How it works

What this is

A visual, interactive mock of how a hierarchical multi-agent system decomposes and executes a task.

No LLM is called. Every prompt, trigger, and payload you see is canned data; timings and branching are randomized to imitate real concurrent orchestration. The point is to make the mechanics legible — what work flows where, what fires each hand-off, and what messages pass between levels — not to produce a real result.

The example task is a competitive research brief on “AI note-taking apps,” chosen because it splits cleanly into independent sub-goals.

The hierarchy — 1 → 3 → 6

Ten nodes in three tiers. Each tier only talks to the tier directly above and below it:

• Orchestrator — decomposes the task into 3 independent sub-goals, fans them out, then merges the returned results into one deliverable.
• Agents A / B / C — each receives one sub-goal, splits it into 2 subtasks, dispatches to its subagents, and merges their outputs.
• Subagents (6) — do the actual leaf work, each stepping through a short sequence and returning a result.

Lifecycle — the phases

A run moves through five phases; the code panel on the main page highlights the active one live:

• plan — the orchestrator reads the task and derives 3 sub-goals.
• dispatch — it hands one sub-goal to each agent (a trigger: orchestrator.dispatch → agent:A).
• work — all 3 agents run concurrently; each fans out to its 2 subagents, which also run concurrently. This is the fan-out: await Promise.all(...) at both tiers.
• aggregate — as each agent's subagents finish, the agent merges their results and reports up (handoff ↑ to orchestrator).
• synthesize — once all agents report, the orchestrator assembles the final brief.

Prompts, triggers & payloads

Every node carries three things you can inspect (click any node on the main page):

• Prompt — the instruction that node "receives." The orchestrator's is a decompose-and-merge system prompt; an agent's scopes it to one sub-goal; a subagent's is a single concrete task.
• Trigger — the event that started it, e.g. orchestrator.dispatch → agent:B or agentA.dispatch → sub:A1. Triggers are how control flows down the tree.
• Payloads — the structured JSON passed on each hand-off: a task-assignment object going down ({ goal, subtasks }) and a result object coming up ({ status, merged }).

The message log on the main page records every hand-off in order; click any line to expand its full prompt, response, and payloads.

How it maps to a real system

The shape here mirrors real hierarchical agent runtimes: an orchestrator that decomposes and delegates, worker agents that own sub-goals, and subagents that execute in parallel and report back. In a real build, each "prompt" would go to a model, each "payload" would be an actual tool/agent message, and the fan-out would be genuine concurrent inference. Here it's all simulated so the orchestration pattern is easy to see and reason about.

Under the hood

Plain, dependency-free static files — open agent-sim.html directly, no build step, no network:

• agent-sim.html — page structure; loads the others.
• styles.css — all styling (dark theme, node states, panels).
• sim-data.js — the scenario: every node's prompt, trigger, and JSON payloads, plus the code shown in the code panel.
• sim-app.js — the vanilla-JS engine: builds the tree, runs the async orchestration, updates the inspector / log / code panel.