The first instinct, when an agent starts struggling with a task, is to add another agent. A researcher next to the writer, a reviewer next to the coder, a planner upstream of both. It feels like the obvious move. The work is too big for one execution window, the responsibilities are blurring together, and splitting them into roles seems like the same kind of separation-of-concerns discipline that has worked in software for decades.
Most of the time, in our experience, that instinct has been wrong.
We have been running a small fleet of agents on a shared platform for over a year. We have added agents we later removed, kept agents we almost cut, and a few times collapsed two roles back into one and never missed the split. The pattern that has held up is uncomfortable, because it asks us to do less of the thing that feels like progress. Before adding another agent, we now spend most of the design time trying to prove the split is unnecessary.
What we look for before splitting
Three signals push us toward a second agent. When none of them are present, we stop.
The first is a durable boundary. The kind that does not move when the product changes. A second agent earns its keep when the line between its work and the first agent’s work is something we can describe in a sentence and expect to still be true in six months. “The first agent writes; the second agent publishes” is durable, because publishing is a different system with its own constraints and access. “The first agent writes; the second agent improves the writing” is not, because the boundary is taste, and taste collapses back into a single judgment every time it is exercised.
The second is an asymmetric capability. The two agents need different tools, different model classes, different permissions, or a different operating mode that cannot reasonably live in one prompt. A small fast model triaging input before a larger model handles the hard cases is a real asymmetry. A planner that “thinks more carefully” before the executor that “writes code” usually is not, because the same model is doing both, and the planner’s careful thinking arrives at the executor stripped of the very context that made it careful.
The third is an isolation requirement. Something about the second piece of work must not see what the first piece saw. Adversarial review, security checks against a fresh context, a sub-task that should not be biased by the parent task’s framing. Isolation is the rarest of the three signals, and it is the one we most often get right when we use it.
If we cannot point to one of these, we stop. The first agent gets a bigger budget, a sharper prompt, or a smaller task. We do not split.
The reasons we have learned to mistrust
The pull toward another agent is rarely framed as “we want a second agent.” It is framed as one of three other things, and each of them is a trap.
The most common is the inability to fit context. The first agent is hitting its window, the conversation is getting long, and the natural fix looks like handing some of it off. This almost never works. What we are usually doing is paying tokens to summarise the same context twice, once into the handoff and once out of it, and losing the parts of it that did not survive the summary. The agent on the other side hallucinates against a shape of the work it was never given. The right move, almost every time, is to compress the task, not the conversation.
The second is a desire to look more autonomous. There is something appealing about an org chart of agents handing tasks to each other. It reads like a team. It demos well. It is also, frequently, a more expensive way to do something a single agent could have done end-to-end. We have shipped versions of this and watched them quietly degrade as the orchestration layer grew faster than the actual work. The fleet got more impressive on paper and worse in production at the same time.
The third is a vague ambition for parallelism. Two agents working at once must be faster than one. In practice, the work is rarely independent enough to actually run in parallel, the orchestrator has to wait for both before it can do anything useful, and the joins are where most of the bugs live. Real parallel work, the kind that benefits from a second agent, is embarrassingly parallel. If we have to think hard about how the results combine, the parallelism was probably the wrong frame.
What goes wrong when we get it wrong
The failure modes have a consistent shape. The handoff loses context the receiving agent needs. The receiving agent fills the gap with a plausible guess. The original agent reads that guess as ground truth and builds on it. By the time the work reaches us, both agents are confidently wrong about something that the first agent, on its own, would have noticed.
Token cost is the second-order version of the same problem. The orchestrator pays for the original prompt, the handoff, the second agent’s reasoning, the response back, and the orchestrator’s own re-reading of all of it. A clean single-agent pass that would have cost a dollar can become ten, and the user-facing improvement is often nothing.
The third one is the one nobody wants to talk about, which is debugging. Two agents disagreeing about a task produce a class of failure where neither log on its own looks broken. The first agent’s output was reasonable given its input. The second agent’s output was reasonable given what it saw. The error lives between them, in the part that nobody owns, and finding it requires reconstructing both contexts at once. We have spent days inside those errors.
The working observation
The most useful change in our design instinct over the last year has been small. We stopped asking “what would a second agent do here” and started asking “what is the single thing a second agent gives us that the first one cannot.” The second question is harder to answer, and we are often surprised by how short the honest answer is.
When the answer is real, we split, and the split tends to last. When the answer is some version of “it would feel cleaner,” we have learned, slowly, to leave the single agent alone and make it better. The cleaner-feeling architecture was almost always the more expensive one to run, and almost always the one we ended up unwinding six weeks later.