Most systems described as "multi-agent" would work better as one agent with good tools, or as a workflow with a model inside one step. Several agents earn their place only under specific conditions, and when they do, the hard part is not the agents. It is the orchestration around them: who decides what happens next, what passes between agents, where state lives, what stops the system when it goes wrong, and how anyone can tell afterwards what happened.
This note covers those decisions. The complete guide to AI agent architecture places them in the wider picture; here we go one level deeper.
First: do you need more than one agent?
Four reasons justify splitting work across agents.
- Specialisation you can test. One agent's instructions and tools have grown so broad that it can no longer be evaluated properly. Several narrower agents, each with a clear job, can be.
- Parallel work. The task divides into independent parts that can run at the same time — researching several suppliers, checking several documents.
- Separation of duties. The agent that prepares a payment should not be the one that approves it, for the same reason that a person should not.
- Clean context. Each worker gets only what its subtask needs, rather than one context window carrying everything.
There are also strong reasons against. Anthropic, describing its own multi-agent research system, reports that agents typically use about four times the tokens of a chat interaction and multi-agent systems about fifteen times — and that tasks in which agents must share the same context, or depend heavily on one another, are a poor fit. Every hand-off is also a place where information can be lost, and every additional agent is another identity to secure and another behaviour to evaluate.
If none of the four reasons applies, stop at one agent.
Orchestration is a control-flow decision
The central question in any orchestration is: who decides what happens next — code or a model?
Anthropic's distinction is useful here. In a workflow, models and tools follow paths defined in code. In an agent, the model directs its own steps. Multi-agent systems mix the two, and the best ones are deliberate about where. Our recommendation is simple: let code own the parts of the path you already know, and let a model decide only where the variation is real. A deterministic spine with agentic steps is easier to test, cheaper to run and far easier to explain than a free-form conversation between agents.
Five patterns
| Pattern | Shape | Use when | Watch for |
|---|---|---|---|
| Pipeline | Fixed sequence of specialists: intake → research → draft → review | The steps are known and always the same | One weak stage silently degrading all the later ones |
| Router | A classifier sends each request to the right specialist | Requests fall into distinct types with different tools | Misroutes with no way back; a "general" bucket that grows |
| Parallel fan-out | Independent subtasks run at once; results are merged | The work divides cleanly and speed matters | Merging contradictory results; cost multiplying with width |
| Orchestrator and workers | One agent plans and delegates; workers execute and report | The subtasks cannot be known in advance | Runaway delegation; the orchestrator trusting whatever comes back |
| Reviewer loop | One agent produces; another checks against explicit criteria | Quality can be judged against a written standard | Endless revision; a reviewer with vague criteria |
Most production systems combine two or three: a router at the front, a pipeline for each request type, and a reviewer before anything leaves the system. Start with the simplest that fits, and add a pattern only when a specific failure demands it.
Hand-offs are contracts
Between agents, everything travels as a message, and every message should be a contract rather than a chat.
- A defined shape. The task, its inputs, its constraints, the expected output format, a deadline or budget, and where each input came from.
- Validated by code. The orchestrator checks that a worker's output matches the expected shape before passing it on. A malformed result is an error to handle, not text to interpret.
- Data, not instructions. A worker treats what another agent sends exactly as it treats a document or an email: as content to work with, never as commands that override its own instructions. This is what stops one compromised or confused agent from steering the rest.
- No credentials in messages. Agents never pass access to one another. Each acts under its own identity, with only the tools its own job requires — never the union of everyone's. The note Agent permissions and tool boundaries covers how those boundaries are enforced.
State lives outside the agents
In a multi-agent system the question "where are we?" must have one answer, and it cannot live in any agent's context window. Keep a task record that the orchestrator alone writes to: the plan, which subtasks are assigned, done or failed, the results received, and the decisions taken. Checkpoint after every step that changes something outside the system, so a failure resumes instead of restarting and repeating actions. The same reasoning, applied to single agents, is in Persistent vs ephemeral agents.
Limits that stop a runaway system
A single agent stuck in a loop wastes money. Several agents stuck in a loop with each other waste it faster, and can take real actions while they do. Set limits outside the agents, per task:
- a budget of steps, tokens, time and cost, with a hard stop;
- a maximum delegation depth, so workers cannot spawn workers indefinitely;
- detection of repetition — the same subtask requested again and again;
- timeouts on every hand-off;
- a circuit breaker that pauses the task and hands it to a person, with the trace attached.
People are steps in the graph
Approvals are not an afterthought bolted onto the end. Where a decision needs a person, the orchestration includes a step that pauses, presents the evidence, waits for the decision, records it, and continues or stops. The person sees one coherent request, not the internal chatter that produced it. Human Approval Patterns for AI Agents covers how to design those steps so they are fast and meaningful.
Athena note — My job in a mission is to keep every specialist aligned and inside the boundaries a Human Wizard approved. In practice that means I care less about how clever each agent is and more about the hand-offs between them: what was asked, what came back, and who decided.
One trace per task
When a multi-agent system gets something wrong, the first question is which agent erred. Without tracing, nobody can answer it. Record one trace per task across every agent: who did what, with which inputs, using which versions of model, instructions and tools, at what cost and in how long. Then evaluate at two levels — each agent against its own job, and the whole system against the outcome — because a system can fail while every agent passes its own tests.
In the Guild's Citadel, this is what the Activity Ledger is for: what changed, who acted, and what evidence supports the action. The Agent Console shows which agents are active, healthy and within policy, and the Approvals module shows where human judgement is required before work continues.
How it fails
| Failure | What you see | What prevents it |
|---|---|---|
| Lost hand-off | A worker answers a different question from the one asked | Message contracts; validation by code |
| Chatter | Agents passing work back and forth without progress | Step budgets; repetition detection |
| Permission bleed | A worker acting with another agent's access | One identity per agent; no credentials in messages |
| Cascading invention | A worker invents a fact; the orchestrator builds on it | Provenance on every result; a reviewer that checks sources |
| Deadlock | Agents waiting on each other indefinitely | Timeouts; a single owner of task state |
| Cost blow-up | A wide fan-out on a task that did not need it | Per-task budgets; a pattern chosen on purpose |
| Blame fog | Nobody can tell which agent caused the error | One trace per task, with versions |
An example
Illustrative example, not a client engagement.
A procurement team prepares a quarterly review for each key supplier. An orchestrator receives the request and plans three subtasks, which run in parallel with read-only tools: one worker summarises the contract terms, one analyses delivery performance, one reviews invoices and disputes. Each returns a structured result with sources. A drafting agent assembles the review; a reviewer agent checks it against a written checklist — every figure sourced, every concern linked to evidence. The draft then pauses for the category manager, who edits and approves it before anything is sent to the supplier.
Nothing in this design asks agents to negotiate with each other. The path is known, so code owns it; the agents do the reading, summarising and checking that genuinely needs a model.
Designing systems like this is part of the AI engineering work the Guild describes as multi-agent coordination with observability, cost and role-based authority. The principle underneath is the one this note started with: more agents are justified only when they make the work easier to test, faster or safer — and orchestration is what keeps that promise.
