Most companies still use AI by assigning tasks. Open a chat, say one thing, watch it finish, say the next thing. When you're satisfied you close the window; tomorrow you open it again and say it all again. The time saved is real, but the way it gets saved looks a lot like hiring a very capable temp: you train them every day, and every day you start from scratch.

Time only starts to accumulate when you work differently. Instead of telling the system "do this now," you write down three things, once: what counts as done, when it should start, and how far it's allowed to reach. Then you let it run and check itself, and it comes back to you only when it hits a boundary. The industry calls this way of designing work loop engineering. The name sounds far off. Doing it is closer than you'd think.

Here's a scene from the field. At a home-goods company, the marketing team has to check every Monday morning whether three competitors have put out new content, changed their prices, or switched their main selling point. It used to be that someone turned on the computer, opened three tabs, copied and pasted, and wrote it all up in an email to the owner: an hour at minimum. Once it became a loop, the job turned into a fixed set of rules. Start every Monday at 8 a.m. Compare those three URLs against last week's record. List only what changed, with the original link attached to every item. If nothing changed, reply with one line: "No changes this week." If it fails to pull the data three times in a row, stop and say so.

Nobody opens those three tabs anymore. What someone does now is look back once a quarter and check whether that set of rules is still right.

01A loop that actually runs has only three parts

The first part is the goal: what counts as done.

This is where most people get it wrong. Most people give instructions by describing a process: "Check whether the competitors have updated anything and put it together for me." It sounds clear, but there's no finish line. How far does "put it together" have to go to count as good? Does missing one company count as a failure? Without answers, the system can only guess. When it guesses wrong you add another sentence, and by the end you've spent about as much time as you would have doing it yourself.

Engineers put it bluntly: don't tell the AI how to get there; tell it where "done" is. There's a handy test for it, too: could a stranger handed the result tell on their own whether the job is finished? If you can answer that, it's a goal. If you can't, it's still just a wish.

The second part is the trigger: when it starts.

It can run on a schedule, like every Monday morning or before closing the books on the 5th of each month. Or it can run on an event, like a customer email landing in a particular inbox or a new row appearing in a particular spreadsheet. This part looks the most technical, but it's actually the least: it asks which things in your company run on a fixed rhythm. An owner who's been in business for ten years can answer that faster than anyone.

The third part is the boundary: how far it's allowed to reach.

A boundary has two halves. One is scope: which data it can read, which files it can change, and which areas it must never touch. The other is stopping rules: stop after how many failures, run at most how many rounds, report back once spending passes how much. This second half is the one most often skipped, and the most expensive. It gets its own section below.

Goal, trigger, boundary. Fill in all three and the job goes from "something you have to explain every time" to "something that runs on its own." Leave one out and it will drift off course, or keep burning money.

02The people who need this most aren't the ones who write code

Almost every article about loops in recent years comes out of a coding context, and that's the main reason the idea hasn't caught on. Owners read two paragraphs and decide "this isn't my problem."

In practice, the easiest places to put it to work are the operational chores that repeat every week, have a clear output, and nobody wants to do. One list that collected twenty-five loop workflows had more than half of them unrelated to coding:

  • Compare three competitors' pages every week and report only what changed.
  • Sort incoming email into three piles, "owner needs to see," "reply as usual," and "set aside for now," with the reasoning attached.
  • Before closing the books, pull together everything required and flag the items that don't match, so a person only deals with those few.
  • When an invoice is overdue, draft a reminder email; whether it gets sent is a person's call.

What the four have in common is obvious: they repeat, they have an end point, you can tell right from wrong, and nobody likes doing them. Another roundup put the conditions in four lines: it repeats, completion can be judged automatically, the cost is bearable, and the tools you have can reach the data. If one of the four is missing, hold off on setting it up.

"Isn't this just a new name for scheduling plus automation?" People in engineering communities keep raising this objection, and it isn't unfair. Scheduled jobs, workflows, feedback mechanisms: these have been around for a long time. Only one thing is genuinely new. It used to be that every step had to be hard-coded in advance by a person; now the stretch in the middle can be handed to a model's judgment, and the person only has to write down the finish line and the boundaries. So rather than arguing about the name, look at the job in front of you and ask whether the judgment calls in the middle used to require someone sitting there.

03It only works if it can hit the brakes

A loop's greatest strength is that it keeps running. Its greatest danger is also that it keeps running.

The official documentation puts the definition plainly: a loop is a system executing round after round until a stopping condition is triggered. The whole sentence rests on those last two words: stopping condition. Without one, two kinds of cost come knocking.

The first is money. A loop without a cap will burn through the budget. In real-world testing, four times the usage is normal, and when multiple systems call each other it can reach fifteen times. Nobody will warn you about this bill. It just shows up on the invoice at the end of the month.

The second is harder to spot: the system falls into a state where it looks like it's making progress but is really going in circles. The same file revised seven times, each pass reported as "optimized," and all seven together no better than the first. The worse version is when it builds out a wrong direction more and more thoroughly: highly complete, and wrong from start to finish.

So before you start, set three gates:

A completion condition a machine can judge "Every customer on the list checked, zero missing" is a condition. "Nicely organized" isn't.

A hard cap At most how many rounds, at most how much spending. When it hits the ceiling, it stops.

No-progress detection If several rounds in a row touch the same batch of data without producing anything new, force a stop and report back.

None of the three is hard to write. The hard part is admitting that in a system without brakes, power and danger are the same thing.

04Three kinds of things you should never let it finish on its own

There's an earlier question, too: should this job be set up as a loop at all?

The estimate from people with experience is that only thirty to forty percent of tasks are genuinely suited to running in an automatic loop. Quick Q&A, brainstorming, subjective trade-offs, decisions that need judgment on the spot: none of these belong in a loop. It's technically possible, but these things don't have an end point that a stranger could recognize. If you can't define done, keep doing it through conversation. There's no shame in that.

Within the part that is suited, you sort again, by color:

Green light It reads and writes only its own data, and you can hand it off entirely. Monitoring, comparing, organizing, and summarizing all live here.

Yellow light The system drafts, a person presses send. First drafts of proposals, reply drafts, notes on reports.

Red light Never runs alone: anything that touches money, anything that touches your live systems, any message sent directly to the outside world.

There are no exceptions to the three red-light items. When any of them goes wrong, what it costs you and the time it saved are completely out of proportion. Like the lobster you can't tame that we wrote about earlier: the problem was never whether it could do the work. It was whether anyone had drawn this line for it.

Your role shifts from handing out work to defining loops

Another piece looked at the layer outside the model: permissions, verification, memory, orchestration. That's what you actually own. This piece is the verb form of the same idea: how that layer actually gets put to use.

The answer is to give fewer instructions.

Before An owner's time went to explaining tasks, chasing progress, and checking whether things were done.

Now That time should go one step earlier: writing down, once, which jobs are worth running, where "done" is, and what it should run into before it comes back to ask a person.

It sounds like technical work, but doing it is all management judgment. Which work runs on a fixed rhythm, which mistakes you can afford, who has the authority to sign off: not one of these questions can a model answer for you. And the rules you write down are different from prompts. They don't evaporate when the model gets upgraded, they come with you when you switch tools, and a new hire taking over can read them.

Don't treat it as a permanent building, either. Rhythms change, data sources change, models gain native capabilities, and rules you wrote to patch a gap should be retired when that happens. Looking back regularly to check whether those few rules are still right is the maintenance cost of all this. It's lower than you'd think, but it isn't zero.

Design that can be trusted. Technology that can be understood. Getting a loop to run isn't the achievement. Getting it to run and also stop is.

Rooted in craft. Built for the new wild.