How Many AI Agents Do You Need

The Sizing Factors

Four factors determine the optimal number of agents for a given system: task complexity, domain diversity, parallelism opportunities, and coordination cost tolerance.

Task complexity refers to the number of distinct steps required to complete the workflow from start to finish. A simple classification task has one step and needs one agent. A content production pipeline with research, outlining, writing, editing, and formatting has five distinct steps and could benefit from up to five agents. Each step becomes a candidate for a dedicated agent, but not every step warrants its own agent because some steps are simple enough to be combined with adjacent steps without quality loss.

Domain diversity measures how many different types of expertise the workflow requires. If every step requires similar skills (all writing, all analysis, all coding), fewer agents are needed because a single well-prompted agent can handle related tasks effectively. If the steps require fundamentally different skills (one step needs legal expertise, another needs financial analysis, a third needs technical writing), each domain warrants a specialist agent because the prompts and tools for each domain are different enough that combining them degrades quality.

Parallelism opportunities exist when multiple steps can execute simultaneously because they do not depend on each other. If your workflow can process five independent data sources at the same time, five parallel agents can complete the work roughly five times faster than a single sequential agent. However, the parallel agents all need to be coordinated through a synchronization barrier, adding complexity that must be weighed against the latency benefit.

Coordination cost is the overhead of managing communication, handoffs, and state synchronization between agents. Each additional agent adds coordination cost: more routing decisions, more handoff points, more potential failure modes, and more tokens spent on context transfer. At some point, the coordination cost of adding another agent exceeds the quality or speed benefit it provides, establishing the practical upper limit on agent count.

Common Configurations

Two-agent systems are the simplest multi-agent configuration and work well for tasks that benefit from a clear separation between generation and evaluation. A writer agent produces content, and a reviewer agent checks it against quality criteria. A coder agent writes code, and a tester agent validates it. The two-agent pattern is easy to build, easy to debug, and provides meaningful quality improvement over a single agent at minimal coordination cost.

Three-agent systems add a coordinator (or router) to the two-agent pattern. The coordinator classifies incoming requests, dispatches them to the appropriate specialist, and packages the results. This configuration handles task variety well because the coordinator can route different request types to different specialists without each specialist needing to handle the full range of inputs. Three agents is often the sweet spot for systems that need specialization without the complexity of larger agent teams.

Five-agent systems are common for production workflows that have distinct phases. A typical five-agent configuration includes a router, two to three domain specialists, and a quality assurance agent. This allows meaningful specialization across different task phases while keeping the coordination graph simple enough to debug and maintain. Many enterprise deployments operate with five to seven agents per workflow.

Ten-plus agent systems are used for complex enterprise workflows that span multiple departments or require deep specialization across many domains. Customer service platforms, document processing pipelines, and software development assistants often use ten to twenty agents organized into hierarchical teams with department-level supervisors and a top-level orchestrator. These systems require significant engineering investment in monitoring, debugging, and coordination infrastructure.

The Diminishing Returns Curve

Agent count follows a diminishing returns curve where each additional agent provides less marginal benefit than the one before it. The first specialist agent you add to a single-agent system typically provides the largest quality improvement because it addresses the most significant bottleneck. The second specialist provides a smaller but still meaningful improvement. By the time you add the fifth or sixth specialist, the improvement from each new agent is modest.

Meanwhile, coordination cost grows roughly quadratically with agent count because each new agent potentially interacts with every existing agent. The intersection of the diminishing benefit curve and the growing coordination cost curve defines the optimal agent count. Beyond this point, adding more agents actively degrades system performance because coordination overhead exceeds the specialization benefit.

In practice, most teams find this intersection at three to seven agents for a single workflow. Systems with more agents typically organize them into hierarchical sub-teams of three to five agents each, with coordination happening within sub-teams and only summary information flowing between sub-teams. This hierarchical structure keeps per-team coordination costs manageable while allowing the overall system to include dozens of agents.

A Practical Sizing Framework

Use this framework to determine the right agent count for your system. First, list every distinct step in your workflow. Second, group steps by skill domain, combining steps that require similar expertise and tools. Third, count the number of groups. This is your starting target for agent count. Fourth, assess whether any group would benefit from being split further because it handles tasks that are too diverse for a single focused prompt. Fifth, assess whether any groups should be merged because they are small, similar, and not individually complex enough to justify a dedicated agent.

After this analysis, your agent count should fall between three and seven for most workflows. If your analysis suggests more than seven agents, look for opportunities to create hierarchical sub-teams rather than a flat arrangement. If your analysis suggests fewer than three agents, verify that a multi-agent approach is warranted at all, because a two-agent or single-agent system might be simpler and equally effective.

Validate your sizing decision by building a prototype with the planned number of agents and testing it against representative tasks. Measure quality, latency, and cost. Then experiment with adding one more agent and removing one agent, measuring the same metrics. If adding an agent does not improve quality or if removing an agent does not degrade quality, adjust your target accordingly. Let empirical results guide your final agent count rather than theoretical analysis alone.