Agent Orchestrator Animation: Watch a Multi-Agent Workflow Actually Run

What an agent orchestrator actually does

An agent orchestrator is the control plane between one human request and a set of narrow, replaceable agents. It is not a smarter agent sitting in the middle; it is the part of the system that owns sequencing. In one sentence: it turns a sentence from you into work orders, enforces who may do what, and returns a single result instead of a transcript.

That last row is the one most teams skip, and it is the row that decides whether the swarm is useful. A reviewer that can edit its own findings is a second coder. A critic that only advises is decoration. The orchestrator pattern works because every role has one job and one direction of authority.

The eight frames, step by step

This is the run in the animation above, written out. It is short on purpose — if a workflow needs eleven agent roles to explain a two-line change, the workflow is the problem.

1. You file the task

   One sentence, no plan, no folder of context. “Add a size-guide link to the product page.” Everything downstream assumes the operator does not know the codebase.

2. The orchestrator plans

   It picks the method (here, test-first), splits the request into work orders, and decides what can run in parallel. Planning is the only step that is allowed to be slow.

3. Explorer recon (read-only)

   A read-only agent locates the size selector, the layout component and the existing tests. It returns findings, not patches. Read-only is enforced structurally, not by good intentions.

4. Coder writes the diff

   One work order plus the explorer's findings, in an isolated worktree. A coder that receives two work orders returns two half-finished changes.

5. Test engineer, in parallel

   The assertion is written before the implementation lands — the test is the specification, and it fails first. This is the step that turns “it seems fine” into evidence.

6. Reviewer reads the frozen diff

   The diff is snapshotted before review. The reviewer has no write access, so review cannot quietly become a rewrite.

7. Critic veto

   A separate gate with one power: stop. If it vetoes, the work never reaches you — which is the point. Attention is the scarcest resource in the system.

8. Merge and one report

   The orchestrator merges, closes the task, and sends a single summary. Not raw logs, not a chain of thought, not a scrollback you have to re-read.

The bottleneck nobody draws

Here is the uncomfortable part that an animation makes obvious. Spawning more agents does not add throughput when the model endpoint admits a fixed number of requests at once. In our stack the admission layer allows four in-flight requests; the team cap is twenty agents. Spawn fifteen agents against four slots and eleven of them are not working — they are waiting, holding context, and burning the coordination budget.

Two different ceilings get confused constantly. The slot pool limits model requests in flight. The agent cap limits how many workers a team may run. A well-behaved swarm sizes itself to the slot pool and lets the agent cap be headroom for bursts, not a target.

The practical consequence: if your orchestrator can spawn twenty workers but your endpoint admits four, the correct configuration is a small team with fast handoffs. Latency per handoff beats parallelism that has nowhere to run.

Five rules that keep a swarm honest

What the animation reveals about failure

Because every edge is explicit, failures become visible as missing or looping traffic:

• The orphaned work order. A packet leaves the orchestrator and no node lights up. That is a spawn that silently failed — invisible in a static diagram.
• The bypassed critic. Work reaches “report to you” without passing the veto node. In practice this reads as a suspiciously confident summary.
• The cap mismatch. Agent counters climbing while slots stay saturated — the queue above, drawn honestly.
• The silent stall. A node stays active forever. Timeouts must live in the orchestrator, not in the worker's optimism.

How the animation is built

No framework, no charting library, no animation dependency. One SVG, one stylesheet, one small script — roughly 12 KB total, and it respects prefers-reduced-motion.

.edge.hot {
  stroke: #4b5c78;
  stroke-dasharray: 6 5;
  animation: dash 1s linear infinite;   /* marching dashes */
}
@keyframes dash { to { stroke-dashoffset: -22; } }

.pkt.run {
  offset-path: path("<copied from the edge>");
  animation: travel 1.15s ease-in-out infinite;
}
@keyframes travel {
  0%   { offset-distance: 0%;   opacity: 0; }
  12%  { opacity: 1; }
  88%  { opacity: 1; }
  100% { offset-distance: 100%; opacity: 0; }
}

The packet is a single <circle>. On each frame the script copies the current edge's d attribute into offset-path, which makes the dot follow the exact curve the edge already draws — no second geometry to keep in sync. Nodes light up by toggling a class; the progress list, meter and busy counter are plain DOM updates.

• Autoplay pauses off-screen. An IntersectionObserver stops the timer when the figure scrolls away, so the page costs nothing while you read.
• Manual control wins. Pause, next frame and replay are real buttons with focus styles — the animation is a diagram you can step through, not a video.
• Reduced motion is honoured. With motion off, frames advance only on button press and the packet is hidden; no content lives inside the animation alone.
• Text carries the meaning. Every frame has a heading and a sentence in the HUD, and the whole run is repeated as an ordered list below — good for screen readers and for search engines.

Frequently asked questions