One Agent Is Enough

Since the GPT-4 era, models have taken multiple leaps in intelligence and generalization, and on frontier models the gap that prompt and tool design once created is being flattened. Yet context windows remain finite, and models suffer from context rot as conversations grow long. For long-horizon tasks, context engineering has become the central concern of agent design.

What context engineering means in practice has been thoroughly covered elsewhere; LangChain's Context Engineering for Agents is a good place to start. I'll jump straight to comparing how today's mainstream coding agents manage context, and explain why I chose a single agent as the "executor."

Auto-Compaction: One Executor — Conservative, Sensible, Simple

Claude Code and Codex, the two coding agents that lead the field by a wide margin in user count, both default to the same conservative, simple approach: when the conversation nears the context limit, perform a one-shot auto-compaction, summarizing the entire session into a synopsis and continuing with that synopsis as the new context. The drawback seems obvious: condensing a long conversation into a brief summary is bound to lose information… right?

The shortcomings of auto-compaction are not that straightforward. The real issue is that models currently lack the ability to summarize well — or rather, an agent carrying a long context struggles to figure out what an agent without that context actually needs. The information most often lost or distorted during compaction falls into two categories: on one hand, the decision-making process between user and agent during their conversation; on the other, the implicit decisions made while writing code. User intent and these implicit decisions are critically important during execution — they internalize unstated constraints that actually let the agent complete the task as the user expects. In practice, auto-compaction has trouble preserving this implicit knowledge. This appears to be an agent's version of the curse of knowledge.

The real mechanism is probably messier. If you use this feature often, you'll notice that conversation quality after a compaction is sometimes unexpectedly bad — the model seems to become irreversibly "dumber" in some way nobody has pinned down, possibly related to a break in the chain of reasoning within the synopsis.

Under these conditions, for long tasks that require auto-compaction — or span multiple compactions — the implementation inevitably drifts. The best we can do is reinforce auto-compaction through the system prompt. Claude Code has clearly designed for this: their compaction prompt requires all user messages to be listed in detail. This design preserves the user's decisions and their underlying intent as much as possible, going a long way toward easing the problem.

Multi-Agent Collaboration: Multiple Executors, Imitating Humans

Over the past few months, especially since Claude Code shipped its Agent Team feature, parallel multi-agent collaboration has become one of the hottest ideas in agent design. But this attempt to imitate the human way of working has not been a clear success.

First, in a multi-agent workflow, an exhaustive plan is merely the starting line for parallel work. Suppose we ask two agents to build two pages of the same app according to a plan that specifies style, features, fonts and more — but can't possibly nail down every implementation detail, or the context cost of planning alone would exceed that of just building the thing. The result: for the same list-loading pattern, one page uses a skeleton loader while the other uses a spinner; for the same input fields, one uses small-radius corners while the other uses large-radius ones, each reinventing the wheel. Each page seems fine on its own, but stitched together, the inconsistent interactions and visuals wreck the user experience.

The communication system between agents is the hardest part. Humans have no hard cap on context, and we think and work slowly enough that communication fits naturally into the gaps. But every message an agent receives is permanently written into its context, and because agents execute so fast, communicating mid-task becomes extremely difficult — in practice, communication can almost only happen during planning. When several agents sync their decisions, every message is stored in every agent's context, plus each agent's responses and evaluations. Context burns far faster than actual work is produced. The more thoroughly they communicate, the less room each agent has for real work. The worst case: an agent's context fills up mid-collaboration, triggering auto-compaction, and it rejoins the shared task with a damaged memory — not only degrading its own work, but potentially spreading an incorrect understanding to the others. Don't communicate, and the pieces don't fit together; communicate, and the context for real work disappears fast. This is the fundamental dilemma of parallel collaboration under the agent architecture.

So which parts of human collaboration are actually worth borrowing? Humans communicate, divide work, then each do their own share. I'll return to the "communication" part in Good Sub-Agents Don't Write Code. What we've established above is that parallel execution is extremely difficult in agent systems. What about dividing the work and then executing serially?

Droid tried exactly that.

Sequential Execution by Plan: Multiple Executors, Working in Silos?

Droid's Mission feature takes a plan-first, serial-execution approach. An Orchestrator (the architect) discusses and works out a detailed plan and acceptance contract with the user. Once the plan is set, a separate Runner executes according to it: dispatching a Worker for each subtask node, and at each milestone sending an independent Validator to review the stage.

The first problem with this kind of architecture is still the loss of implicit knowledge. Can the intent behind decisions, and the implicit constraints they carry, be conveyed perfectly through the plan to a Worker? Can the next Worker truly understand the implicit decisions made by the previous one? No plan covers every detail. A Worker will inevitably make judgment calls the plan never mentioned — choosing a particular data structure, or picking between two equivalent approaches. These decisions and their reasons are never explicitly passed to the next Worker, yet they shape its work. Without this implicit knowledge, each Worker works in its own silo: the code runs, but it builds poorly on what came before, and Workers sometimes make outright contradictory design choices.

Once drift happens, correction is expensive. A Worker is assigned a specific subtask; even if it notices something worth improving in earlier work, it won't change course — that's not its job. Worse, when an earlier Worker's implementation has already partly deviated from the plan, later Workers see the existing code, treat it as authoritative, and build on top of it, compounding the drift. The Orchestrator only gets feedback through Validators at milestones; by the time it spots the problem, several Workers may have piled up a lot of code in the wrong direction, making contract rewrites and rollbacks costly. Moreover, Validators can only review code against the plan — if a Worker's or Validator's own interpretation of the plan conflicts with the Orchestrator's actual intent, the Orchestrator usually finds out too late. Rewrite the entire contract to fix it? Or accept a less-than-perfect result?

Another lurking issue is over-engineering. To keep a complex, easily derailed multi-agent architecture under control, Droid nails down nearly every step that can be nailed down and wraps the entire flow in hard constraints. When a Worker finishes — whether normally or because it has an issue to escalate — it doesn't raise the question in its output the way most projects do; instead, the handoff goes through the returnToOrchestrator field of the EndFeatureRun tool (the system makes the transfer automatically; the Runner never decides), with a structured summary written into the handoff. The heavyweight design clearly improves runtime stability and keeps the system running for long stretches, but heavy process has its price: it increases cognitive load on the model (different models with different capabilities and working styles may respond very differently to the same harness), and limits flexibility — everything must be planned and contracted first. All of this guarantees stable execution. None of it guarantees a better implementation.

Still, Droid's Mission feature remains the most sensible multi-executor design available today. Serial execution sidesteps the worst chaos of parallel collaboration, and the heavy process really does keep the system running for hours without crashing.

While I was writing this post, Claude Code shipped Dynamic Workflows / Ultracode. This is a fairly dated approach — something like a lightweight, customized, dynamic LangGraph, with plenty of prior art behind the idea. It solves none of the problems above, including the loss of implicit knowledge and the inability to course-correct mid-run (the flexibility problem). In particular, its orchestrate-once, dispatch-and-wait mechanism strips away most of the flexibility an ordinary multi-agent system has. The script may contain branches and while loops, and the number of agents dispatched can depend on a list returned by a sub-agent at runtime, but the orchestration route itself must be locked in before each run. Once a sub-agent is dispatched, all that connects it to the main agent is a one-shot return value — no mid-run communication, no negotiation. In other words, to avoid "communication chaos" eating context, it simply forbids the main agent from intervening during execution. This leaves it in an awkward spot as a multi-executor system: its process constraints fall well short of Mission's, and its flexibility falls short of Agent Team's.

The one apparent benefit is that orchestration overhead stays out of the main agent's context. That makes the system valuable in only a few scenarios, such as automating high-quality code review (dispatch several Reviewers across different parts of the code, then pair each with an adversarial agent for cross-examination). But the stubbornly high cost makes this a poor deal.

Fermi's Self-Compaction: One Executor, More Flexible, Still Unproven

Whether it's single-agent auto-compaction or multi-agent orchestration, the problem they face is the same: can implicit knowledge be carried across intact? Today's models don't seem to be good at this — they tend to fixate on details while letting the decision logic behind them slip. This is why a Worker, or Executor, needs a single persistent brain, as intact as possible, throughout the task.

So in Fermi, I introduced self-compaction tools to help a single executor handle long-horizon tasks. To prevent whole-session compaction from damaging user intent and the reasoning built up during planning, Fermi compresses at a much finer grain — down to a single tool call — so that critical reasoning and conversation stay untouched while less important parts get compressed aggressively. For example:

• Compress oversized tool calls and tool results, distilling the few pieces that future work will actually need
• In auto-research tasks, after each exploratory experiment, compress the detailed process — scripts, runs and all — keeping only the experimental idea, a brief description of the script, the results, and any insights useful for future experiments
• When a change touches several parts of a large repository, compact after finishing each part or batch of parts

This way, Fermi avoids compressing the discussions with the user, preserves the decision process as fully as it can, and keeps implicit constraints from being lost. Currently, Fermi's self-compaction comes in two forms:

1. The user runs /summarize manually, selects a range of consecutive turns (a user message and the corresponding agent actions and output), and can provide custom compression instructions.
2. Fermi compresses on its own, but this is restricted to within a single turn — user messages cannot be compressed, and Fermi cannot compress across user messages.

Plenty of open questions remain:

• Can the agent soundly judge what deserves compression? Can it avoid compressing too much or too little? Can it choose the right moment?
• Can it write a summary that preserves what will actually matter later? This is auto-compaction's problem all over again, just at a smaller scale
• Every compaction breaks some prompt-cache hits, so frequent compaction costs extra money
• A bad compaction can't be undone. Worse: once the wrong context is gone, the agent is even less likely to realize the compaction was wrong, so it can't correct course

Good Sub-Agents Don't Write Code

So far, the most effective way to use sub-agents is to keep them from modifying code directly, and let them handle everything else:

• Sub-agents are a natural fit for exploration. They spare the main agent from over-exploring a repository it doesn't know yet, with all the excess file searching and reading that entails. An Explorer does that work in the main agent's place and hands back just the clean result the main agent asked for.
• Sub-agents also make excellent Reviewers. An independent Reviewer catches more blind spots in an implementation.

As Walden Yan of Cognition notes in Multi-Agents: What's Actually Working, sub-agents work surprisingly well as Reviewers, especially when they share no context at all with the executor. He attributes it to two factors: the Reviewer is forced to reason backward from the implementation rather than following a spec or user instructions, and context rot in a long context. But there may be another factor: LLM training emphasizes tightly reasoned problem solving and likely seldom asks the model to find its own mistakes (labs want a model that writes the best code on the first try, not one that writes then self-corrects). This makes it harder for the model to find bugs in its own code than for an independent Reviewer to do so — in other words, a difference in LLM behavior depending on whether the code arrived as role="assistant" or role="user".

• In human collaboration, "communication" is more than just settling on a plan — we often complement each other and even arrive at better ideas through discussion. The same applies to agent collaboration. During the brainstorming phase of planning (especially for complex plans), spinning up multiple sub-agents to plan in parallel makes sense. Since most providers set their backend temperature to 1.0, proposals from multiple sub-agents tend to complement one another, and for complex engineering tasks they usually beat a single agent's one-shot plan, with fewer blind spots.
• Consulting: run the work on a weaker model and consult a stronger one when the problem gets hard. Anthropic has a relevant article demonstrating the approach's effectiveness, but the difficulty is that the agent running the weaker model needs to know when to consult and provide the right context. Too frequent, and the premium model's token cost outweighs just using it outright; too infrequent — meaning "not knowing what it doesn't know" or providing poor context — and the approach doesn't help either. Amp's Oracle takes the same path. Counterintuitively though, in my experience, even models that aren't stronger — same tier, slightly weaker, or even the exact same model — often have consulting value. When an agent can't locate a problem, opening a fresh session to target that problem specifically can often find and fix it quickly. This is likely the combined effect of different sampling distributions across models and a clean context, and it's one of the places where sub-agents genuinely shine.

It pays to configure different models for sub-agents. Fermi exposes three configurable tiers, and when the going gets tough the main agent automatically picks the Tier-High model for the sub-agent. My usual setup: main agent on DeepSeek V4 Pro max, High on Codex/GPT 5.5 xhigh, Medium on DeepSeek V4 Pro max, Low on Codex/GPT 5.4 mini.

• There's one more special approach worth noting: when spawning a sub-agent, pass it the full context of the current process (or the context minus tool results), so the sub-agent gets the complete train of thought and user intent. Two concrete ways to do it:
  • Wrap the context up as a single block and pass it into the sub-agent (similar to an auto-compaction summary, just as a semantically system-sourced message that enters the assembled context as role="user"). This saves tokens since tool results can be omitted.
  • Fork the main agent outright, then pass a system prompt saying "you are a forked agent."

Taken further, the main agent could keep forking itself all the way through, executing each subtask directly — maybe that's a viable approach too? Since no compression or handoff is needed, implicit knowledge is never a problem. Codex already does this; Fermi will support it soon.

Closing Thoughts

"There must be exactly one executor"… or must there? Multi-executor systems aren't wrong by nature. It's just that the bottleneck of today's models lies in the unreliable transfer of implicit knowledge — whether handed to a "future self" through auto-compaction, or to another agent through collaboration. Under this bottleneck, a single executor plus clean-context helper agents (exploration, review, consulting) is the most dependable design. If models ever shake off the curse of knowledge, most of this post can be rewritten. Until then — protect the executor's brain.