Your Multi-Agent System Needs a Manager, Not More Agents

Unlike traditional single-agent LLM applications that rely on one model to handle all tasks, multi-agent systems distribute work across specialized agents. But as these systems grow more complex, developers often make a critical mistake: adding more agents when what they really need is better coordination.

The article by Russlan Ramdowar argues that scaling multi-agent systems horizontally by adding more specialized agents creates diminishing returns. Instead, introducing a manager agent to orchestrate existing agents produces better results with less overhead.

Coordination Approach

The manager pattern treats multi-agent systems as organizations rather than collections of independent workers. A manager agent sits above specialist agents, delegating tasks based on each agent’s capabilities and monitoring progress across the system.

This architecture differs from flat multi-agent designs where agents communicate peer-to-peer or follow rigid sequential workflows. The manager maintains context about which agents are working on what, preventing duplicate effort and ensuring that outputs from one agent feed appropriately into the next.

In practice, the manager agent receives the user’s request, breaks it into subtasks, assigns those subtasks to appropriate specialist agents, and synthesizes their outputs into a coherent response. This mirrors how human teams operate - individual contributors focus on their domains while a manager handles prioritization and integration.

Performance Characteristics

According to the article, manager-based architectures show improvements in task completion rates and response coherence compared to flat multi-agent systems. The manager reduces wasted API calls by routing requests only to relevant agents rather than broadcasting to all agents or following predetermined chains that may include unnecessary steps.

The approach also handles failures more gracefully. When a specialist agent produces an inadequate response, the manager can reassign the subtask to a different agent or request clarification, rather than propagating errors through the system.

For complex queries requiring multiple domains of expertise, the manager pattern prevents context loss that occurs when outputs pass through many agents sequentially. The manager maintains the full context and can reference earlier steps when formulating final responses.

Implementation Considerations

Building a manager agent requires defining clear interfaces between the manager and specialists. Each specialist agent needs a description of its capabilities that the manager can reference when deciding which agent to invoke. These descriptions function like API documentation, helping the manager understand what each agent can and cannot do.

The manager itself typically runs on a capable model since it handles reasoning about task decomposition and agent selection. Specialist agents can use smaller, faster models tuned for their specific domains - a pattern that balances cost and performance.

Developers should instrument manager decisions to understand routing patterns. Logging which agents the manager invokes for different query types reveals whether specialists are properly scoped or if the manager struggles with certain delegation decisions.

You coordinate specialist agents. Available agents:
- code_agent: writes and debugs code
- data_agent: analyzes datasets and statistics
- research_agent: finds and summarizes information

Given the user query, decide which agents to invoke and in what order.
"""

System Design Tradeoffs

The manager pattern adds latency since requests pass through an additional LLM call before reaching specialist agents. For simple queries that clearly map to one agent, this overhead provides little value. The pattern works best for ambiguous or multi-step requests where routing decisions matter.

Manager agents also introduce a single point of failure. If the manager misunderstands a request and routes it incorrectly, the entire system produces poor results even if specialist agents work correctly. Robust prompt engineering for the manager becomes critical.

Cost increases with the manager layer, though this may be offset by more efficient agent utilization. A well-designed manager invokes fewer agents per query than systems that broadcast to all agents or follow fixed pipelines with unnecessary steps.

The architecture requires more upfront design work to define agent boundaries and capabilities clearly. Teams must resist the temptation to create overlapping specialists or managers that try to do specialist work themselves.