When One AI Agent Stops Being Enough

Most organizations that adopt AI agents start with one, asking it to plan, write, review, secure and document because that is simpler to set up and easier to explain to a board. It works well at a small scale. It becomes a liability once the scope grows: more systems, more files, more decisions running through the same narrow context window.

This is not a prompting problem. It is an architecture problem, and it has a well-established answer: stop asking one agent to do everything, and build a small team of specialists coordinated by an orchestrator instead. The pattern is not niche. It is how the research system at Anthropic is built, with a lead agent distributing work across subagents.¹

The limits of one general-purpose agent

A generalist agent holding the full context of a complex environment has to divide its attention across all of it on every task. As scope grows, so does the context the agent must hold, and quality tends to degrade in predictable ways. A bigger context window does not fix this on its own: models retrieve information from the start and the end of a long input far more reliably than from the middle, and the gap widens as the input grows.² Tasks take longer to complete. Output becomes inconsistent between similar requests. Checks that matter, such as security, GDPR compliance and documentation, happen only when someone remembers to ask for them, rather than on a fixed schedule.

None of this means the underlying model is weak. It means the operating model around it is wrong. The same limitation shows up in human teams: one generalist cannot review code, audit security, manage a project and maintain documentation to the same standard as four people who do each of those things full time.

Splitting work into specialist roles

The fix is decomposition. Instead of one agent covering every concern, the work is split into a small number of scoped roles, each with a narrow mandate, a defined deliverable and its own quality bar.

In our own delivery and research operations, we run this pattern with five roles. Each request goes first to the Planner, which decomposes it into tasks. Next comes the Reviewer, checking only for defects and standards violations. A security and risk auditor grades exposure. A cleanup role removes dead code and enforces hygiene. A documentation role keeps written material aligned with what was actually built.

Where the pattern applies beyond software

The same logic extends well beyond engineering teams. A document processing pipeline can split into extraction, verification against rules and exception handling. A customer-facing assistant can split into intent handling, escalation and review of anything compliance-sensitive before it reaches a customer. A finance or procurement workflow can split into drafting, checking against policy and audit logging. In every case, the principle is the same: narrow the scope of each role until its output is easy to check.

Orchestration, not autonomy

A common misreading of this pattern is that it means deploying several autonomous bots that act independently. It does not. Each specialist is a scoped instruction set, a mode with its own constraints and output format, that a central orchestrator switches into depending on the task at hand. The orchestrator decides what happens next and which specialist handles it. Nothing runs unsupervised simply because it has a role label.

This distinction matters most in regulated environments, where the AI Act requires human oversight of high-risk systems and “autonomous” is a word that invites scrutiny.³ A well-designed swarm behaves like a structured workflow with AI performing each step, not like a collection of independent decision-makers.

Where human acceptance points belong

Splitting work into specialist roles carries a governance benefit that is easy to overlook: it makes human review points easier to place. A single agent that plans, builds and ships in one pass gives a reviewer one large, mixed output to check. A swarm produces a narrower, more legible output at each stage, so an acceptance point can sit exactly where a decision has consequences: before a security-relevant change goes live, before a customer-facing message is sent, before a document classification is finalized.

For leadership teams accountable to a board, a regulator or an audit function, this is often the deciding factor over any raw efficiency argument. It is also the language AI management standards speak, ISO/IEC 42001 foremost among them: documented oversight counts, an assurance that the system is safe does not. The question is rarely whether AI can do the work. It is whether someone can explain, after the fact, what it did and why it was allowed to proceed.

Cost and quality: what actually changes

Splitting one agent into several specialists costs more than intuition suggests. Anthropic reports that a multi-agent system burns around 15 times more tokens than an ordinary chat, while measuring 90.2% better performance than a single agent on its own internal research eval.¹ The maths works out where the result is worth that gap, and against you on tasks a single agent closes on the first pass. The rest of the cost shifts earlier, into the design of roles, the handoffs between them and the orchestration logic that ties them together. That upfront investment buys a system that is easier to test, easier to audit and easier to improve one role at a time, without retraining or re-prompting an entire generalist agent every time one part of the process changes.

The quality argument follows the same logic as with any specialized team. A reviewer whose only job is to catch defects catches more of them than a generalist doing five jobs in the same pass, simply because its attention is not divided.

What costs the most on a first swarm

The most expensive part turns out to be settling exactly what one role hands to the next. Model and orchestrator costs are secondary to it. As long as the planner output is a loose description, the reviewer receives something that cannot be checked mechanically, and the whole benefit of the split disappears: somebody is again reading everything and judging by eye.

So a first swarm is worth building from the handover format rather than from the number of roles. Three things are enough to start: a named field for task scope, a named field for the acceptance criterion, and a slot for the verification result. Roles can be added later; the handover format is the hardest thing to change.

The second trap is organisational. A swarm with five roles and a single human acceptance point at the very end delivers exactly what a general-purpose agent delivers, only at higher cost. The acceptance point belongs where the decision is irreversible, not where the run happens to finish.

For leaders running AI beyond a single pilot, the question worth asking is not whether to add more AI, but whether the current architecture can support what the organization is already asking it to do. RS Management designs and builds multi-agent systems for clients and applies the same discipline to its own operations. If you are assessing whether your AI systems need this kind of restructuring, we welcome the conversation.

Footnotes

1. Anthropic, description of its multi-agent research system with measurements of the gain over a single agent and of token usage: https://www.anthropic.com/engineering/multi-agent-research-system. ↩ ↩²

2. Liu et al., measurement of model accuracy against the position of the relevant information in the context: https://arxiv.org/abs/2307.03172. ↩

3. Regulation (EU) 2024/1689, Article 14 on human oversight of high-risk systems: https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng. ↩