Supervisor, Swarm or Fan-Out: Choosing a Multi-Agent Shape

The decision, in one paragraph

A multi-agent system has a shape, and the shape is a decision about control flow: who decomposes the task, who executes the pieces, and who has the authority to move the task somewhere else. There are five shapes that recur constantly in the practitioner literature — fan-out, pipeline, debate, supervisor and swarm — and choosing between them is almost entirely determined by three properties of the task, not of your framework. Is the decomposition known before you start? Are the subtasks independent of each other? Is the routing predictable? If the decomposition is known and the pieces are independent, fan them out. If the decomposition is known and each piece needs the one before it, chain them into a pipeline. If the decomposition has to be worked out at runtime but you can say in advance who the possible workers are, put a supervisor on top. If even the routing has to be discovered mid-task, and the specialists differ in tools or authority rather than only in wording, you have a case for a swarm. If a wrong answer is expensive and no single agent can check itself, add debate or a second-model critique inside whichever shape you chose.

And here is the honest default, stated plainly because the rest of this article will be more nuanced than it: start with a supervisor. The orchestrator-worker pattern is favoured in production for three unglamorous reasons — accountability is clear because one component decides, the control flow is debuggable because it is written down rather than emergent, and cost is predictable because it scales with the number of delegations the controller makes. The common guidance across the 2026 literature is to start with the simplest pattern that fits, and the accompanying observation is that most teams over-architect. Teams reach for a swarm because it is intellectually interesting and because the demos are impressive, then spend a quarter discovering that a swarm's flexibility is indistinguishable from a swarm's unpredictability when something goes wrong.

This guide is deliberately about shape selection and nothing else. The mechanics that sit underneath a shape are covered elsewhere on this site and there is no value in repeating them: what one agent owes the next as a typed structure is the subject of the guide to agent handoff contracts and state transfer; making a long run survive a restart is covered in background agents and durable execution; and if you are specifically orchestrating Claude Code subagents rather than designing a service, the tool-level patterns are in the guide to Claude Code subagents in production. What none of those tell you is which shape to reach for in the first place. That is the gap this fills, and it is answerable with a whiteboard rather than a library.

The five shapes and what each one is actually for

The taxonomy below is the common one, and its stability is the reason it is worth learning: these five have survived several generations of framework churn because they describe control-flow relationships rather than APIs. Each subsection states the control flow, what the shape buys you, what it costs, and the failure it invites. That last item matters most, because every shape has a characteristic way of going wrong, and recognising the symptom is how you diagnose a shape mismatch after the fact.

Fan-out: parallel scatter-gather

The control flow is a scatter followed by a gather. A single step splits the task into N independent branches, dispatches them concurrently, waits, and merges the results. There is no communication between branches and no ordering between them. In the cleanest version the branches do not even know how many siblings they have.

What it buys you is wall-clock time. Because the branches run concurrently, total latency is bounded by the slowest branch rather than by the sum of the branches — a genuinely different shape of curve, and the only shape that gets you a ten-source research sweep in roughly the time of one source. It also buys you clean isolation: a branch that fails or produces nonsense has no way to corrupt its siblings, so the merge step can simply drop it.

What it costs is tokens, roughly multiplied by the branch count. Every branch pays for its own context, its own reasoning and its own tool calls, and then the merge step pays again to read all of the outputs. There is no free lunch hiding anywhere in that arithmetic. It also costs you a merge problem that is harder than it looks: five plausible, partially-overlapping, mutually-inconsistent answers are a genuinely difficult input to reconcile, and the reconciler is usually the weakest component in a fan-out system.

The failure it invites is false independence. Branches that were assumed independent turn out to share a hidden dependency — two agents editing overlapping files, two researchers both booking the same slot, two branches drawing conflicting conclusions from the same ambiguous source — and the merge step is where the contradiction surfaces, several minutes and several thousand tokens after the mistake was made. The diagnostic question before choosing fan-out is not "can these run in parallel?" but "if two branches disagree, is that a signal or a bug?" If it is a bug, they were not independent.

Pipeline: the sequential chain

The control flow is a fixed sequence. Step one's output becomes step two's input, and so on to the end. Each stage is specialised, the order is decided at design time, and nothing routes dynamically. A document-intake chain that extracts, then normalises, then classifies, then summarises is the archetype.

What it buys you is legibility, and legibility is worth more than it sounds. You can draw a pipeline on a whiteboard and everyone in the room agrees on what happens. You can test each stage in isolation with fixtures. You can point at a stage and say "the failure is here", which is a sentence that is remarkably hard to say about the other four shapes. Cost is the sum of the stages and it is knowable before you run anything.

What it costs is latency, because a pipeline's total time is the sum of its stages with no opportunity to overlap, and flexibility, because a task that does not fit the fixed order has nowhere to go. A pipeline also has poor failure ergonomics in one specific way: a bad output at stage two is not detected at stage two, it is faithfully carried forward and elaborated by every subsequent stage, so the final output is confidently wrong in a way that is expensive to trace.

The failure it invites is error propagation with amplification. Each stage treats its input as ground truth, because that is what a stage does. A misread figure at extraction becomes a wrong classification, a wrong summary and a wrong recommendation, and each stage adds fluency and therefore confidence. The mitigation is not a better prompt at stage four; it is a validation gate between stages, which is why the verification discussion later in this article matters more for pipelines than for any other shape.

Debate: multi-perspective critique

The control flow is deliberately adversarial. Two or more agents work the same problem from different framings, or one proposes and another critiques, and a resolution step reconciles them. Unlike fan-out, the branches are not independent pieces of one task; they are competing accounts of the whole task, and the disagreement is the product rather than the defect.

What it buys you is error detection that a single agent cannot perform on itself. A model asked to check its own work is checking it with the same priors that produced it, which is why self-critique catches formatting errors and misses reasoning errors. A separate critic with a different framing, or a different model tier entirely, catches a genuinely different class of mistake. For high-stakes outputs — a claims decision, a credit assessment, a compliance memo — that is the difference between a system you can defend and one you cannot.

What it costs is a multiple of tokens and latency for a single answer, plus the design of the resolution step, which is the part everyone underestimates. Two agents disagreeing is easy to arrange; deciding which one is right, without simply deferring to whichever is more fluent, is the whole engineering problem. The economics and the design of the second opinion are treated properly in the guide to second-model verification and what a critique pass actually costs, which is where to go if you decide you need this.

The failure it invites is expensive consensus. Agents converge on a shared answer because agreement is the socially plausible continuation of a conversation, not because the answer is correct, and you have paid three times over for one opinion with a rosette on it. Guard against it by giving the debaters genuinely different inputs, framings or model tiers, and by making the resolution step check the argument rather than count the votes.

Supervisor: hierarchical delegation

The control flow is a loop with a single controller. One agent — the supervisor, also called the orchestrator — holds the goal, decides the next step, delegates it to a worker, reads the result, and decides again. Workers are typically stateless with respect to the overall task: they receive a brief, do one thing, and return. Authority never leaves the supervisor.

What it buys you is the three properties that make the pattern the production favourite. Accountability is clear, because exactly one component decided and its decisions are recorded in one place. The control flow is debuggable, because the supervisor's decision log is a linear narrative of the run, and a linear narrative is something a human can read at speed under pressure. And cost is predictable, because spend is a function of the number of delegations, which the supervisor itself can count and cap.

What it costs is a bottleneck and a single point of confusion. Every step passes through the supervisor, so the supervisor's context grows with the run and its judgement degrades as it grows. It is also serial by default: a naive supervisor delegates one thing at a time even when three of them were independent, which is exactly the case for letting a supervisor step fan out. And because the supervisor is where all the decisions live, a supervisor with a badly specified role produces a system that is uniformly, consistently wrong rather than occasionally wrong.

The failure it invites is supervisor overload and vague briefs. The characteristic symptom is workers returning results that are individually reasonable and collectively useless, because the briefs did not say what done looked like. The second symptom is a supervisor that stops making progress around step eight because its own context is now mostly a transcript of its own indecision. Both are specification problems, and both are fixed at the brief rather than in the worker.

Swarm: dynamic peer handoff

The control flow has no controller. Each agent assesses the task on arrival and either handles it or transfers control to a more appropriate specialist. Crucially, in the standard formulation only one agent is active at a time: this is a transfer of ownership, not a broadcast, and the task moves rather than being copied. There is no plan, and the route the task takes is discovered as it goes.

What it buys you is routing that could not have been decided in advance. Consider a support conversation at a Bengaluru fintech that opens as a billing query, reveals a duplicate transaction three turns in, and turns out to be a fraud case. No planner sitting at the front of that flow could have routed it correctly, because the information that determines the route did not exist when the routing decision would have been made. A swarm handles this natively: the billing agent recognises it is out of its depth and transfers to the fraud specialist, which has different tools and different authority. HCLTech reported roughly forty per cent faster case resolution using dynamic agent handoff — worth knowing as a directional signal, but it is a vendor-reported figure for one deployment rather than a general result, and it should not be the basis of a business case.

What it costs is predictability, in every dimension you care about. Cost per task is a distribution rather than a number, because the number of transfers varies. Latency is the sum of however many agents happened to touch it. Debuggability is the worst of the five, because the run has no author: reconstructing why a task went from agent A to agent D to agent B requires reading three independent assessments, none of which had the whole picture. And accountability is genuinely unclear, which matters if a regulator ever asks who decided.

The failure it invites is circular handoff, and it is the most commonly reported failure mode in this shape. A defers to B, B defers to C, C defers back to A, and every one of those decisions was locally reasonable. Nobody misbehaved; the pathology is only visible from above. It is also the shape where the handoff itself carries the most weight, since there is no supervisor holding the thread — which is exactly why the typed handoff envelope with a hop budget is a prerequisite rather than a refinement if you go this way.

Shape	Control flow	Best-fit task	Token cost shape	Latency shape	Debuggability	Dominant failure mode
Fan-out	Scatter to N branches, gather, merge	Known decomposition, genuinely independent pieces, latency-bound	Roughly N× a single branch, plus the merge	Bounded by the slowest branch, plus the merge	Good per branch, poor at the merge	False independence: branches collide or contradict
Pipeline	Fixed sequential chain, each stage feeds the next	Known decomposition with real ordering dependencies	Sum of the stages; knowable in advance	Sum of the stages; no overlap available	Best of the five — you can point at a stage	Error propagation, amplified by each later stage
Debate	Competing accounts of the same task, then resolution	High-stakes output where a wrong answer is expensive	Multiple of a single answer, plus resolution	Bounded by the slowest debater, plus resolution	Good — disagreements are legible artefacts	Expensive consensus: agreement without correctness
Supervisor	One controller decomposes, delegates, reads, decides again	Decomposition unknown up front, worker set known	Scales with delegation count; capped by a step budget	Serial by default; fan out individual steps to overlap	Strong — the decision log is a linear narrative	Vague briefs and a supervisor drowning in its own context
Swarm	Peers transfer ownership; one agent active at a time	Routing only knowable mid-task; specialists differ in tools or authority	A distribution, not a number; unbounded without a transfer cap	Sum of however many agents touched it	Weakest of the five — the run has no author	Circular handoff and non-terminating transfer chains

The selection procedure

Work through these five questions in order and stop at the first one that gives you a shape. The point of an ordered procedure rather than a matrix is that it prevents the most common design error, which is choosing a shape because of a property of your team or your framework rather than a property of your task.

Question one: is the decomposition known before the run starts? Can you write down, today, the list of subtasks that this task will always break into? If yes, you do not need a planner at runtime and you should not pay for one. Proceed to question two. If no — if the subtasks depend on what the first few steps discover — skip to question four.

Question two: are the subtasks independent? Given the decomposition, does any piece need the output of another piece? Apply the disagreement test rather than the parallelism test: if two pieces produced contradictory results, would that be information or a bug? If they are genuinely independent, fan out. If any piece needs a predecessor, you have ordering, and ordering means pipeline. Mixed cases are common and are handled by a pipeline whose stages internally fan out, which is a perfectly ordinary design.

Question three: does a wrong answer need an independent check? This question does not select a top-level shape; it selects an insert. If the cost of a confidently wrong output is high — a rejected insurance claim in Leeds, a declined loan application in Pune, anything a customer can appeal or a regulator can review — then whichever shape you chose needs a verification step that is not the producing agent. That is debate or a single-critic pass, embedded inside the pipeline or after the merge, and it is additive rather than alternative.

Question four: is the routing predictable? You are here because the decomposition is not known in advance. Now ask whether you can nonetheless name the set of workers and write down the rules for choosing between them. If you can name the workers and a controller could plausibly pick between them from the task state, use a supervisor. This is where the large majority of real systems land, and it is why the supervisor is the default rather than a compromise.

Question five: do the specialists differ in authority, not just in wording? Only if you got past question four unsatisfied. A swarm earns its unpredictability when the specialists are genuinely different subsystems — different tool sets, different data access, different permission scopes, different regulatory posture — and when the correct specialist becomes knowable only after work has begun. If your "specialists" are the same model with five different system prompts and the same tools, you do not have specialists; you have a supervisor with a routing prompt, and you should build it as one. Where the authority boundaries actually are is a design exercise in its own right, covered in the guide to designing agent tool permission boundaries.

Decomposition known up front?	Subtasks independent?	Routing predictable?	Specialists differ in tools or authority?	Shape
Yes	Yes	Not applicable	Not applicable	Fan-out, with a designed merge step
Yes	No — real ordering	Not applicable	Not applicable	Pipeline, with validation gates between stages
Yes, partly	Some pieces independent	Not applicable	Not applicable	Pipeline whose stages fan out where they can
No	Discovered at runtime	Yes — worker set nameable	Not decisive	Supervisor — the default answer
No	Discovered at runtime	No — route emerges mid-task	Yes, materially	Swarm, with a hard transfer budget
No	Discovered at runtime	No	No — same tools, different prompts	Supervisor with a routing prompt, not a swarm
Any	Any	Any	Any, and a wrong answer is expensive	Add debate or a critic pass inside the chosen shape

A supervisor loop you can read in one sitting

Here is the supervisor pattern with nothing framework-specific in it. It is plain functions and dictionaries on purpose: libraries in this space are replaced faster than the topologies they implement, so a mental model tied to one vendor's API dates badly. Substitute your own model tier for call_model and your own worker implementations; the control flow is the point.

"""Framework-agnostic supervisor: one controller, many stateless workers.

`call_model` is any callable taking a prompt string and returning text.
`workers` maps a worker name to a callable taking a brief dict and
returning a result dict. Nothing here is tied to a library.
"""

import json


def plan_next_step(call_model, task, ledger, worker_names):
    """Ask the controller for exactly ONE next action, as structured data."""
    prompt = (
        "You are a supervisor. Choose ONE next action.\n"
        f"Goal: {task['goal']}\n"
        f"Acceptance criteria: {json.dumps(task['acceptance_criteria'])}\n"
        f"Workers available: {json.dumps(worker_names)}\n"
        f"Work completed so far: {json.dumps(ledger)}\n"
        'Reply as JSON: {"action": "delegate|finish|escalate", '
        '"worker": "<name or null>", "brief": {}, "why": ""}'
    )
    return json.loads(call_model(prompt))


def run_supervisor(task, workers, call_model, max_steps=12):
    """Return a terminal outcome. Never loops without a bound."""
    ledger = []
    worker_names = sorted(workers)

    for step in range(max_steps):
        decision = plan_next_step(call_model, task, ledger, worker_names)
        action = decision.get("action")

        if action == "finish":
            return {"status": "done", "steps": step, "ledger": ledger}

        if action == "escalate":
            return {"status": "escalated", "steps": step,
                    "reason": decision.get("why", ""), "ledger": ledger}

        name = decision.get("worker")
        if name not in workers:
            # A bad decision is data, not a crash. Let the controller see it.
            ledger.append({"step": step, "worker": name,
                           "outcome": "rejected: unknown worker"})
            continue

        try:
            result = workers[name](decision.get("brief", {}))
        except Exception as exc:
            ledger.append({"step": step, "worker": name,
                           "outcome": f"error: {exc!r}"})
            continue

        ledger.append({"step": step,
                       "worker": name,
                       "brief": decision.get("brief", {}),
                       "outcome": result.get("summary", ""),
                       "artefacts": result.get("artefacts", [])})

    return {"status": "failed", "steps": max_steps,
            "reason": "step budget exhausted", "ledger": ledger}

Three things in that sketch are load-bearing and are the reason the pattern is production-favoured. The max_steps bound means the loop cannot run forever, and exhaustion is a named terminal state rather than a hang. The ledger is the debuggable narrative: it is the artefact you read when a run goes wrong, and it exists because a single controller made every decision in one place. And worker faults are appended to the ledger rather than raised, so the controller can see its own failed attempt and choose differently — which is the cheapest form of recovery available to any shape.

Note what is not in there: any notion of resuming after a process restart. That is deliberate, and it is the subject of a later section.

What each shape costs you structurally

Cost comparisons between topologies are where most write-ups become useless, because they quote numbers from someone else's workload. The durable comparisons are structural, and structural comparisons survive both model pricing changes and framework rewrites. There are four dimensions worth reasoning about, and each has a shape rather than a value.

Token multiplication. Fan-out multiplies token spend by roughly the number of branches, because each branch pays for its own context and its own reasoning, and then the merge pays again to read every output. Debate multiplies by the number of debaters plus a resolution pass. A pipeline is a sum rather than a multiple, and the sum is knowable before you run it. A supervisor's spend is a function of delegation count, which is why a step budget is also a spend cap. A swarm's spend is a distribution whose tail depends entirely on how many transfers happened, which is the strongest practical argument for a hard transfer cap even if you never expect to hit it. One under-appreciated multiplier applies to every shape: each additional agent re-pays for context it did not produce, so a graph with more agents than the task needs is paying repeatedly to re-read the same material.

Latency shape. This is where fan-out earns its keep. Parallel branches make total time a function of the slowest branch, not the sum, so a wide scatter completes in roughly the time of its worst member. Pipelines and swarms are both sums: a pipeline's sum is fixed at design time and a swarm's is discovered at runtime, which makes the pipeline forecastable and the swarm not. A supervisor is serial unless you deliberately let individual steps fan out, and that single change is the most common latency win available in a supervisor system.

Debuggability. Rank them honestly: pipeline, then supervisor, then debate, then fan-out, then swarm. A pipeline lets you point at a stage. A supervisor lets you read a decision log written by one author. A debate leaves you the disagreement itself, which is an unusually informative artefact. A fan-out is easy to debug per branch and hard to debug at the merge, where contradictions surface far from their cause. A swarm is hardest because the run has no author and no component ever held the whole picture. This ordering is not a reason to avoid the harder shapes, but it is a reason to instrument them more heavily before you need to — the span structure and attributes that make a multi-agent run readable are covered in the guide to instrumenting agents with OpenTelemetry.

Blast radius of one bad agent. In a pipeline, one bad stage corrupts everything downstream and each subsequent stage adds confidence to the error. In a fan-out, one bad branch is contained and can be dropped at the merge, which makes fan-out the most fault-tolerant of the five in this specific sense. In a supervisor, one bad worker is contained but one bad supervisor is total, so the supervisor's specification deserves disproportionate review effort. In a debate, a bad debater is precisely what the shape is designed to absorb. In a swarm, one bad agent can send the task somewhere useless and there is no controller to notice, which is why swarms need the transfer budget to double as a safety net rather than only as a cost control.

Three root causes of failure, mapped to the shapes

Recurring findings in multi-agent failure analyses converge on three root causes, and the useful move is not to memorise them but to notice that each shape is disproportionately exposed to one of them. Choosing a shape is therefore also choosing which failure you have signed up to defend against.

Specification ambiguity. Agents misinterpret their roles or skip verification steps because the brief did not say precisely enough what was required. This is a supervisor's characteristic disease, because in a supervisor system every worker's understanding of the task arrives through a brief that the supervisor wrote at runtime. It is also the failure that teams misdiagnose most often as a model capability problem, because the workers' outputs look competent in isolation.

Coordination breakdown. Unstructured messaging causes message loss and circular handoffs. This is the swarm's disease by construction: transfer is the primitive, so anything wrong with the transfer is wrong with the system. The two specific production failure modes that recur in this family are agents entering infinite loops, and agents failing to pass necessary context on hand-off — the first is a termination problem and the second is a contract problem, and they need different fixes.

Verification gaps. No independent validation of agent outputs. This is a pipeline's disease, because a pipeline stage's job is to trust its input, and it is also a fan-out's disease at the merge, where the reconciler typically has no way to adjudicate between plausible contradictory branches. It is the last of the three that teams discover, for reasons the next section covers.

Root cause	Most exposed shape	How it presents	Concrete mitigation for that pairing
Specification ambiguity	Supervisor	Workers return individually reasonable, collectively useless results	Make acceptance criteria a required field on every brief, and have the worker restate them before starting. Reject a brief with no checkable definition of done.
	Fan-out	Branches overlap or leave gaps because the split was described loosely	Enumerate the branch boundaries explicitly rather than asking a model to divide the work, and assert coverage at the merge.
Coordination breakdown	Swarm	Infinite loops, circular handoff, context dropped on transfer	A monotonic hop counter no agent may reset, a hard transfer cap whose exhaustion escalates, a loop signature over sender-receiver-state, and a typed handoff envelope.
	Debate	Debaters talk past each other; the resolution step cannot adjudicate	Give debaters the same inputs but different framings, and make the resolver score the argument against stated criteria rather than picking a winner.
Verification gaps	Pipeline	Stage-two error arrives as a confident stage-five conclusion	A validation gate between stages that rejects rather than repairs, plus one independent check on the highest-consequence stage output.
	Fan-out	Merge produces a fluent synthesis of contradictory branches	Make the merge surface disagreement as an explicit field instead of resolving it silently, and escalate branch conflicts above a threshold.

A transfer function that terminates

If you do choose a swarm, the transfer is the whole design. Here is a framework-agnostic version with the guards in place, again as plain functions so that the mechanism rather than the API is what you take away. The caller supplies a state_digest — any stable hash of the task state — which is what makes the loop signature possible.

"""Dynamic handoff: peers decide whether to keep a task or transfer it.

One agent is active at a time. Each entry in `agents` is a dict with an
`assess` callable returning ("handle", None) or ("transfer", peer_name),
and a `handle` callable that does the work and returns a result.
"""


def transfer(envelope, to_agent, reason):
    """Move ownership. The hop list is append-only and never reset."""
    hops = envelope["hops"] + [{"to": to_agent, "reason": reason}]
    return dict(envelope, owner=to_agent, hops=hops)


def run_swarm(envelope, agents, escalate, max_transfers=4):
    """Run until an agent handles the task, or escalate. Always terminates."""
    seen = set()

    while True:
        owner = envelope["owner"]
        agent = agents[owner]
        verdict, peer = agent["assess"](envelope)

        if verdict == "handle":
            return {"status": "done",
                    "owner": owner,
                    "transfers": len(envelope["hops"]),
                    "result": agent["handle"](envelope)}

        # --- the three guards that keep a swarm terminating ---

        # 1. Hard transfer budget. Exhaustion escalates; it never transfers.
        if len(envelope["hops"]) >= max_transfers:
            return escalate(envelope, "transfer budget exhausted")

        # 2. The peer must exist. A hallucinated peer is not a route.
        if peer not in agents:
            return escalate(envelope, f"unknown peer {peer!r}")

        # 3. Loop signature: same sender, same receiver, same state = a cycle.
        signature = (owner, peer, envelope["state_digest"])
        if signature in seen:
            return escalate(envelope, f"circular handoff {owner} -> {peer}")
        seen.add(signature)

        envelope = transfer(envelope, peer,
                            reason=f"{owner} deferred to {peer}")

The while True is safe because envelope["hops"] grows by exactly one on every iteration that does not return, so guard one fires within max_transfers passes regardless of what the agents decide. That is the property you want from a swarm: termination guaranteed by the harness, not by the good behaviour of the agents. Where escalation actually goes — the queue, the interface, the service-level expectations of the humans on the other end — is a design problem of its own, treated in the guide to designing the human review queue an agent escalates into.

Verification is not optional

Of the three root causes, verification gaps are the one teams discover last, and the reason is structural rather than careless. Specification ambiguity announces itself immediately: the workers return the wrong thing and you notice on day one. Coordination breakdown announces itself expensively but unmistakably: the loop burns budget and someone asks about the bill. Verification gaps announce nothing at all. The system produces plausible output, the output is accepted, and the errors accumulate in whatever the output feeds — a claims decision, a compliance memo, a customer's account balance — until something external surfaces them weeks later. An unverified multi-agent system does not look broken. It looks fine, which is worse.

The general principle is that no agent can verify its own output, because it verifies with the same priors that produced it. Self-critique reliably catches format errors and reliably misses reasoning errors. What you need is an independent check, and "independent" has a precise meaning here: different inputs, a different framing, a different model tier, or deterministic code. The cheapest independent check is almost always deterministic code, and it is systematically under-used because it is less interesting than a critic agent.

Where the check goes depends on the shape, and this is the part worth committing to memory.

• Pipeline: between stages, as a gate that rejects rather than repairs. The gate's job is to stop a bad output travelling, not to improve it. A stage that receives a rejection should fail loudly to the operator, not quietly retry until something passes.
• Fan-out: at the merge, and it must surface disagreement rather than resolve it silently. Make branch conflict an explicit field in the merged output, with a threshold above which the task escalates instead of synthesising. A fluent synthesis of contradictory branches is the single most dangerous artefact a fan-out can produce.
• Debate: the shape is the check, but the resolution step still needs one. A resolver that picks the more fluent argument has verified nothing. Score the arguments against stated criteria.
• Supervisor: before the terminal finish action, as an acceptance-criteria check the supervisor cannot skip. In the loop above, that means the finish branch runs a validator over the ledger rather than trusting the controller's own assessment that it is done.
• Swarm: at the point of handling, because that is the only moment where one agent has claimed ownership of the outcome. Whichever agent says "handle" is the one accountable for the result, and its output is what needs checking.

Two practical notes. First, verification has a cost and the cost is the point of designing it rather than sprinkling it: a critic pass on every intermediate step of a twelve-step supervisor run is a doubling of spend for a marginal benefit, whereas one independent check on the highest-consequence output is usually most of the value for a fraction of the cost. The trade-offs are worked through in the second-model verification guide. Second, you cannot tell whether verification is working without a reliability target and a harness to measure against it, which is a separate discipline in its own right, and one worth resourcing before you trust the check. A verification step with no measurement is a ritual.

What the durability requirement changes

One constraint cuts across all five shapes and it has hardened considerably during 2026: a topology that cannot resume mid-run is not a topology you can operate. Agent runs are long, deploys happen mid-run, containers get rescheduled, and a run that restarts from zero because a pod moved is not merely slow — it is a correctness problem, because the side effects from the first attempt already happened.

The distinction practitioners now draw is between checkpointing, where state is saved and the developer implements retry and resume, and runtime-owned durable execution, where the runtime owns retry, resume and deduplication. Runtimes named in that discussion include Temporal, Restate, DBOS and Inngest. Framework support has moved in the same direction: as of September 2026, LangGraph 1.2 requires durable execution and adds graceful shutdown with resumable checkpoints, which is a notable shift from treating durability as an optional add-on. And as of September 2026 the Microsoft Agent Framework — the merger of Semantic Kernel and AutoGen — has been generally available since April 2026 with Python and .NET support. Treat all of those version facts as dated: the shapes in this article will outlive them, which is exactly why the selection procedure above never mentions a library.

What durability changes about shape selection is narrower than it first appears, but it is real. A pipeline is the easiest shape to make durable, because stage boundaries are natural checkpoints and the state at each boundary is small. A supervisor is nearly as easy: the ledger is the state, and a run resumes by replaying the ledger into the next planning call. Fan-out needs care, because resuming means knowing which branches completed and not re-running their side effects. A swarm is hardest, because the resume point is wherever ownership happened to sit, and reconstructing that requires the hop history to be durable too. If durability is a hard requirement on day one, that ordering is a genuine input to the shape decision. The mechanics — idempotent side effects, replayable step results, explicit terminal states — are covered properly in the guide to background agents and durable execution for long-running jobs, and there is no point in restating them here.

One deployment note that matters for teams operating in both of our markets: durability is a per-region property, not a global one. A supervisor whose checkpoints live in AWS Mumbai and whose workers run against models served from London is a design where a regional failure leaves you with durable state you cannot resume against, and a data-residency posture nobody wrote down. Decide, per shape, where the state of record lives, and make it the same region as the thing that resumes it.

Migration paths: from supervisor to swarm without a rewrite

The reason to start with a supervisor is not that it is always right; it is that it is the shape with the best migration options. Every other shape can be reached from it incrementally, which is not true in reverse.

Supervisor to fan-out is the smallest move and the most commonly needed. You do not change the shape at all; you let a single supervisor step dispatch several independent briefs concurrently instead of one at a time. The ledger gains a batch entry rather than a new structure. Do it when your latency is dominated by a run of consecutive delegations that never read each other's results — which is visible directly in the ledger, and is the first thing to look for when a supervisor system is judged too slow.

Supervisor to pipeline is a hardening move rather than an expansion. If your supervisor picks the same sequence of workers on nearly every run, the planner is paying tokens to rediscover a plan you already know. Replace it with a fixed chain and keep the supervisor only for the cases that deviate. The signal is a low-entropy decision log: pull a hundred ledgers and count how many distinct worker sequences appear. If it is three, you have a pipeline with two exceptions.

Supervisor to debate is purely additive. Insert a critic before the terminal step, or run two workers on the highest-consequence subtask and add a resolution step. Nothing about the surrounding shape changes. The signal is an error class that verification would catch and retries do not — that is, wrong answers rather than failed ones.

Supervisor to swarm is the only migration that changes where authority lives, and it should be done one edge at a time rather than wholesale. The path that works: keep the supervisor, but grant one specific pair of workers the right to transfer directly between themselves for one specific case, with its own transfer budget, escalating back to the supervisor on exhaustion. You now have a hybrid where the dynamic behaviour is confined to a single edge whose cost and failure profile you can measure in isolation. If it holds, grant a second edge. Most systems stop after two or three edges and never become a full swarm, which is the correct outcome rather than an incomplete migration.

The signals that justify that last move are specific, and if you cannot name one of them you should not make it. First, the supervisor is repeatedly wrong about routing in a way that better briefs do not fix — meaning the information needed to route genuinely was not available when the supervisor decided. Second, the specialists have diverged in tools or authority to the point where the supervisor cannot meaningfully evaluate their outputs. Third, the round trip through the supervisor is itself the dominant latency cost for a case that two workers could resolve directly. Note what is not on that list: the swarm looked more modern, a framework made it easy, or the team wanted the agents to be more autonomous. Also note that swarm-shaped autonomy expands the attack surface as well as the cost surface — agent-related security incidents were prominent enough in 2026 that the incident numbers made the news, and an agent that can hand a task to any peer can hand it somewhere you did not intend. If you do widen the graph, tighten what each node may reach rather than letting every peer inherit the union of everyone else’s tools.

One task, three shapes: a worked example

Consider a concrete task with a dual-market flavour: a compliance summary of a new supplier, needed by a procurement team that operates a Bengaluru engineering office and a London commercial office. The work involves five independent lookups — corporate registry, sanctions screening, adverse media, financial filings and an internal contract history search — followed by a synthesis and a recommendation. It is a good example because it is genuinely decomposable, the pieces are genuinely independent, and the output is genuinely consequential.

Everything below is illustrative arithmetic, not a measurement. Assume, purely as stated inputs, that one agent turn consumes one unit of tokens and takes one unit of wall-clock time. Substitute your own model tier and your own measured turn time; the ratios are the point, and the ratios are what survive a price change.

As a fan-out. Five lookups dispatched concurrently, then a merge. Token cost is five units for the branches plus roughly one to two units for the merge, since the merge reads all five outputs. Latency is one unit — the slowest branch — plus the merge, so call it two units. This is the fastest shape available and it is the right answer if the procurement team is waiting on the result interactively. The risk is at the merge: if the adverse-media branch finds something the registry branch's clean result appears to contradict, a fluent synthesis of the two is exactly the wrong output, and the merge must surface the conflict instead.

As a pipeline. The same five lookups in a fixed order, each stage passing forward an accumulating dossier, then a synthesis stage. Token cost is around six units, marginally lower than the fan-out because there is no separate merge to pay for — though in practice each stage re-reads the accumulated dossier, so the true cost drifts upward with chain length. Latency is six units, three times the fan-out, because nothing overlaps. What you buy for that latency is the best debuggability of the three and a natural place for a validation gate between every stage. This is the right answer if the summary is produced overnight in a batch and nobody is waiting.

As a supervisor. A controller decides which lookups are needed for this particular supplier, delegates them, reads the results and decides whether to go deeper. Token cost is variable: perhaps four units if the supplier is well-documented and two of the five lookups are unnecessary, perhaps eight if the adverse-media hit warrants three follow-up delegations. Latency is the number of delegations, serially, unless you let the controller dispatch the independent lookups as one batch — which is the supervisor-to-fan-out migration described above, and which brings latency close to the fan-out's while keeping the controller's judgement about which lookups to run at all. That hybrid is what most mature systems end up building, and it is the reason the supervisor is the right starting point: it is the only one of the three you can turn into either of the others without redrawing the graph.

Notice what the comparison actually turned on. Not model quality, not framework choice, not prompt engineering. It turned on whether anyone was waiting for the answer, whether the lookups were independent, and whether the set of lookups was known in advance. Those are properties of the task, they are the same three properties the selection procedure asks about, and they are all answerable on a whiteboard before anyone opens an editor.

That, finally, is the argument for treating shape selection as a first-class design step rather than a by-product of whichever tutorial you started from. The shape you choose determines your token bill, your latency floor, your blast radius and how long it takes to diagnose a bad run — and unlike a prompt, it is expensive to change once several teams depend on it. Choosing it deliberately, writing down why, and naming the symptom that would falsify the choice is a small amount of work with an unusually long shelf life. It is also, incidentally, the kind of engineering judgement that is invisible on a CV and immediately obvious in a repository. If you have made that call and can defend it, put it somewhere the people hiring for agent and platform work across Bengaluru, Hyderabad, London and Edinburgh can actually see it.