Part 1 — The Mindset  ::  Chapter 3

1.3 Loops and Models

Two ideas carry the rest of this book, and everything else is a consequence of them. The first is that all agent work is a loop. The second is that an agent steers that loop well only when you hand it a model of the world it is working in. This is what makes the MAGE method work: Model-Based Agentic Software Engineering means engineering that loop and handing the agent that model, deliberately, every time. Get these two right and the agent finds your answer fast. Get them wrong, it wanders.

1.3.1 Everything is a loop

An agent runs in a loop, and the loop has a fixed shape. It takes an input: the current problem, plus some notion of what success looks like. It reasons, and it acts in its operating environment. It produces a result. And that result folds back into the input for the next turn. Input, reasoning, output, fed around again. Shaping that loop is commonly called loop engineering, and nearly everything in this book is an instance of it. The close of this chapter draws the loop with the engineer's control points marked (Figure 1.3-2).

The loop that produces has this shape (Figure 1.3-1): a goal becomes a model, the agent builds, evidence meets judgment, and the model sharpens each pass.

The printer loop — the loop that produces A five-step loop drawn left to right. A goal — what you want built — becomes a model, the structured description. The agent builds from the model; this is the printer running. The build is evidence: what actually came out. Judgment reads the evidence against intent, asking whether it matches. A dashed return path runs back from judgment to the model, labeled: refine the model, a sharper description each pass. This is the same loop shape as the governance-conversion loop — this one produces the work and sharpens the model; that one hardens the environment when the loop keeps hitting one wall. Goal what you want built Model the structured description Agent builds the printer runs Evidence what came out Judgment does it match intent? refine the model — a sharper description each pass
Figure 1.3-1. The Printer Loop. The loop that produces: a goal becomes a model, the agent builds, evidence meets judgment, and the model sharpens each pass.

Engineering a loop well starts with the metric, because the metric is what the agent steers by. The agent does not magically know your goals or your environment. You have to make its progress measurable — deterministically, through a quantitative check, or through a rubric that scores a qualitative result. Skip this, and you have told the agent nothing about what "done" means, so it searches, and searches, and searches, and never knows when to stop.

The orchestration layer of this book's companion repository is itself a worked example of a loop engineered this way. The catalogue models the orchestrator — the process that dispatches agents, waits for them to land work, and cleans up after them — as an explicit reactive loop with a typed lifecycle: dispatch → work → land → tombstone, then refill and go again. The loop is written down as a model the agent can read — which is the second idea.

Learn more about this governance mechanism: orchestrator model.

Dispatch. To hand a scoped unit of work to an agent and launch it; the orchestrator's act of starting a worker on a task.

Tombstone. The end-of-life marker an agent writes when its work has landed, signalling that its worktree is finished and safe to clean up.

1.3.2 Give it a model of the world

Vibe coding treats the program as an I/O device; engineering treats it as a system.

The difference is not aesthetic. It is what counts as proof that a change is good. Treat the program as an I/O device and the only question is whether the right thing came out this time. Treat it as a system and you ask what must stay true across every input, and you build the structure that holds the answer. Agents make both modes cheap, which is why you have to choose deliberately. The fast, seductive default is the I/O device, and the I/O device is what turns a hundred thousand lines into a mess nobody can reason over.

The second piece is the input the agent reasons over. You have to give it a sense of the environment: when it pulls this lever, what happens, and what is it even allowed to do? That sense of the world is itself an input, and the more of it you articulate, the better the agent knows what kind of reasoning the situation calls for.

Why does this work at all? It is easy to feel you are writing documentation into a void. But a foundation model is, loosely, a probabilistic reasoning machine. Probabilistic means it does not always do exactly what you want. Reasoning machine means it genuinely reasons — the interpretability work probing these networks keeps turning up real internal structure, and even lets us steer it. The Agent Stack makes that case in full. So write the model down: the agent reads it, and it reasons over it.

Think of the agent's behavior as a search. It is searching an enormous space: every place the answer might live, every configuration it might try, every function that might implement what you asked. That space is far too large to sweep.

So when you structure the loop and hand over a model, what you are really doing is conditioning the probability distribution of the agent's behavior — biasing it to search where the answer actually is. Done well, this takes the agent from failing your task to completing it. And when it was already completing the task, it now does so in fewer tokens and less time — materially fewer, in my experience — so you get back to the interesting parts of your job.

A model earns its keep twice over here. It aims the search, and it shrinks what the agent has to hold — which is what keeps the work from spilling the window and churning. The case study measures that churn directly: it peaks as the environment is built, then falls as the built environment holds. For the data, see The Timeline and the Work → (preliminary)

The metaphor's seam. Lakoff and Johnson, in Metaphors We Live By (1980), show that a structural metaphor illuminates where its source and target align and misleads where they break, so naming the break is part of honest use. Here is ours: a real 3D printer is deterministic — the same G-code yields the same part, every run. This printer is probabilistic — the same prompt can yield different output. That is exactly the gap the chapter turns on. Because the agent is a probabilistic search and not a deterministic extruder, we condition its distribution rather than instruct it. The metaphor claims "you get only what you describe"; it does not claim "you get the identical thing twice."

1.3.3 The four levers of an engineered loop

Now put the two ideas back together, because they are one machine. A loop alone is generic; a thermostat runs one. What makes agent work engineerable is that the environment owns the loop's control points, and you set every one of them.

Engineered agent loop. A feedback process in which the environment supplies a modeled state, constrains available actions, measures progress against an explicit criterion, and determines whether the result may advance.

Read the definition as a list of levers, because that is what it is. Figure 1.3-2 draws them at their stations.

The engineered agent loop and its four levers One cycle, four control points. A modeled state feeds Agent reasoning, which produces an Output — a candidate result, not yet accepted. The output flows up into an Admission rule gate: if it passes, it advances and becomes the next turn's input, feeding back into the modeled state; if it fails, a dashed arrow sends the agent around again. Four numbered levers mark what the engineer controls: lever 1, the state exposed — a model, deliberately reduced, the Modeling Thesis at work; lever 2, the action surface — tools and sanctioned seams, so the wrong move is unavailable; lever 3, the success criterion — progress is measured, not felt; lever 4, the admission rule — whether the result may advance. Levers 2, 3, and 4 are the Alignment Thesis enforced in the loop. 4 Admission rule may the result advance? the next turn's input fails — run again Modeled state what the agent sees Agent reasoning then action Output a candidate result 1 The state exposed a model, deliberately reduced — the Modeling Thesis lever 2 The action surface tools and sanctioned seams — the wrong move is unavailable 3 The success criterion progress is measured, not felt Lever 1 is the Modeling Thesis at work; levers 2, 3, and 4 are the Alignment Thesis, enforced.
Figure 1.3-2. The Four Levers. The engineered agent loop — modeled state in, reasoning and action, a candidate output, fed around again. The four numbered levers are the engineering: the state exposed, the action surface, the success criterion, and the admission rule that decides whether the result advances.

The four levers are the book's two theses in miniature. The first — a modeled state — is the Modeling Thesis: bind intent and structure into an explicit model, and the agent reasons through it while the engineer specifies, analyzes, and predicts on it. The other three — constrained actions, an explicit criterion, an admission rule — are the Alignment Thesis: mechanisms the environment enforces, holding the output to intent. Part 2 builds the second set; Part 3 builds the first.

The preface named churn as the wall a fleet hits and traced it to three not-knowings. The levers are where those causes get treated. Not knowing what to build and not knowing how to realize it are failures of the exposed state; the modeled state answers both. Not knowing how to change the system safely is a failure of the other three levers — an unconstrained action, an unmeasured criterion, an ungated admission. That is the division of labor the book runs on: modeling treats the first two not-knowings, alignment the third.

© James C. Davis, 2026–present