October 20, 2026 · 7 min read
Multi-Agent Orchestration Failures: When Sub-Agents Delegate
By Anna, co-founder, build and content
The multi-agent orchestration failure nobody warns you about is a worker agent that hands its job to another worker and stops. You get a reply that says the work was launched in the background, no work, and a bill for the hop. We hit this in September 2026 on our own systems, along with two sibling failures: workers that stall waiting on a long test run, and workers that ignore scope you add after they start.
None of these were model errors. All three were orchestration errors, and all three have checks you can run this week.
What does it look like when a sub-agent delegates the job?
A delegating sub-agent returns a message like “I launched a background worker to handle this” instead of a result. The task is not done, the child is working under a different identifier, and the child may delegate again. Your orchestrator sees a clean finish while the real work is still somewhere downstream.
We saw it in early September 2026. A batch of worker agents, each given a bounded file task, came back with a promise instead of a result. Their children did the same. The grandchildren eventually produced the answers, but each extra level re-read the same context, paid for it again, and arrived late under a name the parent was not tracking. The parent then received late notifications for jobs it believed were already closed.
Why do sub-agents hand the job to another sub-agent?
They do it because we told them to. Our standing instructions for the orchestrator said, in effect, “do not do file-heavy work yourself, dispatch workers.” Sub-agents read the same instructions as the parent, so they concluded they were orchestrators too. The behaviour was obedience, not a bug in the model.
This matches what the published research says about where multi-agent systems break. The Berkeley-led MAST study (Cemri and colleagues, arXiv, latest revision October 2025) annotated more than 1,600 execution traces across seven multi-agent frameworks. It sorted failures into 14 modes under three headings: system design issues, inter-agent misalignment, and task verification (arXiv 2503.13657). A role instruction that leaks into the wrong layer is a system design failure. A delegation that returns “launched” and is accepted as “done” is a verification failure.
What does a vague hand-off cost you?
A vague hand-off costs duplicated work, gaps and wrong guesses, and each level of delegation multiplies it. Anthropic’s June 2025 engineering write-up of its own multi-agent research system says early instructions were “vague enough that subagents misinterpreted the task”, and that without detailed task descriptions agents “duplicate work, leave gaps, or fail to find necessary information” (Anthropic Engineering).
Its fix is a checklist worth copying: each subagent needs an objective, an output format, guidance on tools and sources, and clear task boundaries. The same post notes that early versions spawned 50 subagents for simple queries, and that multi-agent systems use about 15 times more tokens than chats.
Cognition made the sharper point in its June 2025 essay on why it avoids multi-agent designs. Actions carry implicit decisions, and when two subagents work from partial context those decisions conflict. Its example is a Flappy Bird clone where one subagent’s bird does not look like a game asset and moves nothing like the original (Cognition). Every extra hop widens that gap.
What are the three delegation failures we hit?
We hit three, all in September 2026, and each had a different mechanism and a different fix. The first is recursion. The second is a stall on a long foreground job. The third is scope that arrives by message after the worker has started.
| Failure | What we saw | Fix that held | Still open? |
|---|---|---|---|
| Recursive delegation | Worker returns “launched in background” and stops; children repeat it | First line of every dispatch: do this yourself, do not delegate. Read-only audits go to an agent type that cannot call the delegation tool at all | Partly: the prompt line works, but only the read-only type blocks it structurally |
| Stall on a long test run | Worker starts the full test suite in the background, arms a monitor, waits, gets killed | Run tests in one foreground call with a long timeout, no monitors, targeted tests only | No |
| Scope added mid-flight | Worker finishes its list, then declines every extension sent as a follow-up message | Put the full authorised scope in the spawn prompt; use messages only for nudges | No |
Why did workers stall on background test runs?
They stalled because “wait for the background job” is not a state the system tracks well. Three build workers finished their edits in early September 2026, started a multi-minute test suite as a background job, and then either armed a monitor and stopped or were killed by a stream watchdog after ten minutes without progress. Each left correct, uncommitted edits in a working directory.
The damage came afterwards. A second worker sent into the same directory risked pushing the same change twice, and one had to be stopped by hand. The parent saw only “finished” notifications with a one-line “waiting” result.
The fix was boring. Tell every build worker to run the tests in one foreground call with a long timeout, never to arm a monitor, and never to stop and wait. We also stopped running the full suite inside agents at all, since the continuous integration run does that. Targeted tests, with visible output every few minutes, keep the watchdog quiet.
Why do workers refuse instructions you add later?
Workers treat the spawn prompt as the only authorised channel. In late September 2026 a merge worker completed its original list of pull requests, then declined every extension we sent by follow-up message: more merges, a scheduled-job change, a database migration. It called them instructions that arrived through an unverifiable channel.
It was right. A message that widens a worker’s scope into production actions looks, from inside the worker, exactly like an injected instruction. So the rule is: anything that merges, flips a flag, applies a migration or changes a schedule goes in the spawn prompt, complete and authorised up front. Follow-up messages are for nudges such as “poll in the foreground” or “status?”. If the scope grows, start a new worker.
What do the 2026 guidelines say about when to use sub-agents at all?
Fewer than you think. Anthropic’s January 2026 guidance on building multi-agent systems says multi-agent implementations typically use 3 to 10 times more tokens than single-agent approaches for equivalent tasks, and that coordination costs typically exceed the benefits outside a few cases: context pollution, parallel work, and real specialisation (Claude blog).
It also warns that splitting work by role, such as planner, implementer and reviewer, creates a “telephone game” where each hand-off loses fidelity. Split by context boundary instead. Our recursion incident is the cheap version of that warning: the extra layer added nothing a single worker could not do.
What can you check this week?
Run these four checks on any setup where one agent dispatches others. They take an afternoon.
- Read the dispatch prompt a worker actually receives. Does it inherit the orchestrator’s “delegate everything” rule? If so, add a first line saying the worker does the job itself.
- Reject “launched” as a result. Define a finished reply as an artefact: a file, a commit, a row. Anything else is a status message, and a status message is not evidence. Our earlier post on how to know an agent’s task is really done covers that distinction.
- Give each worker a complete scope up front, including what it may merge, apply or change. Test it by asking whether you would need to send a second message to finish the job.
- Cap the depth. Decide how many levels of delegation are allowed and make the deeper layer unable to call the delegation tool where your platform allows it.
If none of these find anything, read the six categories in what broke on the way to 41 agents, which covers the failures that happen inside one agent rather than between them.
Where does this fit in what we sell?
Delegation depth, scope in the spawn prompt and artefact-based completion are the first things we set when we build a team of agents.
In an AI Workforce Sprint, a tomte, our word for one production agent with one defined job, ships with its own scope, its own definition of finished and a named check, so a hand-off cannot quietly turn into another hand-off. The same discipline runs our own agent fleet, and we publish the failures that taught it to us.
One caveat: as of October 2026 the recursion fix is a prompt line for most agent types, and only our read-only type blocks delegation structurally.
Start async
Send us a short description of how your agents hand work to each other and we will tell you, in writing, which hop we would test first. We reply within one business day. No call required.