Every AI Session Is a Workflow

An engineer opens a terminal, types a paragraph describing what they want — “add password reset to the auth flow, include a rate limit, write tests” — and watches an agent work for the next twenty minutes. Files open and close. Commands run. A diff accumulates. When it stops, the engineer skims the change, decides it looks right, and merges. Nothing about this looks like an engineering process. It looks like asking a very capable colleague a question and getting a longer answer back, with code attached.

That impression is the problem. Between the prompt and the merge, something with real structure happened — a goal was interpreted, a plan was formed and kept or silently abandoned, code was generated, it was checked against intent or it wasn’t, gaps were found and closed or they weren’t, and the result was captured somewhere a future session could learn from or, more often, it wasn’t. None of that is optional; it happens in every session whether anyone names it or not. What is optional is whether a team treats it as an engineering process with stages, checks, and a record — the way it already treats a build — or as a single freeform exchange that starts with a prompt and ends when it stops.

What a session actually is

Anthropic’s own guidance for Claude Code recommends a four-phase shape for real work: explore the codebase without changing anything, form a plan, implement it, then commit with a descriptive message. The stated reason is not stylistic. Letting an agent jump straight to coding, the guidance warns, can produce code that solves the wrong problem — the plan phase exists specifically to catch a misunderstanding before it becomes expensive to unwind. That is a narrower claim than this chapter is about to make: four phases for one well-scoped task, not a lifecycle for an entire sitting. But it is worth noticing that even the vendor whose product treats a session as “just a conversation” recommends explicit phase discipline the moment a task stops being trivial.

Underneath that phase discipline sits something narrower still: what Claude Code’s own documentation calls the agentic loop — gather context, take action, verify results, repeat — which runs inside a single turn, sometimes many times inside one exploratory question. The loop is not the workflow. It is the mechanism a workflow’s generate step delegates to. A session can run that loop dozens of times and still have no plan, no review step, and no record of what it decided, because the loop answers a narrower question than a workflow does: not “is this correct,” but “what tool do I call next.”

The lifecycle already exists, unnamed

The clearest evidence that a session already has phases, whether a team draws them or not, comes from what happens when one sitting is not enough. Anthropic’s engineering write-up on long-running agents describes a deliberately two-part structure for tasks that outlive a single session: an initializer session that sets up the environment, writes a feature list, and establishes a progress file, and every subsequent session reading that state, making incremental progress, then leaving structured updates for whichever session runs next. The write-up frames this explicitly as mimicking human engineering practice, treating each session like a shift that has to leave a clear handoff for the next worker. Nobody had to invent the handoff — it is what happens automatically once a task can’t fit in one sitting and someone has to reconstruct where it left off.

A companion piece on context engineering makes the same point from a different angle. Once a task runs long enough, the agent itself needs deliberate techniques — compacting old context, taking notes, delegating pieces to subagents — just to keep working coherently across the arc of one session. Those are not free-floating tricks; they are the machinery a generate stage needs once a single undifferentiated context window stops being reliable. The stages are already there. What is usually missing is a name for them, and a team is far more likely to instrument, gate, and improve a thing it has agreed to call a stage than a thing it experiences as one undifferentiated block of agent activity.

The AI session lifecycle

Call it what it is: the AI session lifecycle. Eight stages, in order, cover a session from the moment someone forms an intent to the moment that session’s outcome becomes available to the next one — plan, prompt, generate, review, refine, commit, deploy, learn. Plan is deciding what “done” means before any code exists. Prompt is turning that decision into an instruction the harness can act on. Generate is the harness’s own loop producing a candidate change. Review is checking the candidate against the plan, by a person or a second agent. Refine is closing whatever gap review found. Commit is capturing the accepted change with a message that will still make sense in six months. Deploy is the change actually reaching something that matters — a merged branch, a staging environment, production. Learn is whether anything this session discovered survives to make the next one better.

None of this is a new idea dressed in new words. It is closer to acknowledging, in one place, an arc that has always existed and giving each part of it a name specific enough to be measured. This Library already treats the session as the fundamental unit of account for AI-assisted work — Volume I’s Session ROI asks what a given sitting returned against what it cost. This chapter asks a related but different question: not what a session is worth, but what a session is made of. Same object, a different instrument pointed at it.

Eight stages, one arc

The pattern across all eight rows is the same one this Library’s account of the harness noticed at a smaller scale: whatever step has no natural forcing function is the step that quietly disappears. Generate fails loudly — a broken build, a failing test — so it gets attention by default. Learn fails silently. A session ends, its context window closes, and whatever it discovered about this codebase either got written down somewhere durable or it didn’t; nothing errors out either way. That asymmetry is exactly why “the same mistake relearned, and re-explained, every sitting” shows up twice in this Library, once as a property of memory inside a harness and again here as a property of a session that has no learn stage — it is the same gap, one level up.

Same session, different altitude

Two other altitudes are worth distinguishing so this one does not get confused with either. One level down, inside a single turn, sits the agentic loop this Library’s volume on the harness named: gather context, take action, verify, repeat — a mechanism, not a workflow, that the generate stage above delegates to, and that can fire dozens of times without ever touching review or commit. One level up, spanning far more than one sitting, sits the spec-driven structure this Library covered earlier: constitution, specify, plan, tasks, implement — a shape for deciding what an entire project should become, not what one session should produce this afternoon. The lifecycle this chapter names sits between them: bigger than one tool call, smaller than a project — and it exists because nothing about a session carries forward on its own.

Sessions are independent. Each new session starts with a fresh context window, without the conversation history from previous sessions.

Claude Code documentation — why the learn stage isn’t optional

Why this deserves a pipeline’s discipline

A CI/CD pipeline earns the name because it has stages with names, gates between the stages, and a dashboard that shows exactly where a build died last night. Most AI sessions today have none of the three. They have a transcript.

The cost of that gap is not hypothetical. In one large cross-organization dataset, teams using AI completed 21% more tasks and nearly doubled pull-request throughput — while code review time grew 91% and organization-level delivery metrics stayed flat. Read against the eight-stage arc, that is not a mystery: generate got faster, and review, the stage with the least existing tooling and the most human judgment attached to it, absorbed the difference. A team that has never named review as a distinct stage with its own load has no way to notice that the bottleneck moved there until the backlog makes it obvious. DORA’s broader framing of AI as an amplifier — of whatever strengths and dysfunctions already exist in how a team works — points at the same conclusion from further out: an unstructured session amplifies the fact that it is unstructured.

The rest of this volume takes each stage of this arc and gives it the depth a chapter can afford that this one cannot. Flight plans take apart what the plan stage should actually produce before a single token of code exists. Boundaries and checkpoints cover the gates a lifecycle needs between its stages — what an agent may do unsupervised, and where a human or a second agent is asked to look before work proceeds. Replay turns the learn stage from a vague debrief into an inspectable record of what a session actually did. Friction names the specific ways a session stalls trying to cross from one stage to the next, and recovery covers what it takes to resume cleanly once a stall has broken the lifecycle’s continuity. Patterns catalogs the recurring shapes real sessions take across the whole arc, named clearly enough to recognize the second time. Optimization asks how a team would know, with evidence rather than impression, whether its version of this lifecycle is actually improving. The volume closes with a capstone on designing an AI workflow deliberately, instead of accumulating one by habit.

What this looks like inside Operon

None of this requires exotic tooling to observe — a command center built to sit on top of an AI coding session is, by construction, in a position to track exactly this arc. Operon’s own session view already renders a coarse version of it as a four-phase rail — analyzing, implementing, testing, complete — a simpler cut than the eight-stage lifecycle above, but built on the same premise: a session is not one blob of activity, it is a sequence with a shape, and the shape is worth showing on screen rather than inferring from a scrollback. The finer-grained pieces of the full lifecycle are what the rest of this volume is about: flight plans for the plan stage, checkpoint gates for the boundary between stages, replay for the learn stage’s evidence, a loop detector for the friction that stalls a session mid-arc. None of that is a claim that any particular tool has this fully solved. It is an existence proof that the lifecycle this chapter names is buildable, not just a chart worth drawing.