Agent Teams in Production

The last two lessons gave you the instruments: an agent, sub-agents for context, skills for pay-on-use knowledge, hooks for rules. This lesson is about putting more than one agent on the same problem at the same time, and the specific things that go wrong when you do.

The short version of why you would: some reviews are more honest with three independent readers than with one, some workloads have embarrassingly parallel structure, and some gather phases are large enough that running them concurrently is the only thing that keeps latency in a range the customer accepts. The short version of why you would not: every extra agent is extra cost, extra failure modes, and extra orchestration.

Fan-out, fan-in

The one pattern that justifies its complexity in FDE work is fan-out, fan-in. A coordinator sends the same input to several specialists in parallel. Each specialist runs its own loop. Their answers come back, and the coordinator merges them into a single result.

1. Step 1

   Fan out

   Coordinator dispatches the same brief to N specialists in parallel. Each one has its own tools, its own context, and its own stopping conditions.

2. Step 2

   Specialists run

   Independent loops. They do not see each other's work — that is the whole point, because independence is what makes the eventual agreement a signal.

3. Step 3

   Fan in

   Coordinator reads the N answers and merges them. Agreement is a strong result; disagreement is a signal to escalate, not a vote to tally.

This shape maps directly onto the review patterns that production deployments use for anything irreversible: three specialists each decide whether a proposed write should go through, and the coordinator ships only if the agreement is clean. It is slower than one agent and more expensive than one agent, and when the alternative is an incident, it buys the right thing.

The cost curve

The honest numbers worth internalising:

Each agent has its own context. System prompt, tool definitions, skills it advertises, the gather phase it is going to run — none of that is shared across specialists. Three specialists working on the same brief is not one context used three ways; it is three contexts used in parallel.

Coordinator cost is on top. The coordinator has its own context, and has to read each specialist's answer back. If each answer is a few hundred tokens, the coordinator's turn to merge them costs roughly N × (answer size) plus its own merging prompt.

Sub-agents multiply. A specialist that spawns its own sub-agent during its gather phase is spending the specialist's budget plus the sub-agent's budget, so a fan-out of three with one sub-agent each is six concurrent contexts, each of them real.

The cheap mitigation that works: a per-specialist tool-call budget visible to the coordinator, a shared token budget for the whole fan-out, and an answer size cap each specialist is asked to respect. None of these remove the cost; they bound it.

When a human is the right node

Agent-team diagrams are honest only when a human is drawn in them. In an FDE deployment the human is not a bottleneck; the human is a node that produces a specific kind of signal nothing else can. Three cases it is worth naming:

Disagreement resolution. When the specialists do not agree — two to one, or two different proposed fixes — the right behaviour is to stop and flag rather than to vote. A human reading a flagged disagreement is a cheap, high-signal step; a ship-on-majority rule is a decision to trust the mode of the model's own opinion, which is the least useful thing about it.

Irreversible writes. Anything that cannot be rolled back — a payment, a deletion, a notification to a customer — deserves a human in the loop by design, not as a fallback. The team exists to do the gather and the drafting; the human exists to sign off on the act. That split is not a compromise; it is the only shape that scales trust.

Labelling and calibration. The customer's domain has edge cases that nobody has a rubric for yet. A human seeing the first dozen of them, labelling them, and feeding those labels back into the eval set is how the team gets honestly good at the domain. Nothing else substitutes for this.

The failure mode to avoid is the opposite one — the human-approves-every- tool-call deployment that pretends to be an agent team and is actually a very slow single operator. It does not scale, it trains the humans to rubber-stamp, and when the rubber-stamping misses, nobody is responsible.

The failure modes that are new

A single agent fails in ways the loop itself can catch — a tool errored, the verify phase said no, the budget ran out. A team of agents fails in ways only the orchestration can see.

Agents disagreeing. Treated above. The code path that handles two "ship" and one "do not ship" is a decision, not a corner case, and it needs to exist before the first time it fires.

Cascading errors. Specialist A leans on a false fact. Specialist B reads A's output in the merge, treats it as external evidence, and reinforces it. The coordinator sees two specialists agreeing and ships. The fix is to keep the specialists blind to each other's output and have the coordinator merge — which is why fan-out, fan-in is the pattern and not a group chat.

Cost blow-up. Three specialists running in parallel, one of them loops, the others wait on the coordinator's timeout. The agent team has spent an order of magnitude more than a single-agent run on a single request. The fix is an owned budget, per-specialist and per-request, enforced by the coordinator before dispatch.

Latency inversion. A fan-out is only as fast as its slowest branch. On a bad day the team is slower than a single agent that would have reached a good-enough answer in half the time. The orchestration layer has to be prepared to return the best-of-N when the deadline arrives, not wait for completeness that no longer helps.

Where this leaves you

You know the loop; you know the surface the loop is allowed to call; you know how to keep the loop focused with skills and sub-agents; and you know when to run more than one loop on purpose. The next part of the course — and the one that most reliably separates FDEs who ship from FDEs who don't — is evals. Every piece of discipline you build there is what lets any of these choices be made from data rather than from vibes.