concepts

Mission Sizing

A candidate must satisfy at least 3 of 5 criteria to qualify as a Mission:

CriterionWhat It MeansLitmus Test
Multi-agentRequires 2+ distinct profiles/toolsWould a single agent choke on this?
Multi-sessionExpected to span multiple chat sessions or Kanban lifecyclesWould it survive a human going to sleep and returning?
Multi-objectiveHas 2+ distinct outcomes that must be achievedCan you describe "done" in 3+ independent statements?
Coordination requiredOutcomes have dependencies, sequencing, or parallel pathsDoes order matter? Can some work run in parallel?
Method ambiguousThe "how" is not obvious; mission command is neededWould a competent builder need significant judgment calls?

Examples of real missions

Hardening authentication end to end, migrating frameworks, security audits, building a public site, implementing an observability stack.

Examples of tasks

Rewriting a README, fixing an auth bug, reviewing a PR, researching best practices, updating dependencies.

The test: If you gave this to one agent with one /goal, would they succeed? If yes, it is a task. If no, because they lack expertise, add a reviewer. Still a task. If no, because it requires coordination across systems, sessions, or tools, it is a Mission.

Sizing is advisory, never enforced. The operator decides; the system informs the decision and respects it.

Structural Limits

The architecture makes five things structurally possible and four things structurally impossible.

Possible

  • Intent-driven automation: human writes intent, system decomposes.
  • Persistent multi-session execution: the board survives restarts, crashes, and session boundaries.
  • Observable agency costs: every card generates rows in task_runs; the After-Action Review is a view of the database.
  • Composability without lock-in: any tool that speaks /goal can join.
  • Human-in-the-loop governance: the “blocked” state is residual control made operational.

Impossible

  • Opaque black boxes: decomposition is visible before execution.
  • Unbounded delegation: budgets gate every card.
  • Single-tool lock-in: the Flight Plan compiles to universal primitives.
  • Fire-and-forget automation: the system expects supervision, and the Flight Plan makes that expectation explicit.