Multi-agent: supervisor & swarm

At 3:07 a.m., a support agent receives this message:

“I was charged twice for the same order. Also, I think someone else accessed my account. Please fix it before the second charge settles.”

The system must inspect the billing ledger, check account-security events, read the customer’s contract, decide whether a refund is allowed, and possibly freeze the account. One bad guess can cost money. One slow answer can let a fraudulent charge settle.

The tempting architecture is a planner agent, a billing agent, a security agent, a policy agent, and a final writer agent. Draw a few arrows between them and it looks like a research lab.

It may also be a $10 support ticket that now takes eight model calls, three retries, and a forensic investigation to explain.

A multi-agent system is a system in which multiple independently controlled agents cooperate on one task. An agent is a model-driven loop that can interpret a goal, choose actions, use tools, and inspect the results. The important word is independently: two prompts sent by one controller are not automatically two agents.

Orchestration is the control logic that decides which agent acts next, what information it receives, and how its result changes the task. The shape of that control logic is a topology.

The four topologies

Single agent

One agent receives the goal, chooses tools, observes results, and continues until it can answer or act. “One agent” does not mean one model call; it may make many tool calls inside one controlled loop.

For the duplicate-charge case, it can inspect the ledger, compare authorisation IDs, read the refund policy, check security events, and ask for approval before freezing the account or issuing money. Its one working context preserves relationships such as “the second charge is pending” and “the account was accessed from a new country.” Fewer boundaries also make testing and debugging easier.

Supervisor and workers

A supervisor, or orchestrator, breaks a goal into sub-tasks, sends them to workers, and combines their results. A worker is a focused agent responsible for one bounded piece of the job.

The supervisor might delegate billing, security, and policy checks. It owns the overall decision, making one obvious place to log the plan, enforce a budget, and require approval. Workers need only the evidence they are authorised to see and should return facts, evidence references, uncertainty, and a recommendation.

This topology helps when subtasks are independent enough to run concurrently or require very different contexts. It is not justified merely because “billing” and “security” sound like different departments.

Swarm

A swarm is peer-to-peer: agents hand control to one another. A handoff transfers responsibility, so the receiving agent becomes responsible for continuing the task.

This fits tasks where ownership genuinely changes, such as a conversation moving from qualification to pricing to contracting. Its cost is distributed control. With many possible paths, a slightly different model response or tool result can change execution, making failures difficult to reproduce.

A supervisor asks workers for bounded results and keeps control. A swarm transfers control and lets peers choose what happens next. That difference affects retries, permissions, tracing, and evaluation.

Hierarchical orchestration

A hierarchical system has supervisors managing other supervisors. It earns its keep when a large task crosses domain teams with separate tools, data permissions, and escalation policies. Local supervisors can own their domains without loading every rule into one context.

The trade-off is compounded coordination: each level can delay, misroute, or compress evidence incorrectly. More layers do not create more truth.

The mechanism: context isolation, not agent count

A context window is the bounded collection of instructions, conversation, tool results, and other tokens a model can consider in one request. It is working material, not permanent memory or a shared whiteboard.

Suppose an investigation collects 40,000 tokens of logs, policy text, source code, and tool output. A model with a 16,000-token usable budget cannot reliably hold all of it at once. Even a larger window forces relevant facts to compete with irrelevant material. Attention is finite; a longer prompt is not free comprehension.

A supervisor can split the investigation into three contexts:

• The billing worker sees 12,000 tokens of ledger and payment evidence.
• The security worker sees 10,000 tokens of authentication events.
• The policy worker sees 8,000 tokens of contract and refund rules.

The supervisor receives three 500-token structured reports rather than 30,000 tokens of raw material. Each worker spends its context on one evidence domain; the supervisor spends its context comparing conclusions.

That is the core mechanism. Multiple agents create multiple attention budgets and control loops. They do not automatically make any individual model smarter.

Parallelism changes time, not work

Independent workers can run in parallel. If three workers each need three seconds, their portion can take about three seconds rather than nine. That reduces wall-clock time, but the system still performs all three workers’ work, so token cost and failure opportunities remain.

Assume:

• One model call takes 1.2 seconds.
• One tool call takes 0.3 seconds.
• A single agent needs five model calls and four tool calls.
• A supervisor needs one planning call, three workers with two model calls and one tool call each, and one synthesis call.

The single-agent path takes:

5 × 1.2 + 4 × 0.3 = 7.2 seconds

The supervisor path, if workers run concurrently, takes approximately:

1.2 + (2 × 1.2 + 0.3) + 1.2 = 5.1 seconds

The parentheses represent the slowest parallel worker, not the sum of all three. The supervisor is faster here but makes eight model calls instead of five. At 2 cents per model call, the model portion is 10 cents for the single agent and 16 cents for the supervisor. These are illustrative assumptions; real latency depends on models, queues, regions, and tools.

If workers run serially:

1.2 + 3 × (2 × 1.2 + 0.3) + 1.2 = 10.5 seconds

That architecture is both slower and more expensive. Multiple agents are not the same as parallel execution.

A practical decision rule

Ask:

What does each agent need to keep separate, and why can’t one agent with tools do the same work?

The answer should identify a concrete context, permission, or concurrency requirement. “The task is complex” is not enough. Complexity may be better handled by a deterministic workflow, retrieval, code execution, or a single agent with a clearer tool contract.

If the refund case always follows the same five checks, write them as a workflow and use a model only where interpretation is needed. If one agent merely needs current ledger data, give it a ledger tool.

The production pattern that usually survives

When multi-agent is justified, a supervisor with focused workers is the most containable default.

Give the supervisor a goal, deadline, worker limit, and list of actions requiring approval. Give each worker a narrow input and output schema. A useful result contains:

• status: completed, blocked, or uncertain
• facts: observations tied to evidence identifiers
• uncertainty: what the worker could not establish
• recommendation: a proposed next step, not an unauthorised side effect
• required_follow_up: missing data or escalation reason

Return a decision-ready summary, not a transcript. For example:

completed. Ledger contains two authorisations but only one captured payment. Evidence ledger-1842 and ledger-1843. Refund is not yet appropriate; place a hold on the pending authorisation if supported.

Keep communication one-way where possible: the supervisor delegates, workers report, and the supervisor decides whether another bounded task is needed. If workers must talk directly, define permitted recipients and transition conditions.

Set budgets for fan-out, delegation depth, handoffs, total model calls, worker timeouts, retries, and the final deadline. Cancel workers when enough evidence is available, and provide a useful partial-result or human-escalation path.

Trace the parent task and every child call with a shared correlation ID. Record assignments, input references, model, tools, outputs, latency, token usage, retries, and final disposition. Redact secrets and sensitive data; restrict trace access and apply retention policies.

Treat side effects differently from analysis. Workers may recommend “freeze the account” or “issue a $120 refund,” but the responsible service must enforce identity, authorisation, idempotency, and approval. An idempotency key lets a service recognise a retry of the same operation instead of performing it twice. Derive the refund key from the case and original charge, not a new random value per retry.

Failure modes you can see in production

• Fan-out becomes a multiplier. Rising p95 latency and token use indicate that uncertainty is spawning too many workers. Set a hard fan-out budget and require a reason each new worker adds information.
• Summaries lose evidence. A coherent answer that lacks record IDs or confuses “pending” with “captured” has compressed away a qualification. Require structured, evidence-linked facts and evaluate whether conclusions are supported.
• Routing goes wrong. “Not my area” or confident application of the wrong policy indicates vague routing inputs. Pass intent, entity IDs, risk, required data, and allowed actions; use deterministic routing for obvious cases.
• Handoffs loop. Repeated cases or maximum-step errors mean peers are transferring responsibility without changing state. Track handoff history and progress, reject repeated transitions, and cap handoffs.
• Workers race or repeat side effects. Conflicting shared state, duplicate refunds, or repeated emails occur when parallel workers mutate state or retries hide a completed operation. Have workers propose actions; let one authorised coordinator commit them, and make side-effect tools idempotent with durable operation IDs.

A timeout is not proof that nothing happened. Distinguish “request sent,” “operation confirmed,” and “confirmation unknown.”

The honest trade-off

Multi-agent orchestration provides separate contexts, parallel model-driven work, and distinct ownership boundaries when those properties are deliberately implemented. A workflow or single controller may provide parallelism and permissions more cheaply.

It charges for the benefits with more model calls, tokens, latency variance, coordination bugs, and a harder evaluation problem. A supervisor contains these costs better than a swarm because its control path is central. A swarm fits when peer ownership is genuinely the domain model; a hierarchy fits large organisational trees, but every layer adds a summarisation boundary and bottleneck.

Choose a topology because the task has a property that one agent cannot handle cleanly—not because its diagram has more circles.

In one breath

• A single agent owns one loop and uses tools. Start there.
• A supervisor delegates bounded sub-tasks and synthesises reports.
• A swarm lets peers hand control to one another; it is flexible but difficult to trace.
• A hierarchy adds supervisors above supervisors for genuinely large domain trees.
• Multi-agent earns its cost when contexts, work, or permissions need separate boundaries.
• Parallel workers can reduce wall-clock time while increasing calls and cost.
• Use structured evidence-linked summaries and limit fan-out, depth, handoffs, retries, and side effects.
• Context separation reduces distraction and disclosure; it does not replace authorisation.
• If steps are fixed, use a workflow. If one agent and good tools suffice, use one agent.

Next, see context engineering, observability, and agent evaluation.

Quick check