How the Work Actually Flows

Most writing about AI agents shows you the last ten minutes: someone types a request, an agent writes code, the code works. That is the least interesting part, and it is not where the leverage is.

Here is the whole path a piece of work takes, from "I have an idea" to "it is live" — and what an agent does at each stage. There are five, and an agent does something real in all of them.

The two stages people assume are human-only — deciding whether the idea's premises are even true, and reviewing the plan before anyone builds — are the two where an agent has saved me the most.

The five stages

  1. IDEA        capture it before it is well-formed
  2. LITERATURE  find out what already exists — including your own past work
  3. PLAN        turn it into phases, then attack the plan
  4. ITEMS       real, claimable units of work with real dependencies
  5. EXECUTION   claimed, branched, built, reviewed by someone else, merged

Nothing here is exotic. What is different from how most people work is that each stage produces a written artifact that the next stage consumes, and an agent can read all of them.

That is the whole trick. Not "the agent is smart" — the agent has the context, because the context is written down.

1. Idea: capture it badly, on purpose

An idea arrives half-formed. The instinct is to think it through before writing it down. Don't — you will lose the half you had.

The move is to capture it under-decomposed: a title, what triggered it, and what you think you want. Deliberately not a plan.

An agent can do this while you talk. What it produces is a record with the one thing you will need later and will not remember: why. Six weeks on, "we should make this easier to start" is worth nothing. "I sat with a friend who has run large design teams for twenty years, watched him get stuck at the fourth step, and he said 'I need to make it simpler to get started'" — that is actionable, and it is only in the record if someone wrote it down within the hour.

The test for whether an idea is captured well enough: could someone who was not in the room tell what problem it solves? If not, it is a reminder, not an idea.

⚠ Resist decomposing here. An idea that arrives as a plan is usually a plan for the first solution you thought of.

2. Literature: find out if you already solved this

This is the stage almost everybody skips, and it is the one with the highest return.

Before building anything, the question is: what already exists? Not just published work by other people — your own. Notes, past projects, half-finished attempts, things a colleague wrote and you forgot.

This is a genuinely good use of an agent, because it is search plus judgement over a corpus you cannot hold in your head. It reads what exists and reports what is actually there, versus what you assumed.

On this handbook, that stage changed the project before a word was written. The agent checking the premises found that of the things the original brief assumed, four were wrong:

• The website was on a different domain than the brief said.
• Two of the three tools the advanced chapters were meant to cover did not exist publicly — one archived, one with no repository at all.
• A tool proposed for beginners had a front door reading "superseded, no further releases planned", pointing at a repository that was itself archived.
• Most of the content the book needed already existed — as papers, written for reviewers.

That last one changed what the work was. The job stopped being "write a book" and became "translate existing material into a register a non-specialist can act on" — a different and harder skill, and one you would staff differently.

⚠ Notice that four premise errors were caught before any building, by reading rather than by discovering them halfway through. That is what this stage buys. The cost was one agent, one session.

3. Plan: write the phases, then attack them

Now decompose. Phases, what each delivers, what has to be true first.

Then do the part almost nobody does: have someone attack the plan before anyone builds against it.

Not a review of the work — a review of the plan. Are the phases in an order that can actually run? Does phase 3 need something phase 5 produces? Is a premise stated as fact that is really a guess?

This is an excellent agent task, and it works better with an agent than with a colleague for one specific reason: a colleague who likes you will soften it. An agent asked to find problems will list them.

On this handbook, the plan went through four revisions before any chapter was written, and each revision came from someone attacking the previous one. One revision reordered the whole thing after the attack pointed out that a human trial was scheduled after only two of seven chapters existed — so it would have measured the introduction, not the book.

Attack your own plan by asking one question: "If this fails, what will the reason turn out to have been?" Then check whether the plan addresses that reason. If it does not, you have found the phase that is missing.

4. Items: make the work claimable

A plan is not work. It becomes work when it is broken into units that someone — a person or an agent — can pick up, finish, and close.

Each unit needs three things:

1. Enough context to be done without asking you. If the item requires a conversation with its author before it can start, it is not ready.
2. Its dependencies, explicitly. "This cannot start until that lands" has to be recorded, or someone starts it and gets stuck.
3. A definition of done that is checkable by someone else.

That first one is the one that matters most and is hardest to accept: an item that only you can execute is a bottleneck wearing the costume of a task.

5. Execution: and the one rule that does not bend

Now an agent claims an item, works it, and proposes the result.

The mechanics are ordinary — claim it so others see it is taken, work on an isolated branch, run the tests, open a proposal. Many Agents, One Rule covers the isolation part, which is the half that bites.

The rule that everything rests on: whoever reviews cannot be whoever produced.

Not because the producer is untrustworthy. Because what review buys is a reader who did not build the thing — someone who does not know what it was supposed to do and therefore reads what it actually says.

⚠ This is not ceremony, and I can price it. Writing the chapters of this handbook, review caught:

• A chapter that told readers a dangerous warning was "mostly not true" — on the strength of testing the one command spelling that is safe. Four of five spellings destroy uncommitted work silently, including the one a reviewing agent runs. The chapter was reassuring readers about the exact command behind the incident it was written about.
• A chapter that sent readers to a file that is not in the place named, at the pivot into its central example.
• A transcript that could not have happened in the order printed. The commands were real. The sequence was not. I had run them, corrected them in a scratch directory, and pasted the corrected output back into the broken ordering — and written a sidebar about having caught that exact class of error.

Every one of those was found by someone re-running the commands rather than reading the prose.

Where the human actually sits

Reading the five stages back, the striking thing is how little of it is typing.

Your job is direction and judgement. Which problem is worth solving, what "good" means here, when a finding should change the goal. None of that is delegable, and none of it is typing.

⚠ The stages people expect to keep for themselves — plan and review — are the two where an agent earns the most, because both reward tireless, unflattering thoroughness more than they reward insight. An agent will read every file. It will tell you your plan has a hole. It will not soften the finding to keep things pleasant.

You can take over at any point, and you should

Nothing above is a pipeline you start and walk away from. Every stage is a place you can stop the agent and do the next part yourself — and the record is what makes that possible, because the state is written down rather than held in an agent's head.

The first version of this handbook was written that way on purpose. Partway through drafting it, I stopped the agent mid-chapter so I could run the remaining steps by hand while a friend watched over my shoulder — the same friend whose "I need to make it simpler to get started" is the reason this book exists. He did not want to see the finished thing. He wanted to see the moving thing: the idea going in, the plan getting attacked, an item getting claimed, work coming back for review.

⚠ That is the demo worth giving, and it is not a demo of an agent writing code. It is a demo of work moving through stages where a human keeps making the calls. You can hand a stage over, take one back, or do one yourself because you want to think it through — and none of that breaks anything, because the next stage reads the written record, not the conversation.

If it only works when it runs end to end unattended, it is not a workflow. It is a script.

Start smaller than this

You do not need five stages and a board to begin. The smallest honest version of this loop is one sitting:

1. Write down what you believe, and what would prove you wrong.
2. Go and look.
3. Write down what you found, including if it contradicts you.

That is chapter one, and it works with nothing but a text file. Everything on this page is what that loop turns into when several people and several agents are doing it at once, and the pressure that made each part necessary showed up in that order.

Add a stage when its absence costs you something you can name. Adopting all of it because it is written down here would be exactly the mistake When a Tool Earns Its Place argues against.

Where to go next

• Ten Minutes to a Board — stage 4 with real tooling, from install to first item
• Skills: Stop Retyping Instructions — how the repeated parts of stages 1–4 stop being retyped
• Many Agents, One Rule — stage 5 when more than one agent is working at once