Reasoning roles
Bounded model calls that run today through the shared MCP interface. Inspect these in the live workflow section below.
FIVE SYSTEMS. SEE HOW THEY WORK.
Watch the work move.
Pick a piece. Play a run. Watch agents share work, check results, and hand over the next artifact.
THE SHARED IDEA
One clear request → Defined roles → Visible handoffs → A reviewable result
A front-row seat
inside the swarm.
Follow the highlighted roles and the artifact at each handoff.
Model role Controller Artifact Active nowClick a role to inspect it
THE CURRENT SCENE
WHAT CHANGES HANDS
What you gain
What still needs care
Go deeper: architecture, specialists, and functionsFull graphs, exact contracts, failure paths, source references, and the complete runtime.
Full graphs, exact contracts, failure paths, source references, and the complete runtime.
01 / INSIDE THE MACHINERY
The whole system.
Every moving part.
Explore the controllers, specialist contracts, dependencies, artifacts, and failure paths behind each piece.
Orchestration machinery
Local engines, ledgers, and fixture workflows in each repository. The atlas below shows their deeper mechanics and exact scope.
Role designs
Documented specialist charters are included where they exist. A proposed role is labelled separately from an implemented worker.
New to the terminology? Start here.
- Agent / specialist
- A role with a specific job, input, and output. Some are model calls; others are ordinary controller code.
- Workflow / DAG
- A dependency graph: steps can run only when their required earlier results are accepted. Independent branches may run together.
- Controller
- The code that admits work, enforces limits, launches roles, and records results.
- Gate
- A condition that must pass before work continues, such as valid evidence or an unchanged candidate.
- Receipt
- A structured record of what was requested, attempted, produced, and accepted.
- Fixture
- A controlled demonstration with predetermined inputs and expected outputs. It exercises mechanics without a real reasoning agent.
- Snapshot / hash
- A saved version of data and a fingerprint of its exact contents. Matching fingerprints establish identity, not truth or usefulness.
- Reconciliation
- Resolving what actually happened after interruption before deciding whether it is safe to continue.
02 / THE SHARED LIVE CONTROLLER
Before, between,
and after the agents.
The visible model roles are only part of a run. This is how the current MCP runtime admits work, supplies evidence, dispatches roles, and records what happened.
Runtime limits and operational boundaries +
03 / THE LIVE MODEL GRAPHS
Meet the roles in a live run.
These are the current MCP model workflows.
Click a role to inspect its reasoning contract.
Selected roleGrouped roles are independent; available workers determine concurrency.
Read the complete workflow
“Agent swarm,” made concrete. Here, an agent is a bounded model role. The controller follows a defined workflow. Roles can share a model; more roles do not automatically mean more providers or better results.
04 / CHOOSE THE RIGHT AMOUNT OF SYSTEM
Start with the work.
Then choose the piece.
Extra roles should solve a real problem.
Complexity has to earn its place.
A practical routing aid, not a performance prediction.
What changes when you add a workflow?
Benefits are design goals. Test whether they help on your own tasks.
| Consideration | One assistant | One chess system | Several systems together |
|---|---|---|---|
| Best fit | Clear, bounded work | A specific need for perspectives, dependencies, or reviewA project with several distinct kinds of work||
| How work moves | One conversation; the person directs | A fixed graph of model rolesA host or person connects system outputs||
| What you gain | Low coordination overhead | Explicit intermediate work and reviewDifferent workflow strengths across a project||
| What you pay for | Manual checks and follow-ups | More model calls, repeated context, and waitingMore handoffs, integration work, and failure points||
| What still needs you | Evidence and acceptance | Evidence and acceptanceEvidence, acceptance, and orchestration
The simplicity principle follows Anthropic’s workflow guidance ↗. System-specific details come from the installed implementations.
05 / THE FULL WORKFLOW
Five strengths.
One shared brief.
A worked example: build a volunteer scheduling website.
Follow the artifact as it moves between systems.
A composed example. These systems run independently. A person or host coordinates the handoffs shown here. The page simulates the process; it does not launch agents.
06 / BUILT WITH THE PIECES
The method,
used on this very page.
All five systems were asked to contribute.
These receipts distinguish completed work from attempts.
The original build used all five live systems. This expanded edition adds source audits of all five native packages and the shared runtime, with architecture maps, function contracts, and illustrated execution traces.
Under the hood: capabilities, limits, and sources +
Capability snapshot and implementation audit: 23 October 2026 · MCP interface 0.3.0. Configured routes and availability can change. Counts refer to workflow stages and exclude optional model-qualification calls. Illustrative outputs are examples, not real project results.
Use the smallest system
that makes the next move clearer.