Missions & the Critic Loop

When the router decides a command is real work, it becomes a Mission. A Mission is a self-healing unit of background execution — it runs in isolation, reviews its own result, and retries before it ever reports back to you.

Isolation by default

• Every worker runs in a fresh git worktree on its own branch, under a dedicated outputs directory. It never writes to your working tree.
• Every worker subprocess is wrapped so that if the orchestrator crashes, the worker is killed with it. No zombie processes.

That isolation is what makes it safe to let a worker try, fail, and try again without touching your repository state.

The Worker–Critic loop

Worker produces output  →  Critic reviews it  →  pass?  →  signed result
                                  │
                                  └─ no → correction → retry (up to 3×)

1. The Worker does the task and produces an output.
2. The Critic reviews that output against the goal.
3. If it falls short, the Critic issues a correction and the Worker tries again — up to three times.
4. A separate signer approves the final result before anything is spoken.

The retry ceiling is fixed at three. It is deliberately not configurable — changing it is an architectural decision, not a setting.

You only hear the verified result

A strict invariant separates the model’s self-talk from what reaches your ears: the spoken readback reads only the signed, approved summary — never the Critic’s raw correction instructions, never the worker’s intermediate reasoning. The model never narrates its own unverified observations.

Zero silent drops

Every worker or tool failure results in exactly one of three outcomes: a silent retry, a spoken correction at the next turn boundary, or an audited apology. Nothing fails quietly.