Supervisor Agent or One Good Agent? When a Multi-Agent Pipeline Pays

The team-lead pattern is everywhere now. A lead agent reads the task, splits it, hands the parts to worker agents, collects the results and asks a human when it is stuck. It looks like a real on-call team, so it feels right for incident response.

But a pipeline of agents is a distributed system, with message delivery, partial failure, stuck workers and a stop button that may not stop anything. This post covers what the evidence says, where these pipelines break, and what to measure before you decide.

What the Evidence Says

Anthropic's research system. In How we built our multi-agent research system, Anthropic reports that a Claude Opus 4 lead with Claude Sonnet 4 subagents "outperformed single-agent Claude Opus 4 by 90.2%" on its internal research eval. The price: agents use about 4x more tokens than chat, and multi-agent systems about 15x. On BrowseComp, token usage alone explained 80% of the performance variance. The same post says some domains where agents must share context or have many dependencies "are not a good fit for multi-agent systems today", and that most coding tasks have fewer parallel parts than research.

Google's scaling study. Google Research ran a controlled evaluation of 180 agent configurations across GPT, Gemini and Claude models. On a parallel financial analysis task, centralized coordination improved performance by 80.9% over a single agent. On PlanCraft, a sequential planning task, every multi-agent variant degraded performance by 39 to 70%. Independent agents amplified errors 17.2x, while a central coordinator held that to 4.4x.

Cognition's warning. In Don't Build Multi-Agents, Cognition states two principles: share full agent traces, not just messages, and "actions carry implicit decisions". Its example: two subagents build parts of a Flappy Bird clone, one draws a Super Mario style background, the other a bird that neither looks like a game asset nor moves like the one in Flappy Bird, and the final agent has to merge two misunderstandings. Their simplest way to follow both principles is a single-threaded linear agent.

A supervisor wins when the work splits into independent parts and is worth the tokens. It loses when steps depend on each other. Most incident investigations are a chain: the alert points to a service, the service to a deploy, the deploy to a config change.

Where Pipelines Break: The Spec Stage

The paper Why Do Multi-Agent LLM Systems Fail? annotated more than 1,600 traces from 7 frameworks and found 14 failure modes in 3 groups: system design issues, inter-agent misalignment and task verification. Common modes include step repetition (15.7%), not recognizing that the task is complete (12.4%), not following the task requirements (11.8%) and a mismatch between reasoning and action.

Many of these start before any agent runs: in the task spec the lead writes for a worker. Anthropic saw the same thing. Early versions spawned "50 subagents for simple queries", and with vague task descriptions subagents duplicated searches or left gaps. Their fix was a delegation contract: "an objective, an output format, guidance on the tools and sources to use, and clear task boundaries."

The paper also tested fixes. Better role specs alone raised ChatDev's success rate by 9.4% with the same prompt and model (GPT-4o), but the authors conclude that "achieving robust MAS reliability often requires more than isolated fixes". A better prompt does not turn a bad topology into a good one.

Push vs Pull: The Mailbox Problem

Agents need a channel. Claude Code's experimental agent teams show a typical design. A team has a lead, teammates, a shared task list and a mailbox. Each mailbox is a JSON file. Messages are pushed: "The lead doesn't need to poll for updates." When a teammate stops, it notifies the lead with its final answer, or with the error text if its turn ended on an API error.

The documented limitations are a good list of what goes wrong in any agent mailbox:

• A sent message is not a done task. A message counts as sent when the write to the recipient's file succeeds. That proves delivery, not action.
• Status lags. Teammates "sometimes fail to mark tasks as completed, which blocks dependent tasks."
• Ghost recipients. After /resume, "the lead may attempt to message teammates that no longer exist."
• Slow stop. Teammates finish their current request or tool call before shutting down.

The lesson: use push for events (done, failed, need help) and pull for state (the task list). Treat a task as done only when its state changes in the shared list, not when a message arrives. Give every claimed task a deadline, so a silent worker shows up as an expired claim instead of a hang.

The Kill Switch Must Live Outside the Agent

Most frameworks give you a turn limit. The OpenAI Agents SDK raises MaxTurnsExceeded when a run passes max_turns. That is a budget, not a kill switch: it fires only between turns.

A shutdown request is cooperative. In Claude Code agent teams, a teammate that gets one "can approve, exiting gracefully, or reject with an explanation." That is not enough for an agent with production credentials.

Build two levels. A soft stop asks the lead to wind down and write a summary. A hard stop works without any agent's cooperation: kill the processes and cut tool access at the layer that holds the credentials. If every tool call goes through one gateway, one switch there stops every agent in the tree.

Escalation Is a Paused State, Not a Message

"Escalate to a human" often means a Slack message and an agent that keeps going. The good frameworks treat it as a checkpoint:

• In the OpenAI Agents SDK, a tool marked needs_approval pauses the run and returns interruptions. You call state.approve(...) or state.reject(...) and resume. The state can be serialized to a database and resumed later. The docs warn that RunState.from_json() does not authenticate the snapshot or the person who submits it, so check who approves.
• In LangGraph, interrupt() saves the graph state through a checkpointer and "waits indefinitely until you resume execution", with Command(resume=...) on the same thread ID.

Define the triggers in the spec, not in the moment: a write action, low confidence, a worker that failed twice, a budget that ran out. Escalation also has limits. Our post on why human approval is not enough covers the reviewer who approves what they cannot judge.

Decision Table

Task shape	Build	Why
Linear chain, each step needs the last result	One agent	Every split loses context; sequential tasks degraded 39 to 70% in Google's study
Several independent checks on the same alert	Supervisor plus workers, results summarized back	Parallel work is where the 80.9% gain came from
Workers must argue and share findings	Team with a shared task list	Needs mailbox, task deadlines and a status owner
Lookup with a known answer (runbook, past incident)	A tool, not an agent	No LLM needed, no tokens, no drift
Any write to production	One agent plus a human checkpoint	Approval must pause the run, not follow it

How to Measure the Flow

Do not compare architectures by feel. Run the same tasks through both and record per task:

1. Outcome against a known answer. Use incidents with a written root cause. SRE Bench works this way: a real fault in a fresh environment and a judge that compares the report with the known cause.
2. Tokens and wall time per solved task. Anthropic's 15x multiplier is the bill. The gain must pay it.
3. Messages per task and duplicated work. Two workers on the same query is the spec failure in numbers.
4. Orphaned tasks. Claimed but never completed. This is your lost-message rate.
5. Turns to stop. How often runs end on the turn limit instead of a finished answer.
6. Escalations. Rate, time until a human answered, and how often the human overruled the agent.

If the pipeline does not beat the single agent on the first two lines, the other four do not matter. Our post on agent token costs shows where the extra tokens go.

How Akmatori Does It

An Akmatori investigation is one agent in the incident manager role. Its AGENTS.md workflow makes it search runbooks, then cross-incident memory, then recent change events, before it calls infrastructure tools. Runbook and memory lookups used to be subagents. They are now gateway tools with lexical BM25 ranking and no LLM in the loop, as the architecture docs describe. That is the fourth row of the table: a lookup with a known answer does not need its own agent.

The MCP Gateway holds the tool credentials and builds each run's tool allowlist from the kind of run, so tool access is controlled outside the agent. Self-improvement changes go through a human: the evaluator drafts proposals, and an operator approves or rejects each one.

Conclusion

A supervisor agent is a tool for parallel work, not a default. For a chain of dependent steps, one good agent with good tools usually wins at a fraction of the tokens. If you split, write the worker spec as a contract, track tasks as state, keep the kill switch outside the agents, make escalation a paused checkpoint, and measure against a single-agent baseline.

If your team wants AI-assisted incident workflows on your own infrastructure, Akmatori helps SRE teams investigate alerts, coordinate response, and automate safe infrastructure actions. Powered by Gcore for global infrastructure reliability.