How it works
One mission, watched from the outside
This page follows a single realistic change through MUON: adding idempotency keys to a checkout charge path so a retried request cannot bill a customer twice. It is a small feature with a real blast radius, which is exactly where a crew earns its keep.
The mission
Play it beat by beat
Keyboard: Space plays or pauses, the left and right arrow keys step one beat, R replays from the start, and the timeline slider scrubs directly.
Sample mission · simulated replay · repository acme/payments-service
Add idempotency keys to the checkout charge path so a retried request cannot charge a customer twice.
Crew
- Claude Codecoordinate
Mission coordinator
Waiting for dispatch
main0 tok - Codexwrite
Implementer
Waiting for dispatch
muon/idempotency-keys0 tok - Cursorread-only
Explorer
Waiting for dispatch
read-only checkout0 tok - OpenCoderead-only
Reviewer
Waiting for dispatch
review worktree0 tok
Mission log
Waiting for the mission to start.
Your desk
No decision needed
The crew works inside the authority you already granted. You are called back only when a gate opens.
Blast radius
Memory recalled
Use the timeline to step through it. The crew panel on the left shows what each agent is doing and what it has spent. The log in the middle is the mission record. The panel on the right is your desk, and it only asks for you when a gate opens.
The eight steps
What happened, in order
Every mission follows the same shape, whether it takes three minutes or three hours. The parts that change are the size of the crew, the gates that apply and the evidence the work produces.
01
You state the outcome
One sentence describing what should be true when the work is done. You can pin the crew, cap the spend or leave both to the superagent inside the envelope you approved.
02
The superagent plans the crew
It reads the brain for prior decisions on the code you named, sizes the crew against the work, and writes a role contract for each agent it is about to dispatch.
03
Agents claim their scope
The writing agent takes a git worktree and a file claim. No other lane can edit those files while the claim is held, so parallel work stops producing surprise conflicts.
04
The pre edit gate opens when it should
A change reaching a public route, a payment boundary or another sensitive edge stops for you first, with the blast radius and the prior decisions attached.
05
The crew corrects itself while running
The explorer finds a second caller. That message reaches the implementer immediately and changes the work in flight, rather than becoming a review comment tomorrow.
06
A different vendor reviews the diff
The reviewer reads the change against the constraints recorded for that path. Using a different model for review is how you catch the mistakes a model is fond of making.
07
Checks run and evidence is attached
Tests, types and migrations run, and the results attach to the run rather than living in a scrollback buffer somebody has to find.
08
You merge, and the record keeps the reason
The merge decision is yours. Afterwards the whole run can be replayed from the ledger, including which memories were used and which are waiting for you to confirm.
After the run
The mission leaves something behind
A finished mission is not just a merged branch. It is a record that makes the next mission cheaper and the next review shorter.
Why the change looks like this
The reason for the idempotency key, the alternative that was rejected and the caller that forced a second edit are all recorded against the symbols they touch.
Two claims waiting for you
Crew vouched claims sit in your queue. Confirming one takes a moment and turns it into context every future mission receives automatically.
The whole run, reconstructable
Sessions, messages, context frames, checks and gates are all in the ledger. A run can be replayed months later without the original terminals.