The trilogy in action
One real session. Three tools. An auth migration from start to advance — earned, recorded, executed.
The trilogy page describes the flow. This one shows it working. An agent opens a session in a checkout service, hits a consequential choice about how to migrate off legacy session tokens, runs it through research.md, records the outcome in Governor as an ADR, and then executes against that contract in Docket. Each step uses real MCP tools the agent calls directly. Nothing happens in a dashboard; everything is auditable after the fact.
Scene 1 — Session start · Governor tells the agent what the project has already committed to
agent · checkout-svc · session open
# agent opens a session. First call is always visionlog_boot. › visionlog_boot project_id=checkout-svc vision "trusted checkout — zero data loss under any refactor" goals 3 active · 1 relevant today: GOAL-007 auth rewrite guardrails 5 active · GR-01 soft-delete only · GR-03 no session-token logging adrs 14 accepted · nothing yet on auth-migration approach agent today's task: migrate auth off legacy session tokens. choice looms: blue-green, gradual rollout, or rolling? no existing ADR — this needs research.md before tasks are created.
Scene 2 — Earn the decision · research.md turns a fork into a locked, reviewable ADR
agent · research.md
› research project_init "auth-migration-approach" › candidate_create "blue-green" · "gradual rollout" · "rolling" › criteria_lock weighted: data-loss-risk=3 · rollback-time=2 · user-impact=2 · ops-cost=1 locked 4 criteria · no further changes without a supersede › candidate_score --scores-from evidence/ blue-green risk 9 · rollback 9 · impact 6 · ops 4 → 7.7 gradual risk 7 · rollback 7 · impact 8 · ops 5 → 7.0 rolling risk 4 · rollback 5 · impact 5 · ops 8 → 5.1 peer_review_log 2 reviewers · 0 open objections › project decide --winner blue-green DECIDED blue-green · ADR-042 authored into Governor rationale recorded · supersede required to re-open.
Scene 3 — Execute within the contract · Docket creates tasks bound to GOAL-007 + ADR-042; DoD is checked, not claimed
agent · docket · execute
› docket task create "stand up blue-green auth cutover" --goal GOAL-007 --adr ADR-042 docket TASK-031 created · linked to GOAL-007 · cites ADR-042 dod tests green · migration applied · PR linked · GR-01/GR-03 met # agent does the work: PR #214, staged cutover, tests, migration applied soft-delete style › docket task complete TASK-031 --notes "cutover behind LD flag; legacy rows soft-deleted; PR #214" dod ✓ tests 42/42 · ✓ migration 0042..0044 applied · ✓ PR #214 ✓ GR-01 soft-delete verified · ✓ GR-03 no tokens in logs docket TASK-031 DONE · unblocked TASK-032 (flip flag) › docket milestone view M2-auth-rewrite milestone M2 · 4 / 5 tasks ▰▰▰▰▱ · next: TASK-032 flip flag agent: picking up TASK-032.
What just happened
Three tools, one session. The agent didn't guess at the migration approach — it earned the call through a scored matrix and peer review. The winning choice didn't evaporate into chat history — it became ADR-042, now part of the project's contract. The task didn't close because the agent said "done" — it closed because the DoD was checked against reality (tests, migration log, PR, guardrails).
A future agent opening this session on Monday doesn't need to reconstruct any of it. visionlog_boot shows the vision and guardrails. research project_get auth-migration-approach shows why blue-green won. docket milestone view M2 shows where execution is. The memory of the project is not in anyone's head.
Memory is the prerequisite. The trilogy gives the project a durable self-description — sentience in a functional sense: perceive, decide, act. What happens when a system starts using that memory to watch itself, notice its own patterns, and self-correct? That's the next step, and it has its own page.