Tasks End. Loops Don't. What Loop Engineering Does to Your AI Budget.

Loop engineering is the shift from giving agents a task to giving agents a responsibility. The first kind starts when you ask and stops when it answers. The second kind never stops. That single difference is the whole story, the power and the danger, and it could arrive in your stack whether your budget planned for it or not.

For two years the mental model for working with AI was simple. You handed it a problem, it worked the problem, it handed you back an answer, and the loop closed. A human opened every job and a human closed every job. That is changing right now, and the change carries a cost profile most leaders have never had to reason about.

What is loop engineering?

Loop engineering is the practice of building agents that run continuously against a standing responsibility instead of a one-time task.

The progression is easy to see once you know to look for it. First we asked AI questions, like a smarter search box. Then we gave it tasks, like fix this bug or draft this document, where every task still started and ended with a person. Now the frontier has moved again. Instead of telling an agent to investigate one crash report, you hand it a loop: watch every crash report that comes in, indefinitely. Its job is no longer to help you fix a crash. Its job is to keep the product from crashing at all.

Notice what just happened to the unit of work. You stopped assigning tasks and started assigning outcomes. The agent owns the outcome, and it stays awake for as long as the outcome needs owning. That is a responsibility, not a task, and responsibilities do not finish.

It is worth giving the two shapes their own names, because you are going to be managing both. A bounded agent does a defined job and stops. A standing agent holds a defined responsibility and keeps running. Most of what you have deployed so far is bounded. Most of what is coming is standing.

Where did this come from?

It showed up the moment the models got reliable enough to run for hours instead of minutes.

For most of the short history of business AI, an agent that ran longer than a few minutes was an agent that drifted, broke, or hallucinated its way off the rails. You could not trust it unattended, so you did not leave it unattended. That constraint just lifted. The current generation of models can run a single job for nine hours, twelve hours, in some cases across multiple days, holding context the whole way and recovering from its own mistakes instead of compounding them. Once that became reliable, the loop became practical. And the moment the loop became practical, somebody can always leave one running.

That somebody could be inside your company, and they are not asking permission.

Why does a loop burn tokens like nothing before it?

Because a task has a finish line and a loop does not.

This is the part that will surprise the finance side of your business, so say it plainly. A task has a bounded cost. You pay for the work, the work completes, the meter stops. You can estimate it, you can cap it, you can put it in a spreadsheet. A loop has no finish line, which means its cost is not bounded by the work. It is bounded by time. The bill is roughly the run rate multiplied by how long the loop stays alive, and a loop nobody remembered to turn off stays alive at three in the morning on a Sunday when nothing is happening, quietly metering the whole time.

Call it the standing cost. The standing cost is what you pay simply to keep an agent awake and watching, separate from what you pay for the useful work it occasionally does. A bounded task only ever charges you for output. A standing loop charges you for vigilance, and vigilance runs around the clock. Leave a handful of these going unscoped across the business and you have built something that consumes budget at a constant rate with no natural reason to ever stop.

This is the mechanic behind every horror story you are about to hear about a surprise AI invoice. It is not that the agent did something expensive. It is that the agent did nothing, expensively, for three weeks.

What separates a loop that pays for itself from one that bankrupts you?

A kill condition.

Every loop you deploy needs an explicit rule for when it stops, escalates, or downshifts to something cheaper. Not a vague intention to check on it later. A defined condition, written before the loop ever runs, that answers three questions: when does this loop wake up, when does it stand down, and when does it pull in a human instead of spending more on its own. A loop without a kill condition is not an agent. It is a leak with good intentions.

We see teams reach for tooling first, rotating across different model providers to dodge usage limits, treating the symptom as if it were the disease. That buys a little runway. It does not buy control. The reason an unscoped loop is dangerous has nothing to do with which provider you bought it from. It has to do with the fact that nobody defined when it was allowed to stop. The real fix is architectural. The agents have to be scoped to a specific outcome, observable enough that you can see what each one costs in real time, and owned by a person whose job includes turning them off. That foundation is the entire difference between a workforce of loops that compounds value and a server farm that compounds your bill.

What should you do about loop engineering?

Install a kill condition on every loop before you let it run unattended. That is the one rule. If you do nothing else, do that.

Then build the layer underneath it. Scope each loop to one outcome you can name out loud. Make every loop observable, so the standing cost shows up on a dashboard during the month and not on an invoice at the end of it. Give every loop an owner who is accountable for both what it produces and what it costs. The companies that win the loop era will not be the ones running the most loops. They will be the ones who knew exactly when each loop was supposed to stop.

The task era was forgiving, because tasks end on their own. The loop era is not, because loops do precisely what you let them. Decide what you are letting them do before you turn them on.

YOR.AI builds AI agents that are scoped to a real outcome and architected so you can see what every one of them costs and produces, loops included. If you are about to put standing agents into production and want them built with a kill condition from day one, reach us at contact@theyor.com.