EXPERIMENT_020 // DECLARATIVE.MULTI-AGENT.ROUTER
Submit a task and watch a real LLM call route it against a declarative task-shape-to-capability table, dispatch that route's real sub-agent calls in sequence or parallel, and render a live trace of the decision and every sub-agent's actual output — not a diagram of how routing could work, but routing that runs.
LOADING EXPERIMENT...
Type a task — a bug report, a content review, a research question, a design review — or click one of four preset examples, one per route. A real LLM call classifies the task against a small declarative routing table (task-shape to sub-agent capability) and picks a route with a stated reason. That route's two or three sub-agents then run for real, sequentially or in parallel depending on the route, and a React Flow canvas renders the router and each sub-agent updating live — pending, running, complete — as the calls actually resolve, alongside a plain-text transcript of every real output.
HOW IT WORKS
Four routes live in one routing-table module, each pairing a plain-language task-shape description with two or three sub-agent definitions (role, system prompt) and an execution mode. The router LLM call sees only the table's id/label/description fields and picks one — the routing logic is data, not branching code, so adding a fifth route means adding a table entry, not a new code path.
The routing decision is a genuine `client.structured()` call (via `@diabolicallabs/llm-client`) against the task text, not a keyword match — and the chosen route's sub-agents are genuine `client.complete()` calls, not scripted responses. Temperature is left non-zero on both calls deliberately: re-submitting the same task can legitimately produce a different route or different sub-agent phrasing, which is the point — a scripted demo could never show that.
The API route streams a TraceEvent over SSE the instant each real step happens — the moment the router decides, the moment each sub-agent starts, the moment each sub-agent's call resolves. The React Flow canvas recomputes its node/edge layout from that running state on every event, so a sub-agent node visibly moves from pending to running to complete as its own call finishes, not all at once after the whole run ends.
Two routes run sequentially (each sub-agent receives the prior one's real output as context — a root-cause analysis feeding a patch proposal) and two run in parallel (independent perspectives dispatched together, each rendered as soon as it resolves via a completion-order generator rather than `Promise.all`). Both modes are declared per-route, not hardcoded per-experiment.
WHAT THIS PROVES
A multi-agent router can be genuinely declarative — task-shape-to-capability as data — without collapsing into either a hardcoded dispatch table or an opaque agent-picks-anything free-for-all. The routing table constrains the LLM's choice to a fixed, auditable set of routes while still requiring a real classification call to pick between them.
A live multi-agent trace is a different engineering problem from a finished multi-agent result: streaming per-step SSE events into a canvas that re-renders on each one demonstrates the difference between an orchestration diagram (EXP_007, EXP_008) and an orchestration that actually ran, with the sequencing and timing of real calls visible as they happen.