Loops You Can't Close

The agentic engineering world has rallied around a pattern it calls the loop. You almost certainly have engineers running them in your business already. The interesting question in a regulated environment is no longer whether to adopt the pattern. It is which shapes of it survive the transfer, and which create silent risk that will surface in the next thematic review. This piece is about telling them apart, and about a redesigned shape that is more powerful in your environment than in the one that produced it.

What a loop actually is

The shorthand the agentic engineering world is using right now is “loops.” It describes a real shift. A year ago, getting value from an AI model meant typing a prompt and reading the response. The skill was prompting. Today, the higher-leverage move is to write a small program that prompts the model on a schedule, reads the output, decides what to do next, and iterates without you. The skill is loop engineering. The unit of work has moved from the keystroke to the prompt to the cron job.

For software engineers this is concrete. A loop reads new issues from a backlog, drafts a fix, runs the tests, and opens a pull request, all without a human at the keyboard. It only stops when the tests pass.

That last sentence is doing all the work. Hold it.

The asymmetry

In an engineer’s loop, “did this succeed” is a function the loop can call. Tests pass or fail. Deploys succeed or error. Types check or they don’t. Verification is mechanical, cheap, and lives inside the loop itself. That is what makes “retry until green” a coherent operating mode. The loop has its own scoreboard, and the scoreboard is honest.

In a regulated business the equivalent question is different. It is “is this defensible to the second line, to the regulator, to the auditor.” That question is human judgement. It takes days or weeks. It sits in an independent function by design. Four-eyes review, separation of duties, change advisory boards, model risk sign-off: these are not bureaucratic ornaments. They are the explicit requirement that the verifier be independent of the actor. A loop that routes around them is not faster. It is non-compliant.

That is the asymmetry. The engineer’s loop closes itself. The regulated loop cannot.

Governed loops

A loop can still be built that works in this environment. The shape of it is framework decides, model executes, firm verifies. Call it a governed loop. It sits inside the broader Governed Velocity posture, which is how we ship in regulated work: fast within guardrails, never without them. The loop has its own structure within that.

Three properties make it durable.

First, the decision layer is encoded policy, not model preference. The loop runs against rules, frameworks, control libraries, regulatory text. When it fires, the rationale is auditable because the rationale is the policy. A system prompt is not a control. A policy is.

Second, the model is the execution layer, not the judgement layer. It reads the evidence, drafts the attestation, populates the working paper, raises the exception. It does not decide whether the control passed. That is not its job.

Third, the verifier is a designated independent function, sitting outside the loop. The loop is architected to hand off cleanly: structured evidence, a defensible audit trail, a single decision for the verifier to make. Closer to a pipeline with a gate than a self-closing loop.

You give up the retry-until-green elegance of the engineer’s pattern. You get something else. A loop that can be defended on a Tuesday morning when a regulator asks how a decision was made.

The inversion

The instinct so far has been to treat regulated environments as the place loops don’t quite work. That has the topology backwards. Regulated operational work is more loop-shaped than the discretionary creative work the original pattern was built for. Not less.

Look at what regulated operations actually consist of. Control testing on a quarterly cadence. Evidence gathering against a fixed framework. KYC re-screening when a trigger fires. Attestation and recertification cycles. Exception triage against a defined policy. Recurring, well-specified, pass or fail. Textbook loop targets, currently done by people clicking through GRC tools at 11pm on the last day of the quarter.

The discretionary “build a feature” work the original loops are being applied to is the harder case, not the easier one. Features are open-ended. Requirements drift. Tests are necessary but not sufficient. A green build is not a useful product.

Compliance work, by contrast, is built around the assumption that the verifier is independent, the policy is fixed, the cadence is known, and the output is auditable. That is almost the spec of a loop. We have been hand-cranking the work that wants to be looped, and trying to loop the work that resists it.

Three shapes to avoid

Three patterns appear most often. Each leaves the verifier out of the design.

A loop that deploys to production without going through CAB. It will work twice and then trip an audit finding that costs more than every cycle of velocity it bought.

A loop that runs control attestations and ticks them off. The second-line function whose job is to independently test those controls now has nothing to test. The control hasn’t been attested. It has been narrated.

A loop that onboards customers without second-line review. Every customer is a regulatory exposure. The exposure does not go away because the loop was confident.

In each case the loop will look like it is working. The breakage is silent and shows up in a thematic review months later. The fix is not to abandon the loop. It is to govern it.

The skill, restated

The mistake is treating loop engineering as a single portable skill. In a regulated environment it is a different skill. It is designing loops that know they cannot close themselves, and architecting the handoff to an independent verifier as a first-class part of the system rather than something bolted on when the second line complains.

The loops you can’t close are the ones that pay you. Build them on purpose.