What a multi-agent workflow actually looks like
Not a chatbot and not a black box: how specialist agents split one job into steps, use your tools, and stop for a person where judgement matters.
By Rachnova6 min read
“Agentic AI” gets used for everything from a chatbot with a plug-in to a fully autonomous system nobody can explain. In practice, the workflows that hold up in a real business look much more ordinary, and that is exactly why they work.
A multi-agent workflow takes one job your team already does, breaks it into steps, and gives each step to an agent with a single, narrow role. The agents pass work to each other, use the same tools your people use, and stop for a person wherever a wrong call would be expensive.
One job, split into roles
Take support triage. A human agent reads the ticket, looks up the customer, checks past cases, drafts a reply, checks it against policy and sends it. That is five different skills done by one person, usually under time pressure.
A multi-agent version gives each skill to its own agent:
| Step | Agent role | What it does |
|---|---|---|
| 1 | Trigger | A new ticket, email or request starts a run |
| 2 | Research | Pulls the customer record, order history and similar past cases |
| 3 | Draft | Writes the reply or update in your tone |
| 4 | Check | Tests facts, policy and tone against written guardrails |
| 5 | Approve | A person signs off anything that matters |
| 6 | Act | Sends, files or updates your systems, and logs every step |
Narrow roles are the point. An agent that only drafts is easier to instruct, easier to test and easier to replace than one asked to do everything. When something goes wrong, you can see which step failed instead of guessing.
Tools, not magic
Agents become useful when they can act: search your knowledge base, read a CRM record, create a ticket, send an email. Each of those is a tool, a small, well-defined function with clear inputs and outputs, and permissions no wider than the task needs.
We treat tool design as the core engineering work. A research agent that can only read customer records cannot accidentally change one. A sending tool that refuses to run without an approval token cannot skip the human step. Safety comes from what the system is able to do, not from asking the model to behave.
Our MailPilot build follows the same pattern on a smaller scale: reply, forward and organise are tools the assistant calls, and it acts only on instructions the user gives it.
Where people stay in the loop
Human approval is not a sign the AI isn’t good enough. It is a design choice about risk. We place checkpoints where an action is:
- Irreversible, such as sending to a customer, paying, deleting or publishing.
- High-value, such as refunds, contract terms or anything above a set amount.
- Novel, where the request doesn’t match anything the system has seen before.
Everything else can run on its own, with a full audit log. Over time, as a step proves reliable on real volume, you can move a checkpoint later in the flow or remove it. That decision is made on evidence, not optimism.
How we know it works
Before a workflow goes live, it runs in shadow mode: it processes real requests alongside your team, but nothing it produces reaches a customer. We compare its output with what your people actually did, and score each step.
That gives three numbers that decide whether to launch:
- Accuracy per step, so a weak step can be fixed without rebuilding the rest.
- Escalation rate, how often the system correctly hands work to a person.
- Cost and time per run, against the manual process it replaces.
After launch, the same measurements keep running. Models change, data drifts and edge cases appear. Monitoring catches that before customers do.
When not to automate
Some work should stay with people: relationship-heavy conversations, decisions that rely on context nobody has written down, and processes that change every week. A good first workflow is repetitive, rules-based and high-volume, with a clear definition of “done”. Support triage, report preparation, document intake and lead qualification are typical starting points.
If you are weighing up a first workflow, start by mapping one process step by step and marking where judgement is needed. That map tells you most of what you need to know about whether agents will help, and where people must stay in charge.