Multi-Agent Delegation: 4 Costs Nobody Models First

A planner agent receives a refund request. It hands the task to a billing agent. The billing agent queries an account agent, which calls a policy agent, which returns a rule.

Five hops later the customer gets a confident answer with the wrong number in it. Every span in the trace reads completed. No exception was thrown anywhere.

This is the signature failure of agent delegation. It is not a bug you catch with a try-except block. It is maths.

When agents call agents, the things you care about stop adding and start multiplying. Error. Cost. Latency. Blast radius.

This piece works through all four agent delegation multipliers, then the patterns that survive them.

Key Takeaways

• Agent delegation compounds rather than accumulates. Five hops at 95% reliability each land near 77%, and nothing in the trace shows you where the 23% went.
• The cost multiple is measured, not theoretical. Anthropic reported its multi-agent research system using roughly 15 times the tokens of a chat interaction, against about 4 times for a single agent.
• Controlling for tokens changes the verdict. A 2026 study found single agents beating multi-agent systems on multi-hop reasoning once both were given equal thinking-token budgets. Identity dies at the first hop. Without token exchange, the user’s authority gets laundered into prose and every downstream agent runs on its own standing credentials.
• Delegation fails in three specific ways. Not initiated at all, initiated without enough information, or issued in the wrong dependency order.
• The protocols do not solve governance. A2A reached version 1.0 under the Linux Foundation, and its four official extensions cover passports, timestamps, traceability and gateways — none of them governance.

---

Quick Navigation

---

The Arithmetic Nobody Runs Before Agent Delegation

Every agent delegation argument starts with one number. How often does a single agent get a task exactly right?

Call it 95%. That is generous for anything with a tool call and a judgement in it. One agent at 95% is fine. A chain of five is not.

Multiply it out. 0.95 to the fifth power is about 0.77. Nearly a quarter of your requests now carry a fault somewhere in the agent delegation chain.

That is the whole problem with agent delegation in one line. Reliability compounds downward while everything else compounds upward.

Worse, the fault rarely stops the job. The next agent gets something plausible, treats it as fact, and builds on it. Agent delegation hides its own errors.

So the question before adding an agent is not “can it do this task”. It is “what does the chain look like once I add it”.

---

Multiplier One: Agent Delegation Multiplies Error

Errors in agent delegation are not random noise. They have a shape, and researchers have started listing it.

A 2026 enterprise workflow benchmark found agent delegation breakdowns to be a main source of end-to-end errors. They fall into three groups.

• No handoff at all. The agent delegation never happened. The task then fails, or an agent without the right tools has a go.
• A handoff with too little in it. The agent delegation happened, but the task description left out the detail that mattered.
• A handoff in the wrong order. The dependency chain broke, so an agent worked from a result that was not ready. Order matters as much as content in agent delegation.

Why the Handoff Loses Meaning

Cognition’s team put this well in Don’t Build Multi-Agents. A smaller model would misread the larger model’s instructions and make a wrong edit, on the slightest wobble in the wording.

That is the deep issue with agent delegation. A handoff squeezes a rich internal state into a short written task. The receiving agent then has to unpack it without the original context.

Their rule is worth learning by heart. Share context, and share full agent traces, not just single messages.

Notice what that means for agent delegation. Every action carries hidden decisions. A sub-agent that cannot see them will make its own, differently.

---

Multiplier Two: Agent Delegation Multiplies Cost

The cost multiple is the best-measured part of agent delegation, and it runs higher than most teams plan for.

Anthropic’s write-up of its multi-agent research system reported roughly 15 times the tokens of a standard chat. A single agent sat at around 4 times.

That is not waste, exactly. Their case is that agent delegation works partly because it lets a system spend more tokens than one context window holds.

But it only pays when the task truly needs that spend. Anthropic points at breadth-first queries, where several separate threads can run at once.

Waste makes it worse in practice. One 2026 study of five-agent code-review pipelines in production logged 42,000 to 71,000 tokens per run. Between 29 and 38% of that was context read by agents that never acted on it.

Read that again. Roughly a third of the spend went to agents reading things they did not use. That is a pure agent delegation tax.

The maths here sits next to the per-token numbers in what inference actually costs per token.

---

Multiplier Three: Agent Delegation Multiplies Latency

Latency behaves differently by chain shape, and shape is an agent delegation design choice.

Sequential agent delegation adds up. Four agents at six seconds each is twenty-four seconds, plus the planner’s own thinking time at each end.

Parallel fan-out takes the longest branch instead of the sum. That is the main reason to build this way. The catch is that you wait for the slowest child, and one stalled sub-agent stalls the job.

There is a quieter tax too. Each handoff makes one agent write a task description and the other read it, so you pay output and prefill costs at every boundary.

That is time spent on agent delegation rather than on work. In a five-hop chain it is often the biggest single piece, and it never shows up in the design doc.

A rule of thumb worth keeping. If the sub-task runs faster than the handoff that describes it, agent delegation is costing you on both axes.

---

Multiplier Four: Agent Delegation Multiplies Blast Radius

The security multiplier gets the least attention in agent delegation and causes the most damage.

Identity Dies at the First Hop

Here is how it works. The user signs in to the first agent. Every agent delegation hop after that runs on passed-along trust.

The next agent gets a written task and acts on it with its own standing keys. The user’s authority got laundered into prose along the way.

That is the confused deputy problem rebuilt at fleet scale. It opens the door to agent impersonation through unsigned metadata, to a low-privilege agent climbing through a high-privilege one, and to identity claims written in the message body that models happily believe.

The fix exists and is dull. OAuth 2.0 Token Exchange, RFC 8693, keeps the first user as the subject. It records each agent in the act claim, narrows scope to the sub-task, and expires in minutes.

Four things are never proof of identity in agent delegation. A shared fleet-wide API key. The user’s own bearer token passed down the chain. Arrival on a “trusted” queue. An identity claim the model reads out of the message text.

O’Reilly’s Radar covers why no existing layer solves this cleanly. Read it before you design your own scheme.

Loops, Fan-Out and the Runaway Bill

Beyond identity, agent delegation creates failures a single call cannot. The unit of damage is the cascade.

A retry that hands off again can form a loop. An agent that fans out to many children turns one request into thousands. Neither needs an attacker, and neither is visible until the bill lands.

Add a poisoned input and it gets worse. One agent’s bad output becomes the next agent’s trusted input, spreading through normal API calls. That is why the injection classes we mapped in prompt injection bite harder in a chain than in one agent.

---

What Actually Crosses the Boundary in Agent Delegation

Here is the ledger most design diagrams leave out. Four things should cross every agent delegation boundary. By default, most do not.

What should cross	What usually crosses	Consequence if missing
Full context and prior traces	A short task string	The sub-agent re-decides what was already decided
Delegated identity with scope	The sub-agent’s own credentials	Nobody can answer who authorised the action
A budget in tokens and time	Nothing	Cost and latency have no ceiling
A trace ID spanning the chain	Per-agent logs	Failures cannot be attributed to a hop

The third row is worth a look, because almost nobody builds it. A delegating agent usually cannot say “extract this figure, within 5,000 tokens, by this deadline, and fail loudly if you cannot”.

Without those written contracts, agent delegation runs on unspoken habit. Unspoken rules fail silently.

The protocols have not closed this gap. A2A moved from Google to the Linux Foundation and reached version 1.0, with Agent Cards listing skills and endpoints. But a 2026 review of governance gaps in agent protocols notes its four official extensions cover passports, timestamps, traceability and gateways. None covers governance.

---

The Honest Case Against Agent Delegation

Two respected teams published opposite-sounding posts on the same day in 2025. The clash is still the clearest way to think about agent delegation.

Cognition argued that scattered decisions and patchy context sharing make multi-agent systems fragile. Anthropic reported a 90.2% gain over a single-agent baseline on its own research eval.

Both are right, and the workload settles it. Anthropic’s agent delegation gains came on breadth-first research, where separate threads run in parallel and results merge at the end.

Write tasks are the opposite. When each step leans on the last, agent delegation scatters decisions that needed to stay in one head.

A sharper challenge landed in 2026. One paper found that single agents beat multi-agent systems on multi-hop reasoning once both had equal thinking-token budgets.

That is an awkward result for anyone selling agent delegation as a design. Some of the measured gain was never teamwork. It was permission to spend more tokens.

So test the cheap idea first. Give one agent the budget you were about to spread across five, and see what happens.

---

Three Agent Delegation Patterns That Do Work

None of this makes agent delegation a mistake. It makes it a choice with a bill attached.

1. Parallel research with a merge step. Separate sub-questions, explored at once, results pulled together by the planner. This pattern has the strongest published evidence behind it.
2. Context isolation. A sub-agent does the noisy digging and returns only the answer, keeping thousands of tokens of search out of the main agent’s history. Here the value of agent delegation is in what does not come back.
3. Hard trust boundaries. A separate agent with tighter permissions handles anything touching untrusted content. An injection that lands then reaches a small blast radius, not your whole tool surface.

Notice what these three share. Each has a real reason for the agent delegation boundary, beyond “specialist agents sound tidier”.

The anti-pattern is the opposite: splitting by job title. A researcher agent, a writer agent, an editor agent, each rebuilding context the last one already had.

---

Instrumenting Agent Delegation Before It Grows

Whatever you build, five controls decide whether you can run agent delegation safely.

1. One trace, one ID. A single trace tree across every hop, covering the tool layer and the agent-to-agent layer. Without it, “which agent did what” has no answer. Our guide to the four signals an agent stack must emit covers the mechanics.
2. Per-agent identity. Each agent gets its own key, passed on every call, with the human user kept alongside it three agent delegation hops deep.
3. Written budgets. Token and time limits attached to the agent delegation itself, with a loud failure rather than a quiet overrun.
4. Depth and fan-out caps. A limit on chain depth and on children per agent, enforced outside the agents, because an agent asked to police itself will not.
5. Checked capability claims. Route on proven skill, not self-reported confidence. Research has found that unchecked confidence scores can double quality variance, and self-claims give every delegate a reason to inflate.

Then add one test to your suite. Break a sub-agent on purpose, and check that the failure surfaces instead of returning a plausible completed. Most agent delegation stacks fail this test the first time.

---

The Verdict: Agent Delegation Is a Multiplier, Not an Addition

• Go back to that refund and the five green spans. Nothing there was broken the way software usually breaks.
• Each agent delegation hop multiplied a small doubt, and no boundary carried enough context, identity or budget to catch it.
• Treat every new agent as a multiplier on four axes. If you cannot say what the chain’s success rate, cost, latency and blast radius look like afterwards, you are not designing. You are hoping.
• Teams that get agent delegation right add agents slowly. One agent with a bigger budget, until the work truly branches.
• That is not timidity. It is the same maths, run before the invoice arrives rather than after.

---

Frequently Asked Questions

---

Keep reading

Here are the latest posts from the blog.