Scope: original public experiment. I built the application workflow and interface.
Use it to explore:
- Separate requirements, failure cases and tests for a fictional software project.
- Inspect how parallel work is combined and how partial failure should be reported.
- Plan
- Parallel work
- Collect
- Synthesize
What happens inside
A planner proposes up to three independent subtasks. Async worker tasks report completion as it happens. A judge synthesizes the collected results. Each stage is sent to the browser as an event.
Decisions and tradeoffs
Bound the fan-out
A three-worker ceiling limits the scope of a public example. More agents are not automatically better answers.
Show each worker's state
Completion order can differ from planning order. Explicit queued, running, completed and failed states make that difference visible.
Keep partial failure honest
If a worker fails, the result should say the synthesis is incomplete. Failed output is not successful evidence.
Illustrative example
Walk through an illustrative task split
A fictional URL-shortener design is split into requirements, failure modes and verification. This is an authored walkthrough, not a recorded model run.
- Plan
A three-worker ceiling limits the scope of a public example. More agents are not automatically better answers.
- Parallel work
Completion order can differ from planning order. Explicit queued, running, completed and failed states make that difference visible.
- Collect
If a worker fails, the result should say the synthesis is incomplete. Failed output is not successful evidence.
- Synthesize
If a worker fails, the result should say the synthesis is incomplete. Failed output is not successful evidence.
Engineering walkthrough / Executed protocol fixtures
Completion order is part of the design.
A planner creates tasks in one order. Network-bound workers may finish in another. The handler keeps worker identities separate from completion order, then waits for all required results before asking for a synthesis.
plan → create_task × up to 3 → as_completed → collect by ID → judgeSuccessful execution
The real handler ran against authored provider responses with controlled delays. The failure-mode worker finishes first, followed by verification and requirements. These are workflow tests, not measured model latency or answer-quality results.
- plan
- worker_startRequirements
- worker_startFailure modes
- worker_startVerification
- worker_doneConsider duplicate requests and expired destinations.
- worker_doneTest retries, expiry, and missing destinations.
- worker_doneDefine idempotent writes and bounded redirects.
- judgeProtocol fixture: combine requirements, failure modes and tests.
- done
What happens when a worker fails?
The failed worker remains visible. The handler skips the judge and ends with an error. It does not ask a model to hide the missing work inside a polished synthesis.
- plan
- worker_startRequirements
- worker_startFailure modes
- worker_startVerification
- worker_doneWorker unavailable.
- worker_doneTest retries, expiry, and missing destinations.
- worker_doneDefine idempotent writes and bounded redirects.
- errorAt least one worker failed; synthesis skipped.
Why the cleanup matters
Worker tasks are cancelled and awaited in a finally block when the stream exits. A browser disconnect must not leave unrelated local tasks running unnoticed. A request already accepted by an external provider may still finish.
The next operational boundary
This experiment has no persistent queue or recovery after process death. Those are deliberately different requirements; Spec Review shows durable jobs and fenced recovery.
Download the executed fixture trace (JSON)What this does not establish
The workers generate text; they do not execute arbitrary tasks on your behalf. The experiment does not establish that a swarm outperforms a single model. It has no durable job history.
Try a live run
Live requests send your prompt to OpenRouter and the selected model provider. Use public, non-sensitive material. Read how demo data is handled.
Checking live availability…
Technical walkthrough reviewed September 2026. Examples do not imply client adoption or production maturity.