AI Automation Copilot

The build

The pattern every small business drowns in is the same: requests arrive on three channels, information lives in five places, and someone copies between them all day. The Copilot is our answer built to production standards — a conversational front door, a retrieval layer over the business's actual documents, typed automations for the repetitive middle, and an approval queue where humans stay the authority. It runs this studio's own inbox triage; the client deployment is a configuration of the same engine, not a rewrite.

What we handled

• Chat-first operations: WhatsApp/web inbox triage with AI drafting and human send-off
• Document memory (RAG) over SOPs, price lists and policies — citations included
• Typed flow builder: triggers, classification, drafting, sync — every edge logged
• Approval queue as the product's spine: act-with-permission, never autonomous spend
• Owner console: run states, failure replay, hours-saved accounting
• Deployed on the client's stack and keys — no hostage data, no hostage accounts

We built the boring machine first

Small businesses don't lose hours to strategy; they lose them to copying: an enquiry lands on WhatsApp, its details go into a sheet, an invoice goes out, a payment gets chased, a question gets answered by re-reading the same PDF. Every “AI transformation” pitch ignores that the money leak is administrative. So the Copilot was scoped from one principle: an AI that removes a copy-paste step and then stops.

It runs here first — triaging studio enquiries, drafting replies against our own service docs, prepping invoice summaries — which is the only credibility test we accept for an automation product: it has to survive the week its author actually works through it.

What the Copilot actually is

Three surfaces, one engine. A conversational front door on the channels the business already lives in — WhatsApp and web chat — where the AI reads the thread, classifies intent, and drafts the next action. A typed flow canvas where automations are assembled from real primitives (trigger → classify → retrieve → draft → approve → sync), each edge validated and logged. And an owner console that shows every run in every state — done, needs-review, failed — with replay, so the business person, not the engineer, audits the robot.

Mobile is a first-class citizen because approvals happen on phones: a card arrives in the chat — “Approve 4 invoices, ৳82,400 total” — with full context a tap away and one-tap decision on the surface. That interaction, not a chatbot, is the product's centre of gravity.

Document memory with citations, not vibes

The retrieval layer indexes the business's actual truth — SOPs, price lists, policies, past tickets — and answers only from it, with sources attached so a wrong answer is a traceable sentence, not a mystery. Freshness is explicit: re-indexing is a flow like any other, and anything the docs can't answer routes to a human instead of being improvised. Model providers are interchangeable (OpenAI, Gemini) behind one adapter; keys, retention and region are set per client, never baked in.

Auto-fill, never auto-send

The hard rule from the client projects we took over: automation loses trust exactly once — the day it does something bold and wrong with no undo. So every side-effecting step (sending, paying, deleting, promising) sits behind a human gate by default, and “fully autonomous” is something a client can unlock per-flow with a written blast radius, not a checkbox. Failure states are product surfaces: retry buttons, diffs on what changed, and a run timeline that answers “what did it do at 3pm” in one click.

Hours-saved accounting is computed from actual runs — drafts accepted, threads closed, invoices matched — and shown in the console. If a flow isn't saving measurable time in its first month, the honest response on our side is to retire it, which is what we did with two of our own.

What deploying it for you looks like

Discovery (1–2 weeks): map the two flows with the most copy-paste cost, agree the metrics, sign the scope. Build (4–6 weeks): connectors to your actual systems, the flow canvas populated, RAG indexed over your documents, approval loops tuned with your staff. Pilot (2 weeks, then ongoing): your team drives it; we watch run-logs with you, cut what doesn't earn, and hand over the console, source and keys on day one — the deployment is on your cloud with your accounts, because a tool that can be turned off by a vendor is not a tool.

The whole thing is one stack story: Flutter mobile where humans approve, Next.js console where the business supervises, a typed Node/Postgres core around the model adapters. Which is exactly the set of languages this studio ships in production — see the technology pages for each link in that chain.