Open Mission is a local-first control system for AI-assisted software delivery. It gives coding agents a governed workflow, isolated workspaces, durable artifacts, and a human operator above the automation.

Start Here · Start a Mission · Why Open Mission Exists

Promise What it means
Safe by design Agent work runs in isolated Mission worktrees instead of your active branch
Structured delivery Work moves from brief to requirements, spec, implementation, verification, audit, and delivery
Runtime freedom Workflow stays stable while agent adapters remain replaceable adapters

Open Mission exists because raw AI coding is fast, but fast is not the same thing as governable. A long chat session can drift from the architecture, rewrite the wrong files, lose context, sound confident without proof, and leave the human trying to reconstruct what happened from terminal scrollback.

Open Mission turns that into an operation. Each Mission owns its workflow, state, artifacts, tasks, and command surface. Agent adapters execute bounded work underneath that control layer.

The practical promise is simple: use AI speed without giving up architectural discipline, repository safety, or human control.

How It Works

Instead of one open-ended session working directly on your checkout, Open Mission gives each unit of work a governed path:

  1. adopt a Repository and record its Mission control state
  2. start a Mission from a brief or tracked issue
  3. create an isolated Mission worktree
  4. move through staged artifacts and tasks
  5. launch Agent executions with bounded context
  6. verify, audit, and deliver with evidence

Open Mission is the operator surface for that flow. Workflow Control shows the legal commands, Agent Execution hosts owner-scoped live execution, and artifacts stay in view.

What Mission Protects

Risk Mission response
Agent work corrupts the main checkout Work happens in isolated Mission worktrees
Context turns into one fragile chat Work is split into artifacts, stages, tasks, and sessions
UI state becomes truth The daemon owns runtime state and Entity behavior
Provider details leak inward GitHub, Git, and agent adapters sit behind adapters
Verification becomes self-reported Gates require artifacts and operator-visible evidence

Why Teams Use It

Open Mission is for teams that want agents to move quickly inside a system that still feels like serious engineering. It is useful when you care about:

  • protecting the main checkout while agents explore and edit
  • keeping requirements, implementation, verification, and audit separate
  • making progress recoverable after crashes, restarts, or runtime failures
  • keeping humans in charge of launch, pause, stop, rework, and delivery
  • preventing provider-specific details from becoming your workflow model

The system is opinionated because the failure mode is real: AI accelerates both good architecture and bad architecture. Open Mission tries to make the disciplined path the easiest path.

For the broader motivation, read AI Technical Debt, including the IBM and Matt Pocock talks that shaped this framing.

Core Vocabulary

  • Repository: the local checked-out Git repository used as the base for Mission work.
  • Mission: a long-lived unit of engineering work with a brief, workflow state, artifacts, tasks, and agent executions.
  • Running Mission instance: the daemon-owned Entity that applies workflow law while a Mission is live.
  • Mission artifact: a tracked operator-facing file produced or consumed by the Mission.
  • Agent execution: a daemon-owned run of one Agent under an explicit System, Repository, Mission, Task, or Artifact owner reference.
  • Open Mission: the operator surface for reading and steering the daemon-owned system.

The full domain glossary lives in CONTEXT.md. ADRs explain why the architecture is shaped this way.

Start Reading