The Supervisor That Became a Bottleneck: When Not to Add a Second Agent

The second agent is usually added to fix a problem the first agent didn't have. A run is slow, or messy, or drops a step — and the instinct is to split the work: a supervisor that plans, workers that execute. Sometimes that's right. Often it converts one legible problem into three illegible ones, and the supervisor you added to coordinate becomes the thing everything waits on.

Knowing which case you're in comes down to a single question about what crosses the boundary between them.

A handoff is a lossy serialization boundary

When one agent delegates to another, the receiving agent does not get the conversation. It gets a string someone wrote to summarize the conversation — usually generated by the delegating model, under token pressure, with no idea which detail will matter three steps later.

That's the whole cost, and it's easy to underrate. The parent knows the user said "nothing before 10am," that an earlier tool call already failed once, that the account is on a legacy plan. The child knows: "Book a 30-minute meeting with Priya next week." Everything else was dropped at the boundary, silently, with no error.

Single-agent runs fail loudly — the wrong tool gets called, and you see it in the trace. Handoff failures are quieter: the child does a perfectly reasonable job on a subtly wrong task.

The bottleneck shape

Watch what happens to a supervisor over a long run.

The supervisor holds the plan. It delegates step one, and the worker reports back — and that report lands in the supervisor's context. Step two, another report. Step three, another. By step six the supervisor is carrying a summary of everything every worker did, plus the original task, plus its own planning turns.

You split the work to keep context small, and the coordinator accumulated all of it anyway — in compressed, lossy form, which is worse than having had the real thing. Meanwhile every step now costs two model calls instead of one, and the workers sit idle waiting for a supervisor that can only think about one of them at a time.

⚠️ The tell: your supervisor's context grows faster than any individual worker's. When that's true, the topology is working against you.

Before and after, concretely

A nightly data-quality job: check six tables for schema drift, null spikes, and row-count anomalies, then write one summary.

Split into agents. A supervisor plus six table workers. Each worker gets "Check table orders for anomalies" and its own tool access. Each returns a paragraph. The supervisor reads six paragraphs and writes the summary.

What breaks: worker four finds a null spike in customer_email. Worker two saw a row-count drop in customers an hour earlier and reported it as minor. These are the same incident — an upstream job partially failed — and neither worker can see the other's finding. The supervisor gets two unrelated-sounding paragraphs and reports two unrelated-sounding problems.

One agent, six tool calls. The same model calls check_table six times in one loop. All six results sit in one context. The correlation is trivially visible, because nothing was serialized away between the observations.

The split version cost more, ran no faster in wall-clock terms once coordination is counted, and produced a worse answer. → The work was never independent; it only looked independent because the inputs were separate tables.

✅ When a second agent genuinely earns its place

• The subtasks are truly independent, and no finding in one changes the interpretation of another. Six unrelated customer tickets, yes. Six tables in one pipeline, no.
• The scopes must differ. The worker needs tools or permissions the parent shouldn't hold, or vice versa. Isolation is a real reason to split, and one of the few that survives scrutiny.
• The contexts must not mix. One agent reads a 200-page untrusted document and returns only a structured extract; the parent never ingests the raw text. Here the lossy boundary is the point, not the cost.

❌ When it doesn't

• The steps are sequential. If B needs everything A learned, a handoff is a downgrade with extra latency.
• You're assigning personas. A "researcher agent" and a "writer agent" over the same material is one agent with two prompts and a serialization boundary between them, bought at double the cost.
• The real problem is a bad tool. An agent that keeps mis-querying the database doesn't need a database specialist agent; it needs a tool that returns better errors and a narrower query surface.

Try the tool before the agent

Most delegation urges are really a request for encapsulation: I want this messy sub-procedure to not pollute the main run. A tool does that with no lossy boundary and no second model — it takes typed arguments, does the messy part in ordinary code, and returns a compact result. If the sub-procedure needs judgment on every call, promote it to an agent. If it needs judgment only in how it's invoked, it was always a tool.

The takeaway

Adding an agent adds a boundary, and boundaries drop context. That trade pays off when the pieces are genuinely independent, when scopes must be isolated, or when dropping context is the goal. It does not pay off just because the task has several steps — steps are what loops are for. Before you split, name what will cross the boundary and what will be lost. If you can't state the loss precisely, you're not ready to split.