A Mission is not a prompt.
It is a unit of work, audit, cost and result. One Mission can carry several agents, environments, approvals and release attempts — and it survives disconnects, retries and restarts.
What every Mission carries.
Before anything expensive runs, the user sees the plan, the cost estimate, the permissions and the risk class.
Intent
A natural-language request, an issue, a pull request, an alert, a ticket or an API event.
Acceptance Contract
Versioned, measurable pass / fail / unknown criteria with an owner, created before implementation.
Risk Profile
Blast radius, reversibility, data sensitivity, customer impact and the approvals required.
Plan
A dependency-aware plan that can be edited before and during execution.
Execution
Multi-agent work with bounded tools, budgets and human checkpoints.
Verification
Independent checks that rebuild the change from the approved contract and challenge it.
Evidence Bundle
Sealed, signed artifacts that justify a readiness decision.
Release Plan
Strategy, metric gates, observation window and a prepared rollback.
Outcome
What actually happened in production, measured in the observation window.
Economics
Model, compute and storage cost, budget and the estimated infrastructure delta.
Criteria are fixed before the work starts.
A versioned contract with measurable pass, fail and unknown conditions, a named owner and an evidence source for each criterion. A Verifier cannot edit it after verification begins.
| ID | Category | Criterion | Evidence source |
|---|---|---|---|
| AC-01 | Functional | Functional behaviour matches the requirement | Acceptance tests |
| AC-02 | Functional | Operation is idempotent under retry | Fault injection run |
| AC-03 | Business | Business rules hold for edge inputs | Property-based tests |
| AC-04 | Compatibility | API stays backward compatible | Contract tests |
| AC-05 | Data | Existing data survives the migration | Restore rehearsal |
| AC-06 | Availability | No downtime for the consumer | Load and replay run |
| AC-07 | Security | Authorisation and audit are enforced | Security checks |
| AC-08 | Reliability | Retries and duplicate webhooks are safe | Idempotency checks |
| AC-09 | Performance | P95 latency stays inside budget | Performance regression run |
| AC-10 | Operations | Dashboards and runbooks are updated | Operational review |
| AC-11 | Release | Canary does not push error or failure metrics above their approved threshold | Live staged metric evaluation |
| AC-12 | Recovery | Recovery path is verified | Rollback rehearsal |
This is the shape of a real contract from the product: twelve criteria, each mapped to objective proof. Coverage is 12/12 mapped — and a criterion that needs residual risk approval says so out loud.
Twenty states, with invariants that cannot be skipped.
The state machine is held by deterministic services. A model can propose a transition; it can never quietly make one.
DRAFT → CONTRACTING → AWAITING_APPROVAL → PLANNING → READY → RUNNING → PAUSED → BLOCKED → VERIFYING → REWORK → EVIDENCE_READY → AWAITING_RELEASE → RELEASING → OBSERVING → COMPLETED → FAILED → ROLLED_BACK → CANCELLED → REJECTED → REOPENED
A release candidate is immutable in AWAITING_RELEASE.
The observation window is never shortened silently.
On cancellation, credentials and resources are revoked.
State is preserved: a Mission survives disconnects, retries and restarts.
Nine roles. Separation of duty, not a swarm.
Multi-agent orchestration is used only where separation improves quality, parallelism or verification independence. A simple task takes one cheap path.
Planner
Builds the dependency-aware plan and keeps it honest as facts change.
Builder
Produces the change. Cannot promote it to production without a gate.
Test engineer
Turns acceptance criteria into durable checks.
Reviewer
Reads the change against architecture and standards.
Security
Checks secrets, permissions, dependencies and supply chain.
DevOps
Owns environments, pipelines and the delivery path.
Verifier
Independent. Rebuilds from the contract, runs adversarial and hidden checks.
Incident
Correlates telemetry and proposes bounded remediation.
Coordinator
Deterministic arbiter of state transitions. An LLM never changes authoritative state.
- Multi-agent orchestration is used only where separation of duty improves quality, parallelism or verification independence. Simple tasks take one cheap path.
- The author of a change is never its only reviewer.
- A Verifier cannot edit acceptance criteria after verification has started.
- Agents communicate through structured artifacts: plan, hypothesis, finding, evidence request, decision proposal. A hidden, unauditable chat is forbidden.
- Every tool call is schema-bound, policy-checked, quota-limited, time-limited and audited.
Five places where a person decides.
Autonomy grows inside policy. These gates are where responsibility stays human.
Contract approval
The acceptance criteria and risk class are approved before any code is written.
Plan approval
The dependency-aware plan and its blast radius are reviewed.
Diff review
The change set is reviewable before it is applied, with granular accept and reject.
Release approval
The release candidate, gates and rollback plan are approved.
Emergency confirmation
Destructive actions and account-level changes require explicit confirmation.
Five things the organisation sets, six the scheduler must respect.
Priority, concurrency, deadlines, budgets and maintenance windows are the organisation's to decide. The scheduler's job is to place work around the constraints it cannot argue with.
Priority
Set by the organisation.
Concurrency
Set by the organisation.
Deadlines
Set by the organisation.
Budgets
Set by the organisation.
Maintenance windows
Set by the organisation.
Model capacity
The scheduler must account for scarce model capacity.
Sandbox region
The scheduler must account for the sandbox region.
Data boundary
The scheduler must account for the data boundary.
Repository locks
The scheduler must account for repository locks.
Deployment freeze
The scheduler must account for the deployment freeze.
Human approval availability
The scheduler must account for human availability for approvals.
Work on a Mission is shared, not forwarded.
A Mission is a place a team works in: ownership and mentions, review threads bound to a version, handoffs that carry their own context, and decision records that stay readable afterwards.
Shared Mission
Roles, ownership and mentions on one Mission, so it is visible at a glance who decides, who verifies and whose action is awaited.
Threaded review
Discussion on a plan, a change and a piece of evidence stays attached to the versioned object and survives an update.
Tracker and chat integration
Status syncs with issue trackers, chat and documentation systems without losing the source link or the authority behind it.
Decision records
An approved decision becomes an ADR with context, options, decision, consequences, owner and a supersession path.
Organisation standards
A Mission checks the standards and golden paths that apply to it, and explains any deviation.
Grounded documentation
Repository documentation cites the code and configuration behind every fact; a stale page is flagged and updated.
Reusable runbooks
Runbooks and playbooks are versioned, tested, scoped, and tied to an owner and a policy.
Asynchronous handoff
A handoff carries state, completed evidence, open questions, residual risk and the next action.
Conflict log
Disagreements between recommendations and human overrides stay visible for review instead of being smoothed away.
Knowledge export
Documentation, decision records, templates and metadata export in documented formats.
Repeatable work, not blank prompts.
Templates carry their own contract shape, checks and risk class — and they improve every time an escape is traced back to a gap.
Seven levels of context, with citations and freshness.
Retrieval returns the minimum relevant set. Stale, conflicting and low-trust knowledge is detected and shown as such, never silently trusted.
Immediate
The open file, the selection, the current task.
Repository
Symbols, dependencies, tests, history and ownership.
Organisation
Standards, decisions, golden paths, runbooks.
Delivery
Pipelines, environments, release state, change calendar.
Production
Telemetry, incidents, alerts, SLO state.
External
Documentation, advisories, dependency and provider status.
Personal
The developer's own preferences and saved context, kept local-first.
Every change keeps its thread.
The Release Outcome Graph links intent to criteria, change, evidence, release, production outcome and, when it happens, the incident — in both directions.
Intent → Acceptance criteria → Context snapshot → Change set → Evidence → Release → Production outcome → Incident → Learning
Deep Wiki
Generated architecture and service maps that stay current.
ADR Library
Proposed, approved and superseded decisions with owners.
Standards
Organisation standards a Mission must follow or explicitly justify deviating from.
Runbooks
Versioned, bounded, dry-run capable automation with approvals and audit.
Incident knowledge
What happened, what was missed, which check changed as a result.
Golden paths
The approved, safe self-service route to production.
One Mission from intent to outcome.
Pause, resume, cancel, retry or branch from a checkpoint — without losing state or doing anything twice.