Six stages. Every request goes through all of them. Each stage has an owner, a Linear state and a definition of done. The last stage feeds the first. This is the model every other chapter leans on.
A stage is done when its exit criterion is met. Not when the owner says so. Bellows reads the criterion off the last line the agent wrote and moves the Linear state. Nobody moves a state by hand except Priya at a gate. That one rule is what makes the loop run without you.
| Stage | What happens | Who owns it | Linear state | Done means |
|---|---|---|---|---|
| Ideation | A request or an idea gets written down in the customer's words. Ledger files it from a ticket. Beacon brings what it saw on the customer journey. Priya adds her own. | Priya | Idea | The issue exists and the customer's words are on it. |
| Scoping | Anvil writes the Problem, the Out of scope list and numbered acceptance criteria. Asks the one question that changes the scope. Says no when no is right. | Scoped | Every criterion can be tested by a machine or a checklist. | |
| Details | Anvil sizes the slice in points and sets the risk flags. Warden writes a threat note if any flag is set. The gate question is one sentence Priya can answer yes or no. | Detailed | Bellows can dispatch it without asking anyone anything except Priya at a gate. | |
| Development | The builder Anvil named makes a branch, builds the smallest change that meets every criterion, runs it, opens the PR. The other builder reviews it cold. Two rounds at most. | In Progress | APPROVE on its own line from the reviewer. | |
| Testing | Gauge writes one test per criterion and runs them against the preview. Warden reviews the final diff. Beacon walks the screen as a café owner. A failure sends the issue back to Development with a defect. | In Test → Ready to Deploy | QA GREEN, WARDEN CLEAR, Beacon has no blocker. | |
| Deployment | Bellows asks Priya. On her yes it deploys. Quill writes the decision and the changelog. Beacon writes the release note. What was learned goes in the log and back into the agents' files. | Priya | Deployed | Live. Written up. Learning logged. The next Idea is already in the inbox. |
Testing cycles with Development. That is the one arrow that points backwards inside the loop. A slice can go round that small circle several times before it moves on. Three times and Bellows stops and asks Priya, because three failed cycles usually means the spec is wrong and not the code.
Route notes on an account. Riverbend Café asked for it through Sam. Three points. Press play or step through. The captions name who did what at each hop.
Two arrows are different from the rest. Defect is the small cycle: Gauge found a failing criterion and sent it back. Learned is what makes this a loop and not a line: the deploy produced a lesson and a new Idea. Both are written down before the lap is over.
Most teams run a line. Idea, build, ship, forget. The knowledge stays in the heads of whoever was in the room. With agents there are no heads. Whatever is not written down did not happen. So the loop ends with two write-back steps and neither one is optional.
At the end of every run Quill records what was decided and why into the wiki. A decision record when a choice was made. A changelog entry when an issue deployed. A runbook change when a process changed. Short, dated, linked to the issue. Anvil reads the last three decisions before it scopes anything. That is how a decision made in week one still holds in week six.
When an agent finds a better way it edits its own agent file or the shared instructions. The Stop hook notices any change under .claude/, CLAUDE.md or AGENTS.md and flags it as a learning event. Quill turns those into learning-log entries. Nineteen of them in the Alderline build. One of them, from ALD-42: test the limit from both sides.
Priya can ask where everything is at any time. This is the prompt she uses on a Monday morning.
Read CLAUDE.md. Then list every open Linear issue in team ALD with its state, who last acted on it and when, and what the next step in the loop is. Flag anything that has waited on me for more than a day and tell me the gate question for each one. Table, then one line on what you would do first.
And this is the trail one lap leaves in the telemetry log. Every line is one event Bellows or a hook wrote. The dashboard is built from these.
Timestamps are UTC. Portland is seven hours behind in September. Two gates fired and both waited on Priya: one for twelve minutes over coffee and one for a day, while she was at the roastery and then out on the Tuesday route.
Illustrative, from the Alderline build. ALD-42 is a three-point slice. Two days end to end, about six hours of agent time, most of the wall clock spent waiting at the two gates. The customer-data gate waited twelve minutes while Priya finished her coffee and the deploy gate waited a day because she was at the roastery and then out on the Tuesday route. That is the right shape. The gates are where the founder's judgement goes in and the founder's time is the scarce thing.
What changed for me is what I do with a request. I used to carry it around. Sam would mention the back door thing on a Tuesday and I would remember it on a Friday and write something vague in HubSpot and feel bad about it for a month. Now I forward it and the next time I see it there is a question I can answer with yes or no. I answer maybe six of those a day. Some of them I say no to. That is the job now. The crew does the rest and I can read exactly what it did.
The interactive version of this chapter. Step through the six stages with the real Alderline issues and see which agent moves each one.
Open the lifecycle → ▤The dashboardThe telemetry above, folded into hours per agent, issues per week, gates asked and answered, and the learning log.
Open the dashboard →Yes, and they are quick when the change is small. Anvil scopes a typo fix in a minute with one criterion. Flint's review is a glance. Gauge runs the regression suite and that is the part you want even for a one-liner. The stages are not overhead. They are the reason a small change cannot quietly break a big thing. What you can skip is the gate: a fix with no risk flag never asks you anything.
Because a failed test is information for the builder and not a verdict on the slice. Gauge writes a defect with the criterion, the steps, expected and actual, and the test file and line. Ember reads that and fixes it. The issue goes back to In Progress so Linear shows the truth: someone is working on it. The cycle has a limit. Three fails and Bellows asks you, because by then the spec is the likely problem.
Bellows, by reading the last line each agent writes. ANVIL: Scoped moves to Scoped. APPROVE moves to In Test. QA GREEN plus WARDEN CLEAR moves to Ready to Deploy. Your yes at the gate moves to Deployed. Agents update fields and add comments but they do not move states, so the board always means one thing. If you move a state by hand Bellows will follow it, but then you are the dispatcher for that issue.
It sits in Idea. That is what the state is for. Anvil only picks up an Idea when Bellows hands it over and Bellows only does that for issues in the ALD team. Keep a separate Linear project for ideas you are not ready to scope, or label them and filter them out. Beacon adds to the Idea pile from the customer journey and Ledger from tickets. Priya reviews the pile on Mondays and promotes what she wants scoped.
The six stages and what done means for each. The seven Linear states that mirror them and the rule that only Bellows moves them. The small cycle between Testing and Development and its limit. The two write-back steps that turn a line into a loop. And a feel for the shape of a slice: about two days, six hours of agent time, two questions for you.
Next: Chapter 3 · Anvil. The product manager. Why every request is scoped into acceptance criteria before anyone codes, with ALD-42 as the worked run.