Chapter 7 · The control graph

Owning the control flow

The rediscovered discipline underneath every working factory: deciding in advance which paths exist, and letting the model be clever only inside the boxes.

Here is a claim that sounds deflationary and is the opposite: most working “agents” are mostly deterministic code with LLM steps sprinkled in at the right pointsprimary. The systems that hold up in production are the ones where somebody decided, in advance, what the paths were. Maximum freedom for the model turned out to be a poor predictor of survival.

Horthy’s 12-Factor Agents states it as a principle: own your control flowprimary. It is the piece of the discipline that most directly determines whether a failure is debuggable.

§ 7.1

A graph is back pressure, drawn

An agent walking a predefined directed graph (explicit nodes, explicit conditional edges) is back pressure as a diagram. You trade some agent freedom for mandatory checks and legible failure points, so that when a run dies you can point at the node that killed itprimary.

plan implement model step check deterministic review HUMAN pass fail — retry, max 2 retries exhausted → escalate, do not loop Every path out of every node is sanctioned in advance. When a run dies you can name the node that killed it.
Fig. 7.1 — Back pressure drawn as a diagram. The clever part stays inside each box; the paths between boxes are decided by you, in advance, including the path that gives up.

The clever part stays inside each box; the paths between boxes are sanctioned in advanceprimary. This is why LangGraph became the most production-favoured orchestration framework: checkpointing, audit trails, rollback are all properties of having an explicit graph rather than an implicit onereputable.

Note what the diagram includes that hand-rolled loops usually omit: an edge for giving up. A retry cap with an escalation path is a design decision. Without one, “the agent kept trying” is indistinguishable from “the agent was working”.

§ 7.2

Short loops, because agents drift

Loop length is not a stylistic choice. Horthy’s rule of thumb from running these systems: agents hold up for three to ten steps and lose the thread past twentyprimary.

The consequence for verification is direct. Short loops verify cheaply: the check runs often, against a small delta, and a failure points at something recent. Sprawling loops hide mistakes in the cornersprimary, because by the time the check runs, the error is twelve steps back and entangled with everything after it.

Stripe encodes this as a hard rule: a two-round CI limit that forces a bail-out to humans on complex debuggingprimary. Two rounds, because the expected value of letting it try a third is worse than the cost of asking someone, whether or not it could eventually fix it.

§ 7.3

The Ralph loop

The other end of the design space is worth understanding precisely because it looks like the opposite of discipline.

A Ralph loop, coined by Geoffrey Huntley in July 2025, is a coding agent running in an infinite shell loop, reading the same prompt file each iteration, using the filesystem and git history rather than conversation history as memory, and starting each iteration with a fresh context windowprimary. It is named after the Simpsons character — deterministically bad in an undeterministic world — and the dumb persistence is the feature.

The fresh context is the actual insight. Conversation history is a liability that grows: it fills with dead ends, it drifts, it compacts badly. Externalising memory to the filesystem means each iteration starts clean and reads the current state of the world rather than the story of how it got there. Iteration N is not the continuation of iteration N−1; it is a new agent looking at a repository.

Ralph loops pair naturally with a lightweight spec workflow, where acceptance criteria live in a plan file the loop reads each timeprimary. By January 2026 Huntley had demonstrated a system that auto-healed a production bug with no human interventionprimary, and had moved on to orchestrating fleets of parallel agents, a direction Steve Yegge described as Kubernetes for agentsreputable.

§ 7.4

Fresh instances, for judging too

The fresh-context principle generalises beyond makers, and this is where it stops being a performance trick and starts being about independence.

A judge that carries its own prior verdict anchors on it. Asked to re-evaluate, it defends rather than re-derives, the same failure mode as a reviewer who already signed off. The fix is mechanical: dispatch judges fresh every round, never continued, and have them regenerate their own evidence rather than grading artifacts the maker left behindworkspace.

From this workspace This is observable, not theoretical. In one run a cold judging pass overturned the reasoning behind a verdict its predecessor had reached four rounds earlier: the earlier judge had asserted a dependency claim it never actually checked. A continued instance would have had every reason to defend that claim and no reason to re-check it.workspace
§ 7.5

What to keep deterministic

A practical division, which every pipeline in the case studies converges on independently:

  • Deterministic: the graph itself, gating, retries and their caps, file layout, what runs in what order, what happens on failure, what gets recorded.
  • Model: the content of a step — writing the code, writing the prose, forming the critique, making the judgement call inside a box.

The seam matters more than the split. Every place where a deterministic step hands off to a model step is a place where you should be able to see what was passed and what came back. When a factory becomes unmaintainable, the model steps are rarely the culprit. The culprit is that nobody can any longer say what runs when.

Decision rule

Draw your agent's graph on paper before building it. If you cannot draw it, you do not have a graph — you have a while-loop with a prompt in it, and the first hard failure will not tell you where it happened. Every node needs an exit for failure, and at least one of those exits must lead to a person.