Agentic SRE Advanced By Samson Tanimawo, PhD Published Apr 18, 2026 5 min read

The Coordinator Agent Pattern: When You Actually Need One

Coordinators add latency and cost. The signals that you actually need one, and the simpler patterns that work most of the time.

Signals you need a coordinator

More than 3 specialists involved in a single workflow. Below that, code-based orchestration is simpler.

Dynamic dependencies: which specialist runs next depends on what the previous one found. Static orchestration cannot express this.

Multi-step plans that branch: plan A pursues one path, plan B another. The coordinator picks per-run.

Pipeline: agent A → agent B → agent C, fixed order. A function call chain in code; no coordinator needed.

Fan-out: agent A → (agent B, agent C, agent D in parallel). Code-based; no coordinator.

Conditional: if the result of A is X, run B; else run C. A switch statement; no coordinator.

A coordinator is itself an LLM call. Adds latency: 1-3 seconds per coordination decision.

Adds tokens: the coordinator has to read the state of all sub-agents. Tokens grow with the number of sub-agents.

Adds failure modes: the coordinator can mis-route, deadlock, or loop. Eval and observability are required.

The coordinator's only job is routing. Not reasoning, not analysis, not action.

Coordinator input: the goal, the available specialists, the current state. Output: which specialist to invoke next, with what scope.

Coordinator does not see specialist internals. It reads only the structured output of each specialist.

Read-only by default. The coordinator can route but cannot act. Specialists do the acting.

Bounded loops. The coordinator can iterate up to N times; beyond that, escalate. N is small (typically 5).

Eval the coordinator separately. Its routing decisions are first-class outputs that need their own test suite.