Focus Is the New Bottleneck: Why You Can Only Run as Many AI Agents as You Can Control

AI agents can increase implementation throughput, especially when work can be divided into independent, well-specified tasks. They also create decomposition, context, tool-access, review, integration, and incident-response work. The useful question is not how many agents a person can run in theory. It is how much concurrent work the team can verify and integrate within its risk tolerance.

There is no evidence-based universal ceiling such as two, five, or ten agents per operator. Capacity varies with the work, model, tools, codebase, tests, permissions, operator, and consequence of error. Treat concurrency as a measured operating parameter. When agents belong to different people, orchestration also becomes an identity, consent, and delivery problem; our cross-owner agent communication guide covers that trust boundary.

What changes when generation gets faster?

Faster generation can move the constraint without removing it. Teams may spend less time drafting code and more time deciding what should change, supplying context, controlling tools, reviewing behavior, resolving conflicts, and proving that the result meets requirements. The balance differs across routine edits, novel architecture, security-sensitive work, and ambiguous product decisions.

Do not assume that the hardest work is a fixed percentage or that one operator now outproduces a particular team size. Measure completed, accepted outcomes. Generated lines, tool calls, or agent turns are activity metrics and can rise while cycle time, quality, or maintainability worsens.

When does parallelism help?

Parallel agents are most promising when subtasks are genuinely independent, inputs and outputs are explicit, tools do not contend for shared state, and integration can be checked cheaply. An orchestrator-worker pattern can also help when the necessary subtasks are not known in advance. Anthropic's account of its own research system describes benefits for breadth-first queries along with coordination, evaluation, reliability, and cost challenges. Its reported benchmark and speed results are specific to that system and workload, not a universal multiplier. See the original multi-agent research engineering report.

Sequential work is often safer when tasks share files, schemas, stateful environments, migrations, credentials, or an unresolved architecture decision. Parallelism can still be introduced after the interface and integration tests are stable.

What creates an orchestration ceiling?

NIST notes that generative AI may require different levels of oversight, human-AI configuration, review, tracking, documentation, and management depending on context. That supports risk-based supervision, not a fixed operator-to-agent ratio. See the NIST Generative AI Profile.

How do you measure safe concurrency?

Start with one workflow and a representative task set. Establish the sequential baseline, then increase concurrency one step at a time while holding task mix and acceptance criteria as stable as practical. Record:

• time from ready to accepted, including review and rework;
• review-queue age and time spent by role;
• first-pass acceptance and escaped defects by severity;
• merge conflicts, duplicated work, rollbacks, and incidents;
• tool, model, infrastructure, and human cost per accepted outcome;
• permission exceptions and unsupported completion claims;
• operator workload and handoff continuity.

Stop increasing concurrency when total accepted throughput flattens, review or integration queues grow beyond the service target, or risk indicators breach the agreed threshold. Re-run the measurement when the model, tools, permissions, codebase, test suite, or task mix changes.

What should every delegated task contain?

1. Objective: the concrete outcome and why it matters.
2. Boundaries: files, systems, people, data, and actions in or out of scope.
3. Inputs: authoritative sources, current state, assumptions, and dependencies.
4. Permissions: allowed reads and writes, approval points, and prohibited actions.
5. Output contract: artifact, format, ownership, and how partial failure is reported.
6. Acceptance: tests, review criteria, evidence, and rollback or recovery path.
7. Handoff: state changed, decisions, unresolved risks, and the next safe action.

Clear delegation reduces duplicated exploration and missing coverage. It does not guarantee correctness, so completion evidence must be checked against the real system rather than accepted from the agent's narrative.

How should context and handoffs work?

Context should be sufficient and scoped, not merely short or reset on a timer. A fresh agent without the current constraints can repeat old mistakes; an overlong context can bury the governing requirement. Keep durable state in versioned artifacts where possible: plans, decisions, interfaces, test results, and recovery notes. Summaries should distinguish verified facts, assumptions, open questions, and work actually applied.

Use explicit state transitions such as pending, in progress, needs attention, completed, and verified. An agent message is not proof that a change exists or passes. Inspect the artifact and run the relevant checks before downstream work depends on it.

Can reviewer agents replace human review?

Reviewer agents can add an independent pass, test hypotheses, or inspect a different risk class. They can share blind spots with the producing model, miss environment behavior, or optimize for an incomplete rubric. Use them as one control, not as proof that the output is correct or safe.

Human review should be proportionate to consequence and should focus on intent, architecture, security, privacy, user impact, and exceptions that automated checks do not cover. Google Cloud's multi-agent reference architecture similarly emphasizes human oversight, defined autonomy, observability, and continuous evaluation. See its multi-agent architecture guidance.

"The useful agent count is the concurrency your team can verify and integrate within its risk tolerance. Measure it from accepted outcomes, not activity."

How do we apply this on engagements?

Wavect does not use a universal two-agent default, a five-agent maximum, a four-hour review cap, or a fixed experience threshold as a public delivery promise. We set work-in-progress limits from the task graph, review ownership, tool and data access, tests, integration surface, and consequence of failure. Those limits can change within an engagement as evidence changes.

Before adding parallel workers, we want bounded tasks, isolated ownership where practical, a visible review queue, explicit handoffs, and checks that cover the important contracts. For higher-risk changes, we add approval gates and deeper human review. This is an operating approach, not evidence that defects cannot escape.

What does this change in hiring?

Agent-enabled work increases the value of decomposition, domain judgment, verification, security, debugging, communication, and recovery skills. It does not make typing irrelevant or establish that the most valuable engineer is the person who can supervise five agents. Roles should be assessed against the work and risks they actually own.

For fractional technical leadership, this can include choosing where agents are appropriate, defining permissions and evidence, establishing evaluation and review loops, and measuring whether automation improves accepted delivery. See our fractional leadership service.