What loop engineering needs before it runs in a regulated estate

A loop can write the code. It cannot grant itself permission.

Something real happened this year, and the people who noticed it are right. The way you got work out of a coding agent used to be a prompt. You wrote a good one, you read what came back, you wrote the next one. That is ending. The leverage has moved into the loop: a small system that finds the work, hands it to an agent, checks the result, records what is done, and decides what to do next. You design the loop once and it runs while you sleep. Peter Steinberger put it as designing the loops that prompt your agents rather than prompting them yourself. Boris Cherny, who leads Claude Code, says he writes loops now, and the loops are what prompt the model. For greenfield work, and for a single engineer with taste, this is a genuine change in what one person can ship.

The harness is not the system #

Then comes the misread. The conversation has started to treat the loop as the system. It is the harness. In a regulated estate the loop sits one floor below the question that decides whether you can use it at all. That question was never whether the loop can run unattended. The bench has run unattended for a while now. The question is what the loop is permitted to do unattended, and who answers for the change when nobody was watching.

That second question moves the decision to a different desk. Whether an agent can produce correct changes unattended is a quality question, and it belongs to the people who build the loop and its tests. Whether those changes are allowed to land unattended is a different question, and in a regulated firm it belongs to whoever owns the estate the changes land in. Loop engineering is the factory floor. The thing worth your attention is the wall the floor runs against, and who is standing at it.

Correctness is not authority #

The loop’s safety story rests on one move: split the agent that writes from the agent that checks. The maker proposes, a second agent with different instructions verifies, and because the checker is not grading its own homework you are told the “done” can be trusted. Run until the tests pass, and let a separate model decide when passing is true. This is worth having. It is also answering the wrong question. A verifier answers whether the code is correct, against the spec, the tests, the types. That is a real question and the checker is the right organ for it. Correctness is not authority. The question governance asks is a different one, and no checker touches it: was this change permitted to happen without a human?

Those two come apart cleanly. A loop can hold a flawless checker, produce code that is correct in every mechanical sense, and still breach governance, because the change it made was one it had no standing to make unattended. Correct work, made outside the bounds it was allowed to act within. The checker has nothing to say about that, because it was only ever looking at the code. There is a second organ. Call it the Gate. The Gate is the control point on the path from intent to landed change. It does not ask whether the work is right. It asks whether the change was allowed to land on its own. The verifier guards correctness. The Gate guards authority.

The same gate, moved to commit time #

None of this is new governance. A regulated firm already separates the people who validate a model or a change from the people who approve it. That separation is written into model-risk supervision and into change-authorisation rules, and the names differ by jurisdiction. A bank under the European regime answers to one stack, a UK firm to its own, and they are not the same regulator with the same words. What an autonomous loop forces is not a new control. It is the same approval gate, moved from a human signing off at runtime to a gate applied at commit time. The novelty is the timing. The obligation was already yours.

Two acts of bounding, and the petitioner #

Here most engineers I talk to have the same reflex, and it is a good one. If a change is bound by the right invariants, why does a human need to be in the loop at all? Bind it properly and let the agent proceed. The instinct is correct. It only hides where the accountability went. There are two acts of bounding, and we tend to collapse them into one. The first is bounding the envelope: authoring the invariants, the constraints, the limits on autonomy for a whole class of change. This is exploration, the judgement-led work this series has spent the year describing, where ambiguity is still allowed and alternatives are still in play, and a person with standing decides what a class of changes may do. You do it once per class. The second is bounding the individual change: checking this one change against that envelope. This is industrialisation, deterministic and repeated, where inference is no longer permitted and the only question is whether this instance falls inside what was already decided. There is no reason a person has to be the one doing the second. An agent checking a change against an envelope a human already drew is industrialisation, and that is exactly where a machine belongs.

Read that way, an autonomous loop is a petitioner, not an officer. It can file a change and ask for it to land. It cannot hold the role that answers for the class of change, because that role, under the rules already in force, has to be a named person and not a process. The loop acts under a standing mandate that a human granted, and it carries no judgement of its own while it runs. The loop did not remove the human. It moved her into exploration and left industrialisation to the machine. The work that carries the weight is no longer reviewing changes one at a time, it is bounding the class they belong to, and that is a different job that most organisations have not staffed.

Does silence mean safe? #

Now the load-bearing part, and it reduces to one question. Does silence mean safe?

“No invariant fired” gets read as “safe to proceed.” Those are not the same statement. Invariant-silence is ambiguous. A change that is genuinely covered, that your invariants range over and find nothing wrong with, is silent. A change in territory your invariants never anticipated, where nothing fires because nothing was ever written to fire, is also silent. The covered-and-fine case and the uncovered-and-unforeseen case produce the identical signal at the invariant layer, which is nothing at all. You cannot tell them apart by listening to the invariants, because the dangerous one is defined by the absence of any invariant that would speak.

Pass, and coverage #

So the licence for autonomous action cannot be invariant-pass on its own. It has to be two things at once: the invariants hold, and the change sits inside the ground your invariants actually cover. Pass, and coverage. At the edge of that coverage the change does not run. It stops, and it waits for a person. An uncovered change is the Gate pushing that change back out of industrialisation and into exploration, because it needs judgement again, and judgement is the one thing industrialisation does not allow. The wait has to be the behaviour that holds under pressure, which means the queue it waits in is bounded and fails closed. When the queue fills, the loop stops. It does not start waving things through. A governed loop that cannot say a clean no is not governed, it is only fast. The reason the stop has to be hard is the timing. A loop runs unattended at exactly the moment nobody is present to notice the change has wandered past the edge of what anyone anticipated. The autonomy and the blindness arrive together, in the same instant. That is the one place a soft rule cannot be afforded.

This sounds like it caps autonomy forever. It does the opposite, slowly. The edge of coverage is not fixed. Every change the Gate stops is a change someone then resolves, and a resolution is a candidate piece of new coverage. Promote it, and the covered ground grows, and the next time that class of change arrives it passes on its own. Promotion is exploration handing industrialisation a larger envelope to run inside. The wall stays hard. Its position moves outward. What looks like the loop being trusted more over time is really the covered ground expanding underneath it, which is a different thing and a safer one. One discipline holds the whole structure up. The loop may surface candidate coverage. It may not promote its own. A loop that promotes the changes it stopped into its own widened envelope is a loop expanding its own mandate, which is the single move that turns bounded autonomy back into the unbounded kind. The human stays on the promotion. The loop generates the evidence. Someone with standing moves it across the line. That promotion is not done once and forgotten. It is a standing duty at a human cadence, and the rate at which the queue fills is the signal that tells you whether your ground is declared well enough to let the loop run at all. A queue filling faster than people can clear it is not a staffing problem. It is the estate telling you it is not ready.

The classifier you have not built yet #

One piece of this is a bet, not a built thing. What decides “inside coverage” against “at the edge” is a classifier, and that classifier does not exist yet. Today the judgement is manual, made by the architect who owns the slice. That is the honest interim, and it is the named next thing to build. The moment you automate that judgement you have built a control that the same regulations will hold to a standard of accuracy and robustness, and a coverage call you cannot stand behind is a gate you cannot stand behind.

Even unbuilt, you can say what that classifier has to do, and it lands in territory every architect already knows. Coverage runs on two axes. One is the elements a change touches, and how much has been built and verified against each of them. Deep, well-attested elements are covered. Reach into something nothing has ever been attested against and you are at the edge. The other axis is the wiring: does the change create an interaction that nothing ranges over? This is the axis that catches what element-level checks miss, and it is the oldest finding in architecture review. Two components, each one individually fine, combine into something toxic. The nodes are healthy. The edge between them is the problem.

The move that makes this tractable is to stop trying to detect that a combination is bad and detect only that it is new. Judging whether a novel combination is toxic is the architect’s work and does not mechanise. Detecting that a combination is novel, an interaction the system holds no attestation over, is cheap, and it is conservative. You already run a version of it. A regulated shop keeps a software bill of materials, checks every dependency against an allow-list, and flags the dependency combinations it knows are poison. That is edge governance over one kind of edge. The same discipline generalises from dependency edges to every edge, the calls, the data flows, the control paths. The classifier flags the novel wiring and routes it to a person. The person judges toxicity. That division of labour is the honest one.

The mediator: the wall you cannot see #

And then there is the part that does not yield. It is the part the ship-while-you-sleep story never mentions. Not every toxic combination is a new edge. Two services, each sitting comfortably inside its own limits, can together exhaust something neither of them owns. A shared thread pool. A connection ceiling. A rate limiter. In a regulated firm, an aggregate exposure across positions that are each individually within bounds, which is not a metaphor but a hard external ceiling the firm answers for. The coupling runs along no edge in your diagram. It runs through a resource that is not in the diagram at all. Call it the mediator. While it stays unmodelled, no coverage check can see the collision, because the thing they collide on is represented nowhere. The cure is the obvious one. Promote the mediator to a first-class element, give it a stated capacity, and the collision becomes visible: two services with edges into one shared node, joint demand against a limit, checkable. The floor underneath that, the part that does not automate, is that you cannot promote a mediator you have not yet thought of. The shared resource nobody modelled because nobody expected the contention is exactly what a good architect is for, and exactly what a postmortem discovers.

There are two different walls here, and they fail in opposite ways. One is the wall the loop hits at the edge of declared coverage. It is loud. Every time the loop stops there you get a logged event, and over time the wall moves outward as you promote what you have learned. The other is the shared resource you never modelled. It is silent. It does not announce itself, because nothing in your diagram represents the thing being contended for. The first wall you can audit. The second you cannot, and the real danger is using the first to convince yourself the second is handled. Declaring more of your estate shrinks the silent wall and pushes it back. It does not remove it.

One change-class, one slice #

Which is why none of this is something you do to your estate. You do it to one change-class on one slice of it. Take a single regulated limit, an aggregate exposure for instance, and the handful of services that touch it. Declare that slice and only that slice. Inside it, where every inbound edge is either declared or denied, the loop’s silence can be trusted, because you have made silence mean something. Outside it, the loop has no standing to act, and the change routes to the human path it always used. This is the line that decides whether the whole thing helps or harms: a loop on a half-declared estate that behaves as though the whole estate is governed is worse than no loop, because it manufactures an assurance that is not there. The governed claim is scoped to the slice, or it is false.

Two things keep that slice honest rather than comforting. The declaration has to be an enumerated inventory that someone signs, not a list of the edges that happened to fire while you were watching. An edge that exists but has not run yet is not a covered edge, it is an undiscovered one, and the first time it fires the loop will correctly stop. When it stops, what the operator sees has to read as what it is, an undeclared edge, and not as an outage, or the response under pressure will be to widen the gate rather than declare the edge. The gate that can be widened during an incident was never a gate.

The question worth carrying #

Which gives you the question worth carrying, and it is not whether the loop is good enough. It is whether your estate is declared enough that the loop’s silence means covered and fine, rather than unseen. That is a property of the estate, not of the agent, and no improvement in the model repairs it, because where your coupling is undeclared there is nothing for the model to read. It moves the go-live decision off the desk of the person who built the checker and onto the desk of the person who owns the estate, because go-live is an exploration decision about a class of change and not an industrialisation step. And it changes the artefact that gates a release from a better test suite into a declared map of what depends on what.

A loop can run the bench unattended. Whether it can run the floor depends on a wall you have to draw, a coverage you have to grow yourself one shared resource at a time, and an honest account of the one you have not found yet. The smallest true version of that is one change-class on one slice, declared down to the last inbound edge, with the part you still cannot model named out loud rather than left silent. Declaration shrinks that silent part. It never closes it, and naming the part you cannot close is itself the control.

Sources: Peter Steinberger, on designing loops that prompt your agents (https://x.com/steipete/status/2063697162748260627); Boris Cherny, on writing loops that prompt Claude, Acquired and WorkOS talk (https://www.youtube.com/watch?v=RkQQ7WEor7w).