Don't Let Your Agents Hire Managers

A team deploys three agents. They step on each other. The natural response: add an orchestrator to coordinate them. Now there are four agents. The orchestrator needs to understand what each agent can do, what each agent needs, and how to route work between them. The orchestrator becomes the most complex component in the system.

Two months later, the orchestrator is overloaded. It is doing too much routing, too much error handling, too much state management. The natural response: add a second orchestrator to handle a subset of the work. Now there are five agents and two orchestrators. The orchestrators need coordination.

This is not a hypothetical. I have seen this trajectory play out in every multi-agent system that treats orchestration as the fix for coordination failures.

The Pattern That Keeps Repeating

Distributed systems engineering hit this wall fifteen years ago. Microservices proliferated. Services called services called services. The response was to add service meshes — infrastructure layers that managed service-to-service communication. The service mesh handled routing, retries, timeouts, and load balancing.

Then the service meshes needed configuration management. Then the configuration management needed its own monitoring. The community called this "service mesh creep" — layers of coordination infrastructure added to manage coordination infrastructure.

Every distributed systems scaling crisis produces the same failure: adding coordinators to fix coordinator overload. The microservices community spent a decade learning that the fix is better service boundaries, not more service mesh. Multi-agent systems are compressing that decade into months.

The parallel is exact. An agent that needs an orchestrator to function is an agent with ambiguous boundaries. The orchestrator compensates for the ambiguity. Adding more orchestrators compounds the compensation without addressing the cause.

What Coordinator Debt Looks Like

I call this Coordinator Debt: the accumulated complexity from orchestration layers added to compensate for boundary failures in the agents beneath them.

Coordinator debt manifests in three ways:

Routing complexity. The orchestrator contains a growing set of rules about which agent handles which request type. These rules encode the boundary decisions that should have been made when the agents were designed. As new cases emerge, the routing rules grow. The orchestrator becomes a shadow specification of every agent's scope.

Error propagation. When an agent fails, the orchestrator must decide what to do. Retry? Route to a different agent? Escalate? Each decision adds a branch to the orchestrator's logic. The orchestrator's error handling becomes more complex than the agents' primary logic.

State leakage. The orchestrator holds state that belongs to the agents. It tracks which agent is processing which request, which requests are pending, which have failed. This state should live with the agents themselves. When it lives in the orchestrator, losing the orchestrator loses the state of every in-flight request.

Why "Just Add an Orchestrator" Feels Right

Orchestration is seductive because it works immediately. Agent A and Agent B are duplicating work? Add a coordinator that routes requests to one or the other. Problem solved — until Agent C arrives and the routing rules triple.

The immediate fix obscures the structural cost. Each orchestration layer adds latency, adds a failure point, and adds cognitive load for anyone maintaining the system. More critically, it defers the hard work: defining what each agent owns, what each agent does not own, and how agents communicate at their boundaries.

Every coordinator you add is a confession that the agents beneath it have ambiguous scope. The coordinator does not fix the ambiguity — it manages it. The debt compounds because managed ambiguity grows faster than managed complexity.

The Boundary Discipline Fix

The alternative is not "no orchestration." Orchestration is necessary for workflows that span multiple agents. The alternative is orchestration that coordinates well-bounded agents rather than compensating for poorly-bounded ones.

Three principles:

Explicit contracts. Each agent declares what it accepts, what it produces, and what it does not handle. The agentic contract is a specification, not a prompt. When the contract is explicit, routing decisions are mechanical — no orchestrator intelligence required.

Rejection over routing. An agent that receives a request outside its scope should reject it with a typed error, not silently pass it upward. Rejection surfaces boundary violations at the point of failure. Routing hides them in the orchestrator's logic.

Local state. Each agent owns the state for its in-flight work. The orchestrator knows which agents are active but not what they are doing. If the orchestrator fails, agents continue processing. If an agent fails, only its work is affected. This is the durable execution principle applied to multi-agent coordination.

When Orchestration Is Load-Bearing

Orchestration is necessary when the workflow requires sequencing that no single agent can own. A pipeline where Agent A's output feeds Agent B, which feeds Agent C, needs something to manage the sequence. That something is a workflow definition — not a smart coordinator, but a state machine that advances through defined stages.

The distinction: a workflow engine advances through stages. A coordinator makes decisions. Coordinator debt accumulates from decision-making coordinators, not from workflow engines. The state machine says "after A completes, run B." The coordinator says "look at A's output and decide whether to run B, C, or retry A." The first is infrastructure. The second is complexity.

Orchestration is necessary for complex workflows. Orchestration used to compensate for poorly-scoped agent boundaries is Coordinator Debt — and it compounds. The fix is not better coordinators. The fix is agents that do not need them.

I keep asking teams the same question before they add a coordinator: what boundary failure am I compensating for? If the answer is "the agents don't have clear scope," the coordinator is debt. Fix the boundaries. The agents will coordinate themselves.

Related Reading:

• The Agentic Contract — why a prompt is not a specification
• Conservation of Chaos — why coordination costs compound as agent count grows
• Durable Execution — designing agent work to survive crashes and restarts