Live Runbook Canvas

One living, human-readable status artifact that an agent maintains across a long, multi-step effort — every task, its state, the blockers, the decisions, and the learnings. It is the shared source of truth that lets the human glance at status and lets the agent re-ground itself after its own context is compacted.

A live runbook is the orchestration analog of Agent Operations Skills. Where an activity log is the agent's private append-only memory, a runbook is the shared dashboard for one bounded effort (a launch, a migration, a multi-PR refactor): the agent owns it and keeps it current, the human reads it to stay oriented without re-asking. It externalizes the state of work that would otherwise live only in the chat scrollback — which is exactly the state that disappears when the conversation is summarized.

Why it earns its keep

The value is concentrated in long-running, many-moving-parts work where no single chat turn holds the whole picture:

• It survives context compaction. Chat history gets summarized; a file on disk does not. After a summarization the agent re-reads the runbook and recovers the precise state — which PRs merged, which are green, what blocked — instead of trusting a lossy summary. This is the Context Engineering payoff: durable state lives outside the context window.
• One glanceable status for the human. Instead of asking "where are we?" across a multi-day effort, the human opens one artifact. This is Staying in the Loop with Agents applied to project state rather than code comprehension.
• It records decisions and their rationale, not just status — merge order, inter-task dependencies, why a path was chosen — so the reasoning is not lost between turns or agents.
• It cuts re-derivation. The agent consults the runbook rather than re-scanning every task each turn (re-listing 20 PRs, re-checking CI). Cheaper and less error-prone.
• Blockers have a home. Active blockers and their resolution sit in a dedicated callout, so a transient failure is not rediscovered three turns later.

Anatomy

The pattern is independent of medium — a Cursor Canvas (*.canvas.tsx, a live React doc beside the chat; see Canvas Text Layout (Pretext)), a markdown file, or a tracker doc all work. What makes it a runbook is the section set, kept current on every change:

• Status headline + stats grid — the one-line verdict ("N merged, M green, K blocked") and counts, so the top of the artifact answers "where are we?" instantly.
• Task table with per-row verdict — each PR / unit of work, its CI state, and a merge/hold verdict. The table is the spine.
• Blocker / danger callouts — what is actively red and why, distinct from the routine rows so it cannot be missed.
• Follow-ups — deferred, non-blocking items so they are not forgotten after launch.
• Session learnings — durable lessons (a rebase-vs-merge call, a recurring CI-staleness failure mode) so the next reader inherits them.

When to use it

Use a runbook when the effort is long enough to outlive one context window and wide enough that state does not fit in working memory: a launch with many stacked PRs, a phased migration, an incident with parallel workstreams. Skip it for single-PR or single-session tasks — there a Plan Mode Review Checklist pass or a short todo list is lighter and sufficient. The runbook is the observation surface that Observation Precedes Orchestration argues must exist before you coordinate many moving parts, and it complements Recursive Agent Orchestration by giving dispatched sub-agents and the human a single place to read and write shared status.

Relationship to neighbors

• Agent Operations Skills — private agent memory (memory.md), append-only, for the agent across sessions. The runbook is its public, effort-scoped sibling: shared, rewritten as state changes, for the human plus the agent.
• Staying in the Loop with Agents — the human's job shifts from doing to understanding; the runbook is how they stay oriented to project state cheaply.
• Harness Engineering — the runbook is part of the harness around the agent, not the model: a deliberate external-state structure that makes long autonomous work legible and recoverable.

Concept Position

---

Timeline

• 2026-07-01 | Concepts category refresh added this page to the Brain, memory, and retrieval family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: One living, human-readable status artifact that an agent maintains across a long, multi-step effort — every task, its state, the blockers,... Source: User request, 2026-07-01
• 2026-06-17 | Pattern named and captured during the Dedalus Machines launch. The agent maintained machines-launch-runbook.canvas.tsx (a Cursor Canvas in the Dedalus monorepo) across a multi-day, ~10-PR launch (#2396, #2417, #2437, #2438, #2455, #2498, #2276, #2439, #2521, #2523, #2531). Concretely, in this conversation it: (1) survived multiple context summarizations — after each, the agent re-grounded from the canvas on disk rather than the lossy summary; (2) tracked merge order and stacked dependencies (e.g. the admin-Metronome work feeding #2439); (3) held blockers and their resolution as a first-class callout (the Metronome custom_fields contract-create 400, a dev-branch build breakage from a Metronome type error, migration-timestamp collisions); (4) gave Kevin one glanceable merge-readiness view instead of re-triaging every PR; (5) accumulated session learnings (rebase-vs-merge strategy on deeply-diverged branches, recurring oxfmt/migration staleness as the dominant CI-failure class). Kevin flagged the pattern as worth reusing. Source: Dedalus DM launch session, 2026-06-17