Designing AI Workflows

Nine chapters ago, this volume opened with a claim disguised as an observation: every AI session already has a plan, a prompt, generation, review, refinement, a commit, a deploy, and something learned built into it, whether anyone names the stages or tracks them. Everything since has been that observation taken apart and rebuilt as engineering practice. A goal became something durable enough to check progress against — a Flight Plan, this Library’s term for decomposed, tracked intent — rather than a sentence typed once and forgotten by turn ten. A session’s reach into the codebase became a boundary that could be enforced and, when violated, recovered rather than reverted destructively. The space between plan steps became a place to actually look at what changed before letting the next step run. A finished session became something rewatchable, not just something misremembered in standup. Real-time stalling — the same file edited five times, the same search repeated eight, the same error hit four times running — became a pattern with a name and a moment to catch it, instead of a mood only visible after the invoice arrived. Interruption became something a session could survive instead of something that erased it. And the whole practice, once all of that existed, turned out to have named shapes worth choosing deliberately — plan-first, test-first, iterate, explore-first, greenfield — and, finally, something measurable enough to tune on purpose rather than by folklore.

The single claim underneath all nine chapters

Say it plainly, because the rest of this chapter depends on it: a workflow is not a single artifact, and it is not a single good habit. It is a stack of independently engineerable decisions — how a session’s goal gets decomposed and tracked, how far the session is allowed to reach into the codebase, when it pauses for a human to actually look, whether its history survives to be reviewed or replayed, whether its stalls get caught in the moment or only in the retro, how interruption is handled, which archetype genuinely fits the task in front of it, and whether any of this is being measured at all. Each of those is its own layer, with its own failure mode, and by now each has accumulated enough real practice to be treated as a craft rather than a checkbox. A team that gets tracking right and boundaries wrong has not half-solved its workflow problem. It has solved a different layer than the one currently costing it money.

This is why “let’s switch AI tools” so rarely fixes the problem it was meant to fix, and why “let’s write better prompts” fixes even less of it. A team whose sessions routinely wander off-goal by turn twenty does not have a model problem or a prompting problem — it has a tracking problem, specifically: nothing in the session checks generated work against a decomposed goal, so drift compounds silently until someone notices scope has quietly tripled. A new model, a new harness, or a stricter prompt template will not touch that layer; only tracking the goal will. The same evidence this Library leaned on in Volume I — that experienced developers using AI tools measured about nineteen percent slower on real tasks while believing themselves roughly twenty percent faster — applies with equal force to workflow practice itself. A team’s sense that “we’re pretty good at this by now” is exactly the kind of self-report that evidence says not to trust, which is what makes actually measuring friction rates, checkpoint reject rates, and time-to-resume — Chapter 9’s subject — load-bearing rather than optional.

An evaluation rubric

What follows is not a new framework — this volume already spent its coinage on Flight Plans, in Chapter 2. It is the set of questions the preceding nine chapters actually equip a reader to ask, whether the job is diagnosing a workflow already in use or designing one from scratch.

• Session lifecycle (Ch. 1): does your team recognize the full plan → prompt → generate → review → refine → commit → deploy → learn arc, or does tracking stop the moment code is generated, leaving review, deploy, and learn invisible to everyone including the agent?
• Flight Plans (Ch. 2): does a session’s goal exist anywhere durable enough to check progress against, or does it live only in the first prompt — forgotten, unrevised, and unenforced by turn ten?
• Workflow boundaries (Ch. 3): can a session touch any file it wants, or is there an actual enforced scope — and when that scope is violated, is the result recoverable, or does enforcement itself destroy work?
• Checkpoint thinking (Ch. 4): between plan steps, does anything pause long enough for a human to look at what changed, or does a session run start to finish unsupervised regardless of how much was touched?
• Workflow replay (Ch. 5): when a session goes wrong, or surprisingly right, can anyone actually watch what happened afterward, or does the only record live in a scrollback nobody rereads?
• Workflow friction (Ch. 6): is edit thrashing, a search spiral, or an error cascade caught while it is happening, or only recognized in hindsight, once the session’s cost is already spent?
• Workflow recovery (Ch. 7): if a session is interrupted — a laptop closes, a context window fills, a teammate has to take over — does the next session actually resume where the last one left off, or does it start from zero and re-derive everything?
• Workflow patterns (Ch. 8): does your team recognize which archetype a task calls for — plan-first, test-first, iterate, explore-first, greenfield — and choose deliberately, or does every session default to the same shape regardless of the work?
• Workflow optimization (Ch. 9): is anyone measuring workflow practice itself, or does “how we work with AI” remain a matter of individual habit, unobserved and untuned?

None of these questions has one correct answer, and that is deliberate. A solo developer prototyping alone has a legitimate reason to skip checkpoints and let a session run to completion unsupervised — the cost of a bad session is an hour, not an incident review. A team shipping against a compliance deadline has an equally legitimate reason to gate every step and accept the friction that comes with it. The rubric’s job is not to prescribe a posture. It is to make sure the posture was chosen, layer by layer, instead of defaulted into — the same way most teams inherit whichever workflow shape their tooling ships with and never ask whether it fits the task actually in front of them.

Most teams have not designed a workflow. They have inherited whichever shape their tooling defaults to, and mistaken the absence of a decision for the presence of a good one.

Where the Library goes next

This volume treated the session as the unit worth engineering — one agent, one goal, structured well enough that plan, review, and recovery all hold together. Volume VI, Multi-Agent Development, asks what happens once a task is handed to more than one agent at a time, and it opens deliberately with the contrarian half of that question: most coding tasks, unlike the open-ended research workloads where multi-agent systems shine, do not actually parallelize well, and the cost of running several agents in place of one is not small. Anthropic’s own account of building a multi-agent research system puts multi-agent token usage at roughly fifteen times a single chat interaction’s cost, justified only when the work is genuinely divisible and valuable enough to pay for it. The volume covers when not to reach for multiple agents before it covers when to, then the economics of parallelism, orchestrator-worker patterns, isolation through worktrees, and judge panels for verifying one agent’s output against another’s — building toward the claim this Library gives that volume outright: the future is not one AI, it is coordinated systems, used sparingly.