Too Many Agents, Too Little Delivery

A roster of executive agents, specialist agents, reviewers, and escalation roles can look disciplined. Every risk has a title. Every title has instructions. That arrangement can create the appearance of rigor without establishing a path to completed, accepted work. This is the design risk examined here, not a reconstructed incident log.

Consider a system that produces plans, reviews, and status faster than artifacts a human owner can use. Activity is something the system does. Coordination is the work required to keep those activities aligned. Output is an artifact produced. Verification checks that artifact against explicit criteria. Acceptance means the intended human or downstream system can actually use it. Only then can the work contribute to an outcome.

The lesson is not that multiple agents are inherently wasteful. It is that roles should follow the accepted deliverable. Framing work around a concrete output, an accountable synthesizer, and a visible acceptance test changes the design question from “Which agents should be on the team?” to “What is the smallest agent configuration that can produce an accepted, verifiable outcome?” That is a proposed change in approach, not a measured before-and-after result.

The case for specialization is not foolish. Organizations divide work because expertise, permission, and focus are real constraints. A product manager may reasonably want one agent to research, another to draft, a third to test, and a fourth to challenge the result. Review roles appear to create checks and balances. Parallel workers appear to compress time. A named specialist appears to protect every known risk.

The strongest opposing argument is that one agent cannot reliably carry every context, tool, policy, and evaluation rule for a complex program. Separating responsibilities can reduce prompt complexity, isolate sensitive access, improve tool selection, and let independent work proceed at the same time. In the right system, those are meaningful advantages.

The mistake is converting that reasonable argument into a presumption that every distinct concern needs a distinct agent now. A role name is not a capability boundary. Parallel prompts are not necessarily parallel work. A review step is not useful merely because it exists. Each additional worker creates a new interface: context must be selected, authority must be declared, state must be protected, output must be interpreted, and disagreement must be resolved.

EXTERNAL EVIDENCE External guidance points in the same direction without prescribing one universal topology. OpenAI recommends maximizing a single agent’s capabilities before adding agents because multi-agent systems introduce complexity and overhead. Anthropic similarly recommends starting with the simplest solution and increasing complexity only when the expected performance gain justifies the latency and cost. Those are design heuristics, not proof that one agent always wins.

An agent count alone cannot diagnose a workflow. A four-agent system with clean boundaries may outperform one overloaded orchestrator; a two-agent system can still loop indefinitely. The useful evidence is behavioral. Look for the relationship between coordination work and accepted output.

The signals below are diagnostic prompts, not a list of verified incidents from my work or universal proof. One occurrence may be appropriate—for example, a security review can correctly block an artifact. The pattern becomes concerning when coordination repeatedly consumes the capacity required to create, verify, and accept the deliverable.

The most revealing question is not “Are the agents busy?” It is “What changed in the state of the deliverable?” If the answer remains unclear after another plan, handoff, or review, the workflow is probably measuring motion instead of progress.

• 01More plans exist than completed artifacts.
• 02The same context is rediscovered or restated across workers.
• 03Several reviews begin before a reviewable artifact exists.
• 04Recommendations conflict and no accountable synthesizer resolves them.
• 05Status reports describe blockers without advancing or closing them.
• 06The human owner is interrupted for routine, reversible decisions.
• 07Authority boundaries remain implied, inconsistent, or contested.
• 08Agents review the same assumptions under different role names.
• 09Work continues without a defined terminal condition.
• 10Token, run, or handoff volume rises while accepted-output volume stays low.

The root-cause hypothesis is a sequencing error: beginning with a division of labor and trying to discover the product outcome through the resulting organization. That inverts the design problem. The sequence below is an analytical model to test, not a verified reconstruction of a particular run.

A delivery system should start with the result: who needs it, what form it must take, what evidence it must preserve, and what test makes it acceptable. Only then can the builder identify capability, context, permission, and evaluation boundaries that justify separation.

Specialization should follow a demonstrated coordination or capability need. It should not precede the product outcome. This is an interpretation of the opening reflection and a proposed operating rule—not a universal law about agent architecture.

1. 01

   Roles before outcomes

   The roster was designed before the accepted result and intended user were explicit.

2. 02

   Titles before output contracts

   Responsibilities sounded distinct, but required inputs, outputs, and formats were not.

3. 03

   Reviews before criteria

   Reviewers were added before the system defined what passing, revising, blocking, or abstaining meant.

4. 04

   Parallelism before boundaries

   Tasks ran at the same time even though they depended on shared context or mutated the same state.

5. 05

   Authority by implication

   No component clearly owned synthesis, conflict resolution, or the final declaration of completeness.

6. 06

   Activity before acceptance

   Runs, documents, and reviews were counted while usable, accepted results were not.

My default correction is a deliberately small topology: one accountable orchestrator, zero to three bounded specialists, one verifier after an artifact exists, and human intervention only for defined reserved matters, material trade-offs, or irreversible action. The range is a proposal for starting design, not an empirically optimal agent count.

The orchestrator owns problem framing, work decomposition, source-of-truth selection, synthesis, conflict resolution, final-output completeness, and terminal-state declaration. It may delegate execution, but it cannot delegate away the obligation to return one coherent result. When specialist outputs conflict, the orchestrator resolves the conflict or exposes the exact unresolved decision; it does not forward a pile of competing drafts to the owner.

A specialist is introduced for a boundary, not a title. A distinct tool or permission, genuinely separate expertise, a context that should not enter the main thread, safely parallel work, or an independent evaluation rubric can justify one. Renaming a prompt “Chief Strategy Agent” does not.

The verifier should evaluate an existing artifact against explicit acceptance criteria. Asking the same system to restate its assumptions under another persona may improve self-critique, but it should not be represented as independent verification. The verifier returns a legitimate terminal state—accept, revise, block, or abstain—with evidence tied to the artifact.

The human owner remains accountable for consequential outcomes. Reserve matters should be named in advance: irreversible changes, material risk acceptance, publication, spending, credential use, protected merges, production changes, or other decisions the organization chooses to retain. Routine, reversible execution should not require repeated owner intervention when the route is already authorized.