Gates are human approval through the inbox, a review pass or an eval pass. Loops are bounded, for example `on_fail: { goto: build, max: 3, then: escalate }`.
- Plan artifact
A versioned artifact with goal, approach, steps, acceptance criteria, risks and open questions. Humans edit it through the inbox; agents propose edits, which go to the inbox for approval. Stored on the server and attached to merges with git notes, never committed. A plan-conformance review profile compares the diff with it.
- Eval stages
Report pass or fail per acceptance criterion of the plan.
- Task intake
Pick a workflow, fill its inputs (a brief, attachments, linked GitHub issues, handoff bundles from other tasks), and optionally override vendors, models, prompts or review profiles per stage.
- Mid-task swapping of stage vendors, models, prompts and review profiles
At any point a human can swap a stage's vendor, model, prompt or review profiles, and add, remove or reorder the stages of the task's frozen workflow.
# M6 — Fan-out
-`export_context` and handoff bundles
An `export_context(purpose)` MCP tool producing a bundle with the goal, decisions made and why, current state, dead ends tried, open questions and relevant files. Used for cross-vendor forks, stage-to-stage handoff, and the durable record of a task. Compaction already writes the same contents.
Forking a snapshot into a different vendor: the new session starts from a handoff bundle from `export_context` instead of the vendor's native fork, and the UI labels it a handoff, not a true fork. Same-vendor forks from a snapshot exist (see "Forking" in `docs/operations.md`).
`spawn_stages(stages[])` and `collect(stage_ids[])` MCP tools let agents build workflows on the fly, using the same stage definition format. An optional per-workflow human gate on spawning. Spawned stages show in the task's UI tree marked as just-in-time, and a just-in-time structure can be saved as a reusable workflow.
