The Loop

01

Why this, why now

For two years the popular image of AI has been a chat box: type a question, read an answer. That image is now the main thing holding teams back. The systems doing real work in 2026 do not answer once. They run a loop, gathering what they need, acting, checking the result, and going again until the work is done.

The chat box taught everyone to think of AI as a vending machine: insert a prompt, receive an output, done. That works for a single question and falls apart the moment the task has more than one step, needs a tool, or has to be right rather than merely plausible. Consider the difference between "write me a sentence about our refund policy" and "process this refund." The first is a vending-machine task. The second is a loop: check the account, read the policy, apply the rule, confirm the amount, and only then act, with a way to notice when something is off and try again. The second shape is where real work lives, and it is not a prompt.

The shift has a short history the field mostly agrees on. First the gains came from the model itself, bigger weights and more training. Then they came from context, meaning what you put in front of a frozen model. Now they come from the harness, the machinery around the model that lets it act and correct itself. This five-part series is a field manual for that machinery, and it starts here because the loop is the atom everything else is built from. The later parts, the harness and context engineering and workflows versus agents and trust and verification, are all ways of running a better loop.

02

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, and 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 enough. The tools finally make loops native, since agents that plan and call tools and run tests and retry are no longer a research demo but ship in the products people use daily. And the evidence has caught up, because systems that keep the same model but wrap it in a better loop now beat systems with a stronger model and no loop.

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.

03

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 and acting and checking that a single call cannot.

04

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, whether calling a tool or writing a file or handing off to a sub-agent. Verify checks the output before it counts, with a test or 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 misbehaving in front of you. An agent that hallucinates usually has a Gather problem, because it was not handed the facts it needed. An agent that does the wrong thing has an Act problem, meaning bad tools or unclear instructions. An agent that confidently ships errors has a Verify problem, because nothing checked its work. In our experience almost every failure in practice is one of those three phases missing or done badly.

05

4. A loop, traced step by step

Abstractions are easy to nod along to and hard to 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.

Loop trace · a coding agent fixing a failing teststep 1 gather read the failing test + the 2 files it touches step 2 act write a first fix step 3 verify run the tests -> 2 of 12 still fail ↻ not done, so loop again with what it just learned step 4 gather read the exact errors from the 2 failures step 5 act adjust the fix to handle the edge case step 6 verify run the tests -> all 12 pass ✓ done.

Nothing there is clever, and that is the point. The agent did not get the fix right on the first try, exactly as a human would not. What made it succeed was not brilliance but 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.

This is worth sitting with, because it inverts a common intuition. People assume a more reliable AI system needs a smarter model, when 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 and the shape does not.

06

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 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 the company has now promised something it will not honour. Add one verify step, checking every offer in the draft against the current price list and flagging 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, because 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.

07

6. The loop that improves itself

The clearest proof that the loop rather than 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, repeat. Over eighty rounds 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, including better tools for editing files and a step that validates its own patches and 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 automatically, keep the winners, let them breed the next generation. Pointed at Google's own infrastructure it found real improvements to data-centre scheduling and to chip design, and discovered a faster kernel that shaved about one percent off the training time of the model underneath it. That last figure is worth stating precisely rather than dramatically, because "the AI sped up its own training" is a much bigger claim than a one percent total-time saving from a single matrix-multiply kernel.

Neither system got a smarter model. Each got a loop that checks its own work and iterates, which is recursive self-improvement in a measured and controlled form, already running.

08

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 if you never write a line of code, because they are exactly the questions a good project manager asks. Imagine an agent researching a market. After each search it should be asking whether it has enough to answer the question yet, whether it is just re-reading the same sources, whether it is actually getting closer or going in circles, and what the most useful next search would be. 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.

09

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 for implementing the feature, and inside it an inner loop for each small piece, writing a function and running its test and fixing it and running it again, before the outer loop moves on. 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, because that is how you get an agent nobody can debug that behaves differently every run. You design a small loop that does one thing reliably, verify 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 is entirely about that wrapping. 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.

10

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. This is a framework rather than a measured finding, and we use it because it matches what we see rather than because anyone has quantified it.

Open loop versus closed loop Open (the pilot that stalls): a team builds a chatbot that can "answer questions about invoices." It demos beautifully. Nothing feeds it real invoices, nothing acts on its answers, and after the applause it is used by no one. Closed (the version that pays): every incoming invoice is the signal. The agent reads it, matches it against the purchase order and the goods-received record (its operating graph), and, if the three agree and the amount is under a set threshold, approves it for payment. Anything that does not match, or is over the threshold, routes to a person. It runs on every invoice, learns from the exceptions, and shows up in the numbers as days of finance time saved each week.

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. A demo is an open loop and value is a closed one.

11

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, and whether the agent acts or escalates 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.

12

11. The honest counter-case

Loops are not free and not always right, so three caveats. First, a loop that cannot tell good from bad amplifies error instead of converging, iterating confidently toward the wrong answer faster than a single call would. The verify step has to be real, or the loop makes things worse. A loop that checks its work by asking the same model whether it looks right usually just gets a confident yes, which is verification theatre.

Second, loops cost. Every iteration is more tokens and 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 rather than 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 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 actually looked at.

13

12. What a business does with this

For a leader the takeaway is not to go and build agents. It is a lens for every AI initiative in the building. 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 nobody uses is missing a real signal. A pilot that occasionally ships an embarrassing error is missing a verify step.

This is See, Understand, Adopt 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, which is almost always at Verify. Then adopt by closing one loop properly rather than opening ten: pick a single high-frequency well-scoped task, whether invoice matching or ticket triage or 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 move: stop grading prompts and start designing loops. Pick one tightly scoped, high-frequency task; wire a real signal in; add a genuine check so the loop knows when it is done; draw the autonomy boundary action by action; and close it. One closed loop beats ten open demos.

14

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.

Back From the Future · BFF Insights · Working with AI · Part 1 of 5 · July 2026