For most of the past two years, the default mental model for AI agents looked like this: one agent, one task, one context window. That worked fine for short, well-scoped jobs. For anything genuinely ambitious — a full codebase review, a multi-source research synthesis, an end-to-end pipeline that needs to handle hundreds of inputs — it quietly fell apart. The agent would lose the thread, cut corners near the end of a long run, or rate its own output too generously. These were not bugs that better prompting could fix. They were structural.
The response emerging from the field is a shift toward multi-agent architectures: instead of one agent doing everything, a lead agent plans the work and fans out to a fleet of sub-agents, each running in its own isolated context. This is not a new idea — it mirrors how large human organisations handle coordination problems — but it is only now becoming practical to implement at the API level without writing a lot of custom orchestration scaffolding.
Why a single agent hits a ceiling
Three failure modes explain most of the frustration practitioners have logged with single-agent runs on hard problems.
The first is what might be called agentic laziness: after seeing many healthy results early in a run, an agent starts assuming the rest are fine too and stops checking. A fleet model counters this by giving each item its own dedicated agent, so no single run accumulates enough evidence to justify coasting.
The second is self-preferential bias: an agent that generates output and then reviews it tends to rate it highly. The fix is isolation — a separate reviewer agent that never saw the generation process and has no stake in its quality. This is a direct parallel to code review: the person who wrote the code is the last person who should be the only one reading it.
The third is goal drift: in long runs, the original constraints (the ones that actually matter — “do not touch production”, “stay within budget X”) get compressed out of the agent’s context window over time. Distributing work across sub-agents means each sub-agent receives the original goal intact, not a compressed summary of it several layers down.
What changes when the fleet is the unit
When the unit of work shifts from a single context window to a coordinated fleet, several things become possible that were not before.
Different phases of a task can run on different models matched to what each phase actually needs — a faster, lighter model for high-volume scanning, a more capable model for the review step. The cost tradeoff is real: fleets spend more tokens, and that is worth understanding before committing to the pattern. But the quality gap on complex tasks can be substantial enough to justify it.
Adversarial review becomes a first-class primitive. One agent generates; a separate agent critiques, in isolation, with no shared context. This is the architectural equivalent of a red team, and it applies beyond code: investment memos, research synthesis, content moderation, anything where the risk of uncritical acceptance is high.
Visibility becomes more tractable, not less. A common concern with multi-agent systems is that they become opaque. The countervailing case is that a well-structured fleet with a durable event stream — one that logs every tool call, every handoff, every sub-agent transition — is actually more auditable than a single agent run whose reasoning is buried in one long context. The debugging surface is larger, but it is also more structured.
The coordination analogy that holds up
The Linux kernel maintainer model is worth holding in mind here. Linus Torvalds reached a personal scaling limit in 1998 — too many patches, too many contributors, one bottleneck. The response was a layered trust network: subsystem maintainers who owned their domain and vouched for what went upstream. Today the kernel incorporates work from thousands of contributors across hundreds of organisations. No single person reviews everything. Coordination does not require central omniscience; it requires clear scope, clear interfaces, and a mechanism for surfacing what actually needs escalation.
Multi-agent AI architectures are solving a structurally similar problem. The constraint is not intelligence — it is context, attention, and the limits of what any single process can hold without losing track of the important things.
What this means in practice
The pattern is not yet the default, and the tooling is still new enough that the ergonomics will keep improving. A few things are worth keeping in mind when evaluating whether a fleet approach fits a given problem.
The cost goes up. Budget management — capping spend per session, pausing rather than discarding when a limit is hit — needs to be a first-class concern, not an afterthought.
Safety architecture is non-trivial. Prompt injection from external content, credential exposure in sandboxes, agent overreach beyond assigned scope: these risks compound in a fleet. The principle of separating the inference layer from the action layer — so credentials are never present in plaintext where the agent operates — is worth taking seriously from the start.
For tasks that are genuinely parallel, genuinely long, or genuinely adversarial in structure, the fleet model is a better fit than trying to scale a single context window. The practice is still developing, but the direction looks durable.
Text summarized and optimized using Anthropic’s models and reviewed by a human.