how it works
How It Works
The Full Flow
missions.md is a human-facing layer over primitives Hermes Kanban already ships. You write a one-page Flight Plan. The system decomposes it into cards, routes them to agents, verifies outcomes against your criteria, and gives you a debrief.
The flow
IDEA → define-mission → Flight Plan (one page — the only thing you write)
|
launch-mission
├─ pre-flight Go/No-Go checks (automatic)
└─ kanban_create ×N → Hermes fleet executes
|
debrief-mission
└─ task_runs → After-Action Review (the proof)What the System Leans On
missions.md builds no orchestration tech. It is a pattern language over what already exists.
| Mission need | Hermes primitive |
|---|---|
| Sequencing and parallelism | `kanban_create(parents=[...])` with dispatcher auto-promotion |
| Verification against acceptance criteria | `goal_mode=True` (judge re-checks each turn) |
| Human gates | `kanban_block()` / `/unblock` |
| Budgets | `goal_max_turns`, token/time limits |
| The audit trail and AAR data | `task_runs` in SQLite |
| Recovery from stuck workers | `reclaim` / `reassign` |
Structural Limits
The architecture makes five things structurally possible: intent-driven automation, persistent multi-session execution, observable agency costs, composability without lock-in, and human-in-the-loop governance.
It also makes four things structurally impossible: opaque black boxes, unbounded delegation, single-tool lock-in, and fire-and-forget automation. You cannot launch a mission without seeing its decomposition. A runaway agent exhausts its budget and blocks for human review. If a worker tool changes, you swap the profile. The Flight Plan does not change.