Nothing Turns Green

The loop would have emailed thirty-five people twice. Real people: hotel event planners, a convention-center manager, the kind of contacts you get one shot at. It had the list, it had its instructions, and on its second run it would have started down the same list again, politely, because nothing in it remembered the first run. I caught it before it sent. The fix took an hour. The lesson has taken longer, and it is why I think most of what is being written about agent loops right now describes the easy half of the problem.

If you have been near tech writing lately, you have seen the loop. The idea is that you stop typing instructions to an AI one at a time and instead describe a goal, then let a system pursue it on its own until it gets there or gives up. Good idea. It is also, in nearly everything written about it, an idea about code, and there is an assumption buried underneath all of it: that when the agent finishes a pass, something other than the agent can tell whether the work is any good.

In code, something can. You run the test suite, the build comes back red or green, the types check or they do not. Simon Willison put the real prerequisite plainly: the value you get from a coding agent is massively amplified by a good, cleanly passing test suite. The tests are doing the heavy lifting, not the model. That is what lets a coding loop run all night without you, because the question of whether the work is correct has been handed to a machine that answers in seconds. Not an infallible machine. Green tests miss bugs they never exercised, and a passing build can still ship a logic error. But it is cheap, it is fast, and it is right far more often than not, and that turns out to be enough. Code ships with an oracle. You did not build it. You inherited it from forty years of people deciding that software should be able to check itself.

Point the same loop at operations and the oracle is gone.

Ask an agent to draft a batch of outreach, or reconcile last month's numbers, or answer a support thread, then ask the question the test suite used to answer: is it done? Nothing runs. The agent says it finished, in the same confident tone it uses when it is right. But a reconciliation can balance to the penny and still book a payment to the wrong account, and an email can send cleanly and still cost you the relationship. "Done" goes back to being a judgment a person has to make.

The economics invert too, in a way the coding pieces never have to reckon with. In software, making is expensive and checking is cheap: you pay a senior engineer to build the feature and a fraction of a cent to run the tests against it. Operations runs the other way. An agent will draft you eighty-eight win-back emails in a minute, and the drafting was never the hard part. The hard part is deciding whether sending them is accurate, compliant, and safe for a relationship you spent two years building. Some of that you can check mechanically. The rest is judgment, and the judgment was the bottleneck the whole time. It did not get cheaper when the drafting did.

You have to manufacture the oracle

It comes in three layers, built from the cheap end up. At the bottom are rules, the things that are simply true or false: is this contact already in the ledger, is the batch over the cap, is the unsubscribe link missing. No intelligence required, no fatigue, and they catch the stupid mistakes that do the most damage. In the middle sits a second model that grades the draft against a written standard, and the one rule that matters there is that it never sees who wrote the draft, because a model asked to check its own work passes it every time. At the top is you, looking only at what the first two layers could not settle.

If you are reading every draft, you have not built a verifier. You have hired yourself as one.

The obvious problem is that I have just moved the question up a level. The grader is a model with no oracle of its own, so who says it grades well? Nobody, at first. You calibrate it the slow way: read its verdicts next to your own on a sample, find where it runs soft or harsh, and tighten the written standard until the two of you agree. A verifier is not something you build once and trust. It is an instrument you keep checking against your own judgment, and you only let it run unwatched on the dimensions where it has already earned that. The calibration never fully ends, because what counts as good drifts. The brand voice shifts, a compliance rule changes, and a standard you froze in March is quietly wrong by June.

Here is what the verifier looked like for the loop that almost sent twice. The rules: no more than twenty emails in a run, thirty in a day, no one contacted who had heard from us in the last thirty days, every address checked against a ledger first. None of those numbers are clever, and I set them in an afternoon. They are also the only reason I can leave the loop running instead of standing over it.

The limit that matters is not a count

Look at what those limits are really protecting against, because it is not what the coding pieces worry about. They worry about two things, both about consumption: a loop that spins forever, and a loop that burns the budget. The fixes are an iteration cap and a spend ceiling. Fine, but those answer the question of how much the thing can use up, and in operations that is the wrong question. A runaway code loop wastes an afternoon and some tokens, and you delete the branch. A runaway operations loop sends the email, moves the money, files the document, and none of that sits on your bill. It sits in the world, where delete does not work.

So the limit that matters in operations is not a count but a property of each action: can it be undone? This is the old one-way-door idea, and it is not mine, but almost nobody applies it to agent loops, which is strange, because it is the only guardrail that maps to what actually goes wrong. Before a loop does anything on its own, you ask whether the world can be put back afterward. Pulling a report or drafting a file can be thrown away at no cost, so hand those over completely. Sending the message cannot be unsent, so it does not get full autonomy, however good the model gets.

The catch is that "can it be undone" is rarely a clean yes or no, and the real work is in the middle. You can send a correction, but the recipient already read the first email. You can refund the charge, but the chargeback still dinged your processor. The honest test is not whether an action is reversible in theory. It is whether it can be undone before anyone notices or pays for it. Sort the loop's actions by that, give the machine the ones that pass, and keep your hand on the ones that do not. That sorting is most of the design, and it is harder than writing the loop.

It helps to be honest about how ordinary the machinery is, because the people selling "autonomous agents for operations" are not. Most of what carries that label is a workflow: a fixed set of steps, every branch chosen by a human in advance, with a model dropped into one slot. That is automation, often good automation, and it is not a loop. A loop is the harder, stranger thing where the agent chooses the next step itself against a goal you gave it. The skeptics have a point. The scheduling underneath is unglamorous, and plenty of "agentic" pilots never move a number anyone cares about. The mechanism really is mundane. The discipline is the verifier you had to manufacture and the reversibility you had to sort, and neither of those lives in the word "agent".

Write the definition of done first

None of this removes you. It moves you to the edge of the work instead of the middle of it. You stop doing the steps and start writing down, before the fact and precisely enough to be checked, what a good result is, then ruling on the cases the checks could not. It is a real change, and it does not suit everyone. It rewards the people who can say exactly what they want and be held to it, and it is unkind to the ones who have been getting by on "I'll know it when I see it". Hand a loop a vague standard and it will give you back vague work, faster than you could have produced it yourself.

If you want to understand any of this, do not start with the loop. Start with the verifier. Take one thing you do over and over, and before you automate a single step, write down how you would know the output was good, in terms specific enough that a rule or a second reader could apply them without you in the room. Most people find they never wrote it down, that it has been living in their head as a feeling they apply by instinct. Dragging it into words is the hard part, and the useful one. The loop is easy after that. The thing code got for free, and operations never will, is a definition of done. Write yours first.