Multi-agent systems: when they help, and when they're an expensive detour

Multi-agent architectures are the current default answer to "our agent isn't working well enough." Split it into a researcher, a writer, a critic and an orchestrator, and quality goes up.

Sometimes. Often it goes sideways: five agents produce a worse result than one did, at four times the cost and six times the latency, and now there are five things to debug instead of one.

Here's the honest version of when delegation pays.

What a subagent actually costs

Every delegation carries fixed overhead that's easy to overlook:

• Context re-establishment. The subagent starts cold. Everything it needs must be re-explained or re-discovered.
• Re-exploration. It will re-read files, re-run searches, re-derive conclusions the parent already had.
• Report generation. It writes a summary.
• Report consumption. The parent reads that summary and reasons about it.
• Information loss. The summary is lossy by definition. Nuance the subagent saw does not survive the round trip.

For a task the parent could have completed in four tool calls, this overhead exceeds the work. You've paid five times the tokens for a worse-informed result.

Delegate when the payoff clearly exceeds that overhead. Otherwise don't.

When delegation genuinely wins

1. Genuine parallelism over independent work. Twelve files to analyse, no interdependencies. Six competitors to research. Forty test suites to run. Wall-clock time drops proportionally to the fan-out. This is the strongest case and the one worth building for.

2. Context isolation on large-surface exploration. Investigating a codebase or a document corpus generates enormous intermediate context — files read, dead ends explored — that the parent never needs. A subagent absorbs that and returns a distilled finding. You trade tokens for a clean parent context, which on long-horizon runs is often the binding constraint.

3. Adversarial review. A verifier with fresh context and an explicit brief to find problems consistently outperforms self-critique, because the writer's context contains all the reasoning that produced the flaw. Fresh eyes work for models for the same reason they work for people.

4. Genuinely distinct expertise. Different system prompts, different tools, different models, different constraints. A code-writing agent and a security-review agent are legitimately different configurations. A "researcher" and a "writer" that differ only in a sentence of prompt usually are not.

When it doesn't

Sequential dependencies. If B needs A's full output, splitting them adds a lossy summarisation step in the middle for nothing.

Small tasks. Anything the parent finishes in a handful of tool calls. This is the most common mistake by a wide margin.

Routine verification. Checking your own work belongs in the main loop, not in a spawned agent. Current frontier models verify well without being told — and instructing them to add a verification step often produces redundant over-checking rather than better results.

Splitting one modest job across several agents. Parallel subagents are for genuinely independent tracks, not for chopping one medium task into pieces that then need reassembling.

Compensating for a bad prompt or missing tools. If a single agent is failing because it lacks the right retrieval or the right tool, five agents will fail five times in parallel. Fix the underlying gap.

The direction problem

Something worth flagging for anyone maintaining agent systems across model generations: the default delegation behaviour of frontier models has swung.

One generation under-reached for subagents and needed explicit encouragement to delegate. The next reaches for them freely and needs an explicit cap. Prompt guidance written to fix the first problem actively creates the second.

If you carry a "delegate more aggressively" instruction forward into a model upgrade, expect your token spend to multiply. Re-baseline delegation behaviour on every model change, and prefer a deterministic ceiling on spawn count over prose guidance — a hard cap is the only lever that reliably holds.

Architecture patterns that work

Orchestrator + workers. One coordinator holds the goal and the plan; workers execute scoped subtasks. Coordinator gets the frontier model at higher effort; workers get cheaper models at lower effort. This is the default and it fits most real problems.

Prefer asynchronous delegation over spawn-and-block. Long-lived workers that keep their context between subtasks outperform spawn-per-task in two ways: they don't re-establish context each time (which means their prompt prefix stays cached), and the orchestrator isn't bottlenecked waiting on the slowest one. If your platform supports persistent worker threads, use them.

Writer + verifier. Two agents, opposing incentives. The writer produces; the verifier tries to break it against explicit criteria. Iterate until the verifier passes or you hit a cap. Excellent for anything with checkable output — code, structured deliverables, compliance-sensitive content.

Map-reduce. Fan out identical work across N items, collect, synthesise. Ideal for bulk analysis. The synthesis step is where quality is won or lost — brief it properly.

The seven rules we hold to

1. Cap the fan-out. A hard number in code. Twenty parallel agents on a task that needed three is a cost incident, and models will do it if allowed.
2. Brief precisely, once. The most expensive pattern is launching a vague subagent, waiting, then re-briefing. Front-load the specification: goal, constraints, what "done" looks like, what to return.
3. Commit to the delegation. If you delegated, use the result. An orchestrator that re-derives its subagent's findings has paid twice for one answer.
4. Launch parallel work in one batch. Independent subagents should start concurrently, not sequentially. This is a harness concern and it's frequently got wrong — check that your framework actually parallelises rather than awaiting each in turn.
5. One level deep. Subagents that spawn subagents produce untraceable cost and unreadable traces. Many platforms now enforce this; enforce it yourself if yours doesn't.
6. Give workers narrow tools. A worker researching competitors doesn't need write access. Least privilege limits both damage and distraction.
7. Trace everything, per agent. You need per-agent token counts, per-agent duration, and the full message graph. Without them, a slow expensive run is undiagnosable.

Cost modelling, briefly

A rough model that's close enough for planning:

single-agent cost   ≈ T
orchestrated cost   ≈ T_orchestrator + Σ(T_worker) + Σ(handoff overhead)

Handoff overhead per worker is roughly: context re-establishment + report generation + report consumption. In practice that's often 20–40% of the worker's own token usage.

So a fan-out of five over work that would have been ~2× a single agent's tokens serially lands around 2.5–3× in total spend — bought back as roughly a 5× reduction in wall-clock time.

That's a good trade when latency matters and a bad one when it doesn't. A nightly batch job has no latency constraint; run it serially. An interactive research request does; fan it out.

The test

Before adding a second agent, answer:

What can two agents do here that one cannot?

Valid answers: run genuinely independent work at the same time; keep a large exploration surface out of the parent's context; review with genuinely fresh eyes; apply a materially different configuration of model, tools and constraints.

Invalid answers: it feels more sophisticated; the single agent isn't quite good enough; the architecture diagram looks better.

If the honest answer is the second list, fix the single agent. Better retrieval, better tools, better decision boundaries, a better eval set. That work transfers to the multi-agent version later, if you ever genuinely need it. The reverse isn't true — a badly-grounded agent doesn't improve by being cloned.

---

We build orchestrated systems when the work is genuinely parallel, and one good agent when it isn't. Book an audit call.