OpenAI Becomes the Work Layer, AI Search Rewrites the Publisher Model, Why AI ROI Can't Be Tool-Led — What Loop Engineering Is, and How the Tech Function in Financial Services Is Adopting AI

The shift from prompting an agent yourself to designing the system that prompts it for you.

You may have heard the phrase "loop engineering." It got its name in June 2026, when Peter Steinberger posted that you shouldn't be prompting coding agents anymore — you should be designing the loops that prompt them. Google's Addy Osmani named and structured the idea the next day, and Anthropic's Boris Cherny, who leads Claude Code, put it bluntly: "I don't prompt Claude anymore. I have loops running. My job is to write loops."^[1,2,3]

Prompt engineering is: write one good instruction. Loop engineering is: build the system so the agent finds work, acts, checks the result, and knows when to stop — without you typing the next prompt each time. The cleanest way to hold the concept is a stack, where each layer wraps the one inside it rather than replacing it:

Prompt engineering — the words you send. Context engineering — everything the model can see when it answers. Loop engineering — the repeating cycle that drives the agent toward a goal, on a schedule or a trigger, with you out of the per-step seat.^[2] A loop runs roughly: Goal → Act → Check the result → Fix or continue → Stop when a condition is met. Note where the weight sits. Most coverage draws the cycle and makes Act look like the hard part. It isn't.

The part most coverage misses

The hard part of a loop is not autonomy. It is the check and the stop. The most useful line in the whole discourse: a loop is a task with a check; a task without a check is just hope.^[4] An agent that acts ten times without a real verification step doesn't do ten times the work — it compounds ten times the error, faster, with less of you watching. The craft of loop engineering is making the check real and defining what proves the agent should stop. Everything else — model choice, scheduling, helper agents — is secondary.

The other reframe that carries the whole idea: in the loop versus out of the loop. The old way put a human inside the loop — you gave an instruction, read the answer, typed the next one. Loop engineering puts a small designed system in that seat instead. That's the actual shift. It's also why "draft this email, then review it, then give me the improved version" is not loop engineering — it's a good multi-step prompt, but you're still the one in the seat, hitting enter.^[3]

"So what do I actually use to loop?"

A year ago, a loop meant writing and babysitting your own pile of shell scripts. The shift in 2026 is that the pieces now ship inside the agent tools, so for most people the answer is: the same tool, with a feature you may not have turned on.^[5] The two that matter today are Claude Code and OpenAI Codex. They've converged on the same primitives with different names:^[6,7]

A scheduled or triggered run — in Claude Code, routines that run on a recurring schedule, a GitHub event, or an inbound API call (managed from the CLI with /schedule), plus /loop for re-running a prompt on an interval inside an open session; in Codex, the Automations tab. This is what makes a loop a loop instead of a one-off.^[7] A goal command (/goal in both) — sets a completion condition and the agent keeps working across turns until that condition holds, then stops on its own. This is the stop rule, made into a feature.^[6] Worktrees, skills, and connectors — isolation so parallel runs don't collide, written-down project knowledge so the agent doesn't re-guess every cycle, and MCP connectors into the tools you already use.^[5]

You don't have to be a developer to recognize the principle. Plenty of non-coding tools now have the same two ingredients: a trigger (a schedule, an incoming email, a new row) and a goal-shaped instruction ("don't stop until you've found three options with confirmed pricing").^[8] If a tool can start itself on a trigger and check its own output against a condition you wrote, you can build a loop in it.

This isn't a hunch; it's baked into how the better tools are built. Claude Code's /goal, for instance, hands the "are we done?" decision to a separate, smaller model that only reads what the working agent wrote down — it can't run your tests itself.^[6]

The honest counter-current

The people who coined the term are themselves cautious, and that caution is the story, not a footnote. Osmani called himself skeptical and warned that token costs swing wildly depending on whether you're "token rich or poor."^[2] The recurring failure modes practitioners name: weak verification (the agent declares done without proof), comprehension debt (output ships faster than anyone can understand it), and cognitive surrender (accepting whatever the loop returns because checking is tiring). An unattended loop is also a loop that makes mistakes unattended. This connects directly to two threads we've tracked — token economics (Issue #14's "Token-Price Reckoning") and the "AI augments, humans sign off" principle for any consequential work.

What this means for you

You're probably not writing while-loops around a coding agent. But the role shift underneath the term reaches every knowledge worker, and there are three concrete moves. First, think in cycles with checks, not one-shot outputs. Even when you're still the one prompting, design the verification step on purpose: what would tell me this is wrong? Second, treat the stop rule as the deliverable. Before you automate anything, write down what "done" looks like and what would make you pull the agent out. If you can't state the stop condition, the task isn't ready to loop. Third, keep yourself in the review path as you take yourself out of the prompt path. The leverage of a loop is that it runs without you. The risk is identical. Decide in advance which decisions still need a human signature.

The skill is no longer asking once, and it was never really asking perfectly. It is deciding what gets checked, what gets to run on its own, and who is still watching when it does.