Everyone optimises the prompt. The teams that win optimise the loop.

1. Why now: the atom of AI work

The chat box taught everyone the wrong mental model. It made AI feel like a vending machine: insert prompt, receive output. The teams getting real value in 2026 threw that model away and replaced it with a loop that keeps going until the answer holds up.

Why now is simple. The tools finally make loops native. Agents that plan, call tools, run tests and retry are no longer a research demo; they ship in the products people use daily. And the evidence has caught up: systems that keep the same model but wrap it in a better loop now beat systems with a stronger model and no loop. That single fact reorganises how a business should think about adopting AI, and it is where this manual begins.

One clarification before we go further, because the word "agent" gets thrown around loosely. An agent is not a special kind of model. It is a model placed inside a loop, given tools to act with and a way to check its own results. The same model that answers a chat message becomes an "agent" the moment you wrap it in gather, act, verify and let it run more than once. So when this series talks about building good agents, it is really talking about building good loops around ordinary models. That is the whole trick, and the rest of this dossier is about how the trick works.

2. Ask-and-receive versus the loop

Put the two side by side. A single API call is ask-and-receive: one prompt in, one answer out, no memory, no tools, no check. You keep whatever comes back, right or wrong. Useful, and sharply limited.

A loop is different in kind. It gathers the context the step needs, acts by calling tools or taking a real action, and verifies the result against a test or a judge. When the check fails, the whole thing runs again with what it just learned. That retry, on failure, with updated context, is the entire difference between calling an API and running an agent.

Take a concrete task: "find the three customers most at risk of churning this month and draft an email to each." As a single prompt, the model has no data, so it invents plausible names and generic emails, confident and useless. As a loop, it queries the real usage data, ranks the accounts, checks each against the definition of "at risk," pulls each customer's history, drafts an email grounded in that history, and flags any it is unsure about for a human. Same model, entirely different outcome, because the loop did the gathering, acting and checking that a single call cannot. That is why a loop can finish work a single call never could.

3. The three phases: gather, act, verify

The loop has three phases, and naming them makes the rest of this series legible.

Gather pulls together everything the model needs right now: the relevant context, the memory of what happened before, the right tools. Act runs the model and lets it do something, call a tool, write a file, hand off to a sub-agent. Verify checks the output before it counts, with a test, a second model acting as judge, or a fresh pass. Then, on failure, repeat.

Two of the five parts in this series live almost entirely inside Gather: context engineering is how you decide what goes in, and the harness is the machine that assembles it. The other parts are about Act and Verify. The reason to learn these three words is that they let you diagnose any AI system that is misbehaving. An agent that hallucinates usually has a Gather problem: it was not handed the facts it needed. An agent that does the wrong thing has an Act problem: bad tools or unclear instructions. An agent that confidently ships errors has a Verify problem: nothing checked its work. Almost every failure in practice is one of those three phases missing or done badly.

4. A loop, traced step by step

Abstractions are easy to nod along to and hard to actually picture, so here is a loop running, traced one step at a time. The task is ordinary: an agent is asked to fix a failing test in a piece of software. Watch the three phases repeat.

Nothing here is clever, and that is the point. The agent did not get the fix right on the first try, exactly like a human would not. What made it succeed was not brilliance; it was the loop. Step three failed, and instead of shipping the broken fix, the system noticed the failure, fed the errors back in, and tried again. A single prompt would have stopped at step two with a plausible fix that did not work. The loop kept going until the tests actually passed.

This is worth sitting with, because it inverts a common intuition. People assume a more reliable AI system needs a smarter model. Often it just needs a loop with a real check, so that being wrong on the first attempt is survivable rather than final. The trace above would look almost identical for a marketing agent checking its copy against brand rules, or a finance agent reconciling an invoice against a purchase order. Gather, act, verify, repeat. The domain changes; the shape does not.

5. Verify is the phase everyone skips

If one phase separates a demo from a system, it is Verify, and it is the one people skip. A loop with no check is just a faster way to be confidently wrong. The model produces something plausible, nothing tests it, and the error ships.

Picture the churn-email agent from section two, built without a verify step. It queries the data, ranks the accounts, and drafts three emails, one of which cheerfully offers a discount the company does not actually offer, because the model guessed. Nothing checked the offer against the real price list, so the email goes out and now the company has promised something it will not honour. Add one verify step, "check every offer in the draft against the current price list, and flag anything that does not match," and the error is caught before it leaves the building. The model did not get smarter. The loop got a check.

This is why the loop and the eval are two sides of one idea. You cannot loop until right without a way to know what right is. The teams who get reliable work out of AI are rarely the ones with the cleverest prompts. They are the ones who defined, up front, how the loop knows it is done: the test that must pass, the rule that must hold, the second model that must approve. The final part of this series is entirely about building that check well, because it is the hardest and most valuable part of the whole stack.

6. The loop that improves itself

The clearest proof that the loop, and not the model, is doing the work comes from systems that improve while the model underneath stays fixed.

Sakana's Darwin Godel Machine is an agent that rewrites its own code. It works in a loop: propose a change to itself, test the changed version on a coding benchmark, keep the change if it scored better, and repeat. Over eighty rounds of this, it climbed from twenty to fifty percent on SWE-bench and from about fourteen to thirty-one percent on a second benchmark, all on the same foundation model. Along the way it invented improvements a human might have added by hand, better tools for editing files, a step that validates its own patches, a way to avoid repeating past mistakes, and it invented them because the loop rewarded whatever scored higher.

DeepMind's AlphaEvolve runs the same shape of loop on algorithms rather than on itself: generate many candidate solutions, evaluate each one automatically, keep the winners, and let them breed the next generation. Pointed at Google's own infrastructure, it found real improvements to data-center scheduling and to chip design, and even discovered a faster kernel that shaved about one percent off the training time of the model underneath it. Neither system got a smarter model. Each got a loop that checks its own work and iterates. That is recursive self-improvement, in a measured and controlled form, already running, and it is the strongest possible evidence for the claim this dossier keeps making: the loop is where the leverage is.

7. Plan, act, observe, reflect

Zoom in on a single pass of the loop and a smaller pattern keeps recurring: plan, act, observe, reflect. The agent breaks a goal into steps, takes one, reads what happened, and decides what to do next. Microsoft's Magentic-One made this explicit with an orchestrator that asks the same short list of questions after every step: is the task complete, is the team looping or repeating itself, is progress being made, who should act next, and what should they do.

Those five questions are worth stealing even without any code, because they are exactly the questions a good project manager asks. Imagine an agent researching a market. After each search it should ask: do I have enough to answer the question yet? Am I just re-reading the same sources? Am I actually getting closer, or going in circles? What is the most useful next search? An agent that asks these keeps making progress. An agent that does not either declares victory too early, stopping at the first plausible-looking answer, or spins forever, re-running near-identical searches without noticing. A loop without a reflect step drifts. A loop that asks "am I actually making progress" every time is the one that arrives.

8. Loops inside loops

Real systems are not one loop but loops nested inside loops. The coding agent from section four shows it. There is an outer loop, "implement this feature," and inside it an inner loop for each small piece, "write this function, run its test, fix it, run it again," before the outer loop moves on to the next piece. Magentic-One described exactly this: an outer control loop for the whole task and an inner one for each step.

This matters for how you think about scale. You do not design one giant loop that does everything at once; that is how you get an agent that is impossible to debug and behaves differently every run. You design a small loop that does one thing reliably, verify that it works, and then wrap it in a larger loop that orchestrates many of them. A document-processing system might have an inner loop that reliably extracts the data from one invoice, wrapped in an outer loop that runs it across ten thousand invoices and handles the ones that fail. The fourth part of this series, workflows and agents, is entirely about that wrapping, when to compose loops as a fixed sequence and when to let a lead agent orchestrate them. For now the point is that the loop composes: get one small loop right, and you can build the large system out of copies of it.

9. Closing the loop in a business

So far this is engineering. Here is the version that decides whether AI shows up in your results. Most corporate AI pilots stall, and the reason is usually that they are open loops: an impressive demo answering a one-off prompt, with nothing flowing back in and nothing checking the output. It wows the room and then goes nowhere.

A closed loop has three parts, as Exponential View put it: a real signal flowing in from the business, an operating graph that holds the relationships the agent needs, and a defined scope for what it may act on, with a check that closes the loop before it runs again. The difference between an open and a closed loop is the difference between a clever demo and something that moves a number.

The practical instruction that follows is almost boring. Do not chase a broad, open-ended AI capability. Pick one tightly scoped loop, wire a real signal into it, give it an owner and a check, and close it. That is what moves a number. A demo is an open loop; value is a closed one.

10. The autonomy boundary

The closed-loop picture contains the single most useful governance idea in agentic AI: the autonomy boundary. Not every action inside the loop should be taken by the machine alone. Whether the agent acts or escalates to a human should depend on three things: the value at stake, the confidence in the answer, and the reversibility of the action.

Drawn as a simple table, for the invoice and refund agents, it looks like this:

Read down the table and the rule draws itself. Low value, high confidence, easily undone: let the loop run on its own. High value, lower confidence, hard or impossible to reverse: a human decides. Drawing that line explicitly, action by action, is what makes autonomy safe to grant, and it answers the fear that agents will run wild. A well-built loop does not have unlimited scope; it has a boundary, and everything past it routes to a person. The last part of this series returns to this, because deciding what to trust the machine with is a skill, not a checkbox.

11. The honest counter-case

Loops are not free and not always right. Three honest caveats. First, a loop that cannot tell good from bad amplifies error instead of converging: it will iterate confidently toward the wrong answer faster than a single call would. The verify step has to be real, or the loop makes things worse rather than better. A loop that "checks" its work by asking the same model "does this look right?" often just gets a confident yes, which is verification theatre, not verification.

Second, loops cost. Every iteration is more tokens, more time and more money. A multi-agent loop can burn a large budget for a marginal gain, and sometimes a single well-aimed call really is the right tool for a simple task. Matching the weight of the loop to the value of the task is part of the craft, not an afterthought. Third, autonomy raises the stakes of a bad check: the more a loop is trusted to act on its own, the more a weak verify step can do damage before anyone notices, which is exactly why the autonomy boundary in the previous section matters.

None of this argues against the loop. It argues for building the loop with the same care as the model: a real check, a bounded scope, and a cost you have looked at. The failure mode of loops is a weak check. A loop that cannot judge its own output does too much, too confidently.

12. What a business does with this

For a leader the takeaway is not to go build agents. It is a lens for every AI initiative in the building. Ask of each one: is this an open loop or a closed one? Does a real signal flow in? Is there a verify step, and does someone own it? Where is the autonomy boundary drawn? Most stalled pilots fail one of those questions, and naming which one is usually the fix. A pilot that "answers questions" but never acts is an open loop; a pilot everyone loves in the demo but no one uses is missing a real signal; a pilot that occasionally ships an embarrassing error is missing a verify step.

This is the See, Understand, Adopt method applied to AI's basic unit. See whether the thing in front of you is a demo or a loop. Understand the three phases and where your process breaks, almost always at Verify. Then adopt by closing one loop properly rather than opening ten. Pick a single, high-frequency, well-scoped task, invoice matching, ticket triage, lead scoring, wire the real signal in, add a genuine check, draw the autonomy boundary, and close it. One closed loop that runs every day beats ten open demos that impressed once. The rest of this series builds outward from here: the harness that runs the loop, the context that feeds it, the patterns that compose many loops, and the verification that lets you trust them.

13. Verification and sources

This dossier draws on live web research and a personal archive of more than 15,000 sources. Load-bearing numbers were cross-checked where possible. The worked examples and traces are illustrative, built to explain the mechanics rather than to describe a specific named system. The notes below flag confidence and the main caveats, in the spirit of showing our work.

The framed figure in this dossier is taken from publicly posted material, credited to the original source in its caption. Charts labelled "BFF" are our own, drawn from the sources named beneath them. Traces and scenarios are illustrative, written to teach the idea.