Flight Plans

Two hours into a session that was supposed to migrate a service’s logging framework, someone looks over a shoulder and asks the obvious question: how far along is this? The honest answer sits somewhere between a shrug and a scroll back through the terminal. The agent has touched call sites in nine files, run the test suite twice — the first run failed on an import it then fixed itself — and is currently doing something in the config directory that may or may not have been part of whatever approach it settled on three screens ago. There is no line anyone can point to that says the session is on step four of seven. There is only activity, and the reasonable hope that activity is progress.

Hand the same migration to a junior engineer and the question has a real answer, because the engineer either keeps a checklist or can reconstruct one on request: schema change, call-site updates, config, tests, cleanup — four done, one left. Nothing about an AI session makes that structure unavailable in principle. The agent almost certainly decided on some version of it before touching a file. What it did with that decision — narrate it once, in prose, and then let the transcript bury it — is the actual gap. Earlier in this volume, the session itself is named as the basic unit of AI-assisted work; this chapter is about what happens inside one, once it has more than a single step.

The plan that already exists, unrecorded

Ask a capable agent to do anything with more than one moving part and it tends to narrate something plan-shaped before or during the work — first the schema, then the call sites, then the tests — because sequencing the steps out loud is a large part of what makes multi-step execution coherent at all. That habit is not occasional. It is close to the default behavior for any goal with real structure, and it shows up whether or not anyone asked for it. What is occasional is treating that narration as anything other than exhaust: text that scrolls past, gets buried under tool output within a few turns, and by the time someone downstream wants to know which step the session is on, answering requires re-reading the whole conversation to reconstruct a plan the agent already stated once and then abandoned as a record.

Anthropic’s own guidance for long-running agents makes a version of this point from the harness side: a structured, updatable file of what still needs to happen — the kind an initializer agent writes and later sessions are instructed to update rather than rewrite — is what lets work resume correctly across a boundary a single conversation can’t cross. The insight generalizes below the level of a multi-session project. Even inside one sitting, the difference between a plan that exists as prose and a plan that exists as state is the difference between a session someone can check on and a session someone has to interrogate.

Two ways this goes wrong

The first failure is the one the opening scene shows: no visible structure at all. A session on track and a session quietly lost in the weeds produce, from outside, an identical stream of tool calls and file edits. Nothing distinguishes them until someone reads closely enough to judge, which is exactly the effort a structured record exists to save. Interrupting a session like this and resuming it later loses more than context — it loses the place, because the place was never written down anywhere but the conversation itself.

The second failure is quieter and more expensive, because it produces false confidence instead of honest uncertainty. Someone — a person at the start of the session, or the agent itself on its first turn — writes a task list. Work then proceeds, and somewhere in the second or third step the actual sequence diverges from what got written: a step turns out to need splitting, an earlier one gets revisited, a dependency surfaces that reorders everything after it. The list, if anyone looks back at it, no longer describes the session. The team believes it has structure because a document exists. It does not, because nothing kept the document and the execution synchronized, and a plan nobody is updating is functionally the same as no plan at all — worse, actually, since it still looks like evidence.

Flight Plans

Call the fix a Flight Plan: a goal-decomposition and step-tracking record, scoped to a single AI session, that stays synchronized with execution rather than being written once and left behind. A goal gets broken into concrete steps, a cursor marks which step is active, and the cursor advances — ideally from evidence the session itself produces, a test passing where the plan said it should, a file changing where the plan said it would — as the work actually happens. At any point mid-session, the record is inspectable: not a transcript to be reconstructed, but a small piece of state anyone, or anything, can query directly.

That needs separating carefully from a specification, in the sense this Library’s volume on intent architecture develops at length. A spec is written before code exists and describes what the finished thing should be — a document, reviewed and iterated on its own timeline, that can outlive the session that first acts on it by months. GitHub’s spec-kit formalizes a specify-plan-tasks-implement sequence, and its tasks phase does produce something list-shaped, but that list is still an artifact of planning that precedes execution. Nothing about it is built to change shape as a particular session unfolds, because it was never meant to describe one session in the first place.

It also needs separating from a plan-mode proposal, which this Library covers in its own chapter on plan-mode thinking. Plan mode is narrower and more disposable than either a spec or a Flight Plan: one turn’s read-only research, culminating in a single proposal presented for approval before any edit exists, discarded the moment it is approved or rejected. It answers whether the agent should proceed at all, and roughly how — a decide-then-do gate at the very start of the work. A Flight Plan assumes that question is already settled, by a spec, by an approved plan-mode proposal, or by nothing more formal than the agent deciding as it goes, and tracks the one thing neither of the others is built to track: where the session actually is, right now, against the sequence it committed to.

Three tracking artifacts, compared

None of the three substitutes for another. A session can have a spec it is implementing, a plan-mode proposal that approved the approach, and a Flight Plan tracking progress through it, and each artifact would still be doing a job the other two cannot do. The confusion that actually happens on teams is subtler than picking the wrong one — it is assuming that having any one of the three means the others aren’t needed, and discovering mid-session that the question actually being asked (where are we, right now) was never the question the artifact on hand was built to answer.

When detection lies

A Flight Plan that has to be typed in by hand before every session invites the same ceremony problem this Library names elsewhere: a step people skip under deadline pressure until the practice quietly stops happening. The more durable version detects the plan from what the agent is already narrating and advances the cursor from evidence in the session itself — the same instinct behind Claude Code’s own task-tracking primitives, which turn a model’s stated intentions into structured, queryable items rather than leaving them as prose a person has to re-read.

Auto-detection buys convenience at the price of a specific and well-known failure mode: it can be fooled by structure that merely looks like a plan. Three numbered lines in a README the agent happens to print while reading a file are, to a pattern matcher with no other signal, indistinguishable from three numbered lines the agent just committed to executing. A detector that cannot tell narrated intent from quoted text will mint a plan from the wrong thing — and if re-detection resets progress every time it fires, a phantom plan minted from unrelated output can silently erase real progress on a real one. That second part is the sharper danger. A false positive that produces a wrong status light is an annoyance. A false positive that overwrites state nobody meant to lose is a bug with teeth, and it is exactly the kind of failure any system that infers structure from unstructured narration has to be built to refuse: require a genuine marker of intent, not just a numbered format, and never let a new detection destroy progress that already exists.

What a Flight Plan dashboard should be able to answer

What a Flight Plan buys you

Once a session’s steps exist as tracked state rather than narration that scrolls past once, a handful of things become possible that pure prose never allowed. Someone can ask, mid-session, exactly which step is active, and get an answer without re-reading the transcript. A session can pause and resume without losing its place, because the place is stored rather than remembered from context that may itself have been compacted away. And a tracked plan gives a harness something concrete to gate against, which matters most for the two chapters that follow this one in this volume: workflow boundaries constrain what a session may touch, and checkpoint thinking constrains when it may proceed past a given point, and both constraints are considerably more precise when there is a real step to attach them to rather than an undifferentiated stream of tool calls.

A Flight Plan is not itself a safety mechanism, and treating it as one is the fastest way to trust it more than it has earned. It is the substrate — the piece of state that turns “the agent seems on track” from an impression into a claim someone could actually check.

The Sprint Backlog is updated throughout the Sprint as more is learned.

The Scrum Guide, on why a tracking artifact has to change during execution to stay true