Loops Moved the Work Up a Level. The Risk Moved Down One.

Two of the people building coding agents have been saying the same thing in different words. Boris Cherny, who leads Claude Code, put it plainly. He does not prompt the model anymore. He writes loops that do. Peter Steinberger said it as a directive: stop prompting agents, start designing the loops that prompt them. Addy Osmani wrote the long version of it last week, and a hundred and fifty engineers argued it out underneath.

The shape is settled enough to name. The unit of work moved up a level. You stop holding the tool turn by turn and start designing a system that runs the agent. A trigger. Isolated worktrees. Skills written down once. Connectors to the systems it acts on. A checker agent. A memory file the next run can return to.

The conversation about the risks has been good. Token cost. Comprehension debt, the widening gap between what the loop shipped and what anyone still understands. Verification that cannot rest on a model grading its own output. The sharper version of the caution is converging on one idea. Anchor the check outside the model, on a deterministic test or a human at the merge, and gate the moves that should not run alone.

That instinct is correct. It also stops one step short of the problem a regulated enterprise has.

The connector is the part that changes

The bullet that matters in every version of this is connectors. A loop wired into your systems does not tell you what it would do. It opens the pull request. It updates the ticket. It moves the work forward on its own.

In a code repository that is fine, because the actions reverse. A bad pull request reverts. A wrong ticket gets reopened. The cost of a mistake is bounded by how fast you notice it.

Move the same loop into a bank, an insurer, or a hospital, and the connectors reach systems where the action does not reverse. A payment leaves. A record gets deleted. An entitlement gets granted. The verification burden everyone agrees stays on the human gets heavier in the exact place it matters, because some of those actions finish before anyone reads the run.

What the loop sends is its own exposure

There is a second change the developer framing does not cover, and it is the one that decides whether a regulated enterprise can run any of this.

It is not only which action the loop took. It is what the agent put in the prompt on the way to the model.

An agent working a task pulls context to reason about it. A customer record. A claim file. A patient chart. A trading position. It places that context in a prompt and sends the prompt to a model. If the model sits at a public endpoint, the regulated data has left the building. That is a disclosure on its own terms, whether or not the action that followed was correct, whether or not anyone ever notices.

A checker sub-agent does not see this. It was built to grade the diff, to ask whether the output is right. The record that went out in the prompt is not a logic error in the output. It is a policy event in the call. Trace-logging does not see it either. Trace-logging records that the workflow ran, not what crossed the boundary while it ran.

This is the line between two questions that are easy to blur. One is whether the right workflow executed. That matters, and iteration caps and human gates and the checker agent are the right tools for it. The other is what the agent sent to the model, what came back, and whether any of it can be proven later. The first is the workflow plane. The second is the runtime plane. The developer thread is almost entirely about the first.

The control has to sit at the call

If the exposure happens at the moment the agent sends the prompt, that is the only place to govern it.

Not in the review after the run, when the data has already left. Not in a policy document, which is not evidence. Not in a model asked to behave, because a model under prompt injection is the thing you are containing, not the thing you trust to do the containing.

The control has to sit inline, in the call path between the agent and the model, reading every prompt, every response, and every tool call before it goes through. Inspect the prompt and redact or block the regulated record before it reaches a public endpoint. Score the tool call and stop the destructive one before it runs. Hold the out-of-band action and require a verified human when policy says so. Write all of it to an identity-bound record, so an examiner's question is answered from a query instead of a reconstruction.

That position, in the path, at the moment of the action, is the one the workflow plane does not occupy. Tools that spawn agents and scope their authority govern which agent runs and on whose say-so. That work is necessary. It sits above the call between the agent and the model. It does not read what crosses it.

Loops are right. Extend the discipline.

None of this argues against loops. The paradigm holds. Scaling intent across a codebase, automating the tedious work of verifying and iterating, moving the human up to the goal and the invariants, all of it holds.

The discipline the thread is converging on holds too. Anchor verification outside the model. Gate the actions that should not run alone. The part a regulated enterprise adds is that the gate is not only about whether the action was right. It is about what the loop sent on the way there, and the actions it can take are the ones a regulator examines.

Build the loop like someone who intends to stay the engineer. In a regulated setting, build it like someone who will also have to prove, six months from now, what it sent and what it did.

APERION builds SmartFlow, the on-premises runtime governance control plane for regulated enterprises deploying AI agents, with inline policy at every prompt, response, and MCP tool call, and Shield, its open-source MCP middleware. Related reading: Addy Osmani's write-up on loop engineering and the software factory.