Multi-agent AI means splitting one job across several specialized agents instead of handing all of it to one. Each agent owns a defined scope, and work moves between them through an explicit handoff. Standing up the agents is the easy part. The handoff rules decide whether the system holds together or quietly drops things.
Thirteen agents run VantaSoft day to day. Fifty-eight scheduled jobs run across twelve of them, and six have a work queue that dispatches tickets automatically. Below are the rules that move work between those agents, what each rule costs, and the four handoffs that failed before we fixed them. Everything here comes from our own fleet records as read on October 13, 2026.
If you want the roster first, each agent and the job it owns is here.
What is a multi-agent AI system?
A multi-agent AI system is two or more agents that each own a narrow job and pass work between them through a shared record, instead of one agent trying to do everything. The defining feature is not the agent count. It is that ownership is explicit at every step and the handoff leaves a trace somebody can read later.
One agent with many tools is still one agent. That is often the right build, and it is where we tell people to start. You cross into multi-agent territory when two parts of the work answer to different permissions or different people.
When do you need more than one agent?
Split an agent when two parts of its job need different access, different judgment, or different approvers. Keep one agent while the work shares an owner and a set of credentials. Every split buys you a handoff, and a handoff is a place work can stop moving, so do not pay for one you do not need.
Three tests we use:
- Does the second half of the work need credentials the first half should not hold? Our finance agent can read the books. Our content agent cannot, and should not.
- Would the same person approve both halves? If an engineering change and a QA sign-off are supposed to be independent, one agent doing both defeats the point of the sign-off.
- Can you name the thing being handed over precisely enough to write it in one line? If you cannot describe it, you do not have a handoff yet.
We learned the third one by failing it. Early on we tried broader agents covering two domains each, and the work that lived between their two halves was the work that got dropped. No agent on our fleet owns two domains now.
How do multi-agent AI systems hand work to each other?
Choose the handoff path by how durable the handoff has to be. Work somebody should be able to audit later belongs on a ticket or a task board. A question you need answered inside the next minute belongs in a direct message. Reaching for the lightweight path to move durable work is the most common way these systems lose a task.
| Handoff path | Use it when | What you get | What it costs |
|---|---|---|---|
| Labelled ticket | the work needs an audit trail | one owner, survives a restart | dead unless a queue reads the label |
| Shared task board | later steps wait on earlier ones | dependencies and retries | a card sent to nobody waits forever |
| Direct message | you need one fact, or a stop | an answer inside this run | no record, and the asker waits |
| Child process | parallel reading in one run | isolation and speed | dies with the parent run |
| Scheduled read | the trigger is a clock, not an event | nobody has to remember | drifts when the input changes shape |
Two of those come with the agent runtime rather than being anything we built. The Kanban board is a durable task board shared across profiles, where every handoff is a row anyone can read and write and every worker is a full OS process with its own identity. Its documentation sets that against in-process subagent swarms, which is the same tradeoff we hit. Subagent delegation is the other side of it: child instances with isolated context, fast and parallel, and gone when the parent run ends.
What do multi-agent routing rules look like in production?
Our issue tracker has no user account for an agent, so the label is the assignment. Applying the engineering agent's label to a ticket assigns it to that agent. There is no second step, and an empty assignee field does not mean the ticket is unassigned.
Six queues read those labels. Each one scans the tracker every thirty minutes without calling a model, and they are offset five minutes apart on purpose, so the half hour runs corporate engineering, voice product engineering, agent deployments, QA, project management and platform engineering in sequence instead of all at once. The scanning script is the same file on every profile. We checked the md5 across the installed copies and got one hash. The routing label is derived from the profile's directory name, so adding a seventh queue is a copy and a cron line rather than a code change.
Four rules do most of the work:
- A ticket with no routing label is invisible, not deprioritized. It is the single most common reason a filed ticket sits untouched for a week.
- Waking is decided by presence, not by change. A ticket sitting in progress wakes its agent again every thirty minutes until it leaves that state, so nothing has to happen for claimed work to get picked back up.
- Parking work on a person adds one label, assigns the person, and keeps the routing label. That routing label is the only record of which agent parked it and which queue it returns to. Removing the park label is the entire hand-back.
- Ownership is exclusive. When our QA agent fails a ticket, it drops its own label and applies the engineering label that owns that surface. Two agents never hold the same ticket at once.
One handoff we deliberately left manual: nothing routes a ticket into the QA queue automatically. A person decides what gets independently tested, because an agent judging its own work ready for QA is a kind of self-grading we would rather not automate. We go further into where those lines belong in human in the loop for AI agents.
What goes wrong with multi-agent handoffs?
Four failures, roughly in order of what they cost us.
The first was a label that routed nowhere. We created a routing label for an agent that had no queue reading it, so assigning work to that label reported success and reached nobody. A ticket sat in that state until a person spotted it. A handoff that returns success and delivers nothing is worse than one that errors, because nobody goes looking for it.
The second was noise from a broken scan. A failed scan used to wake the agent, which meant one timed out API call cost a full model run plus a delivered status report about a queue nobody had read. Since late August the first two consecutive failures stay quiet and the third one reports. On a thirty-minute cadence that works out to roughly one report an hour during a genuine outage and none at all for a blip.
The third was slicing work too thin. We had told the queues to work in thirty-minute slices, so a single ticket ran across seven to ten short runs, each re-reading the ticket from scratch and posting its own report. The work came out fine. The overhead was absurd. Since October 6 a queue run takes one ticket and finishes it in that run, on a ninety-minute lease refreshed while the run is still working.
The fourth is the bill for the third, and we chose to pay it. A long run holds the working-directory lock for its whole profile, so every other scheduled job on that agent waits behind it. We measured it on one profile on October 5: a ten-minute monitoring job started twelve to twenty-eight minutes late behind each queue run. The real fix is a per-job working directory in the runtime. Until that ships, late monitoring beats re-reading one ticket ten times.
The handoff we deleted
Sometimes the best handoff is the one you remove. Until October 5, changing a page on our own website meant the content agent writing up what it wanted and routing a ticket to an engineering agent, who would make the change. Two agents, one ticket and a queue wait, for work the content agent was capable of doing itself.
So we deleted it. The content agent now ships website changes directly, through the same branch, test suite, pull request and staging check an engineer uses. What stayed is the thing that handoff was actually protecting: promotion to production runs through a script that refuses when the release range carries somebody else's unshipped work. The check was the guardrail all along. The second agent was just where we had parked it.
Every handoff in a system like this deserves the same audit. Work out what the step is protecting, then see whether a test or a script can protect it instead of another agent's queue.
Multi-agent AI vs one larger agent
One larger agent is cheaper to run and easier to debug. Several agents give you separate credentials, independent review and an audit trail across each handoff. The honest trade is coordination overhead, because every agent you add is another queue to watch, another wake rule to tune and another place a ticket can go quiet.
The model we work from, written down in an internal training deck last August, is coordination without a swarm. Intake clarifies the request, the priority and the decision owner. A durable task carries state, dependency, acceptance, evidence and blocker. A named specialist does the domain work and returns a focused result. An independent reviewer tests the exact artifact without taking ownership of it. A human approves, rejects or changes the scope. Named owner, one tracker, visible blocker, evidence-backed handoff, explicit decision.
That list is doing more work than it looks like. Most multi-agent demos fail on the second item, because there is no durable task anywhere, only a conversation.
Frequently asked questions
What is the difference between multi-agent AI and one agent with many tools?
One agent with many tools holds a single set of credentials and a single context, and makes every decision itself. A multi-agent system splits those so permissions, judgment and approval can differ by step. If you cannot name the reason for the split, the single agent is the better build.
How many AI agents should a small business start with?
One. Pick the recurring decision that currently depends on somebody remembering, and build the agent that makes it. Add a second when a different job needs different access or a different approver, rather than because two agents sound more capable than one. AI agents for business covers how to choose the first one.
How do AI agents communicate with each other?
Through whatever record you give them. Ours use a labelled ticket for durable work, a shared task board for work with dependencies, and a direct message for a single bounded question. The medium matters less than whether the handoff leaves behind something a person can read afterwards.
What happens when a multi-agent handoff fails?
In a well-built system the work stops somewhere visible. In a badly built one it reports success and disappears. Design for the first: every handoff should either land in a queue something actually reads, or park on a named person with the reason attached.
Is multi-agent AI the same as agentic AI?
No. Agentic AI describes software that takes actions toward a goal instead of only answering questions. Multi-agent is one way to build that, where several such agents divide the work between them. You can have either without the other.
Do you need a framework to build a multi-agent system?
Not to start. Ours coordinates through a shared task board and a labelled ticket queue, both ordinary infrastructure. A framework earns its place when you want many short-lived agents inside one process. It will not help with the part that is actually hard, which is deciding who owns what.
Where to start
Write your handoffs down before you add a second agent. One line each: what gets handed over, who owns it next, what has to be true before it moves, and where it stops if nobody picks it up. If a line will not come out cleanly, the handoff is not ready, and adding an agent will not make it ready.
When you want that turned into something that runs without anyone chasing it, it starts with 30 minutes on your workflows.
More from our own fleet is filed under from our agent team, including the morning brief one of these agents writes every day.
