The debate about AI in software delivery has mostly settled on a truce: keep a human in the loop. It sounds safe, and it is the right instinct. But it hides the question that actually matters, which is not whether a human should be involved but where. Put a human at every step and you have not built oversight, you have built a queue of dialogs that a tired engineer clears without reading. Put a human at no step and you have handed production to something that does not feel the weight of a bad decision. The real work is drawing the line, and drawing it in the right place.
That question is also getting sharper for legal reasons. The EU AI Act's Article 14 requires that high-risk AI systems be designed so a person can meaningfully oversee them, and its obligations become enforceable on August 2, 2026. "A human was technically able to intervene" will not be enough. The oversight has to be real. So it is worth having a principled answer to human oversight of AI decisions, rather than gating by vibes.
Three questions that decide whether a human belongs
For any step an agent might take, ask three things. They are quick, and together they sort almost every decision.
Is it accountable? Some decisions are answerable to someone: a customer, a regulator, a teammate whose code you changed. If the honest answer to "who is responsible if this is wrong" is a named person, that person needs to actually decide, not discover it later. Accountability cannot be delegated to a process that has no skin in the game.
Is it reversible? A decision you can cleanly undo is safer to automate than one you cannot. Reformatting a file is reversible. Deleting data, sending an email to a customer, or removing a public API are not, or not without cost. The less reversible the action, the stronger the case for a human before it happens rather than a cleanup after.
How big is the blast radius? A change contained to one module is different from one that touches a public contract, a migration, or a shared service. The wider the reach, the more a human should look before it lands. If you are unsure of the reach, that uncertainty is itself a reason to gate.
A decision that is accountable, hard to reverse, and wide-reaching is one you gate without hesitation. A decision that is none of those is one you can let the agent handle and move on. Most steps fall clearly on one side. The interesting ones sit in the middle, and that is where the next section helps.
Walking the delivery lifecycle
Map the three questions onto how work actually flows from intent to production, and a clear pattern falls out.
What to build. Deciding scope, priorities, and trade-offs is accountable by definition: it is a product decision someone owns. An agent can draft a plan, surface options, and flag conflicts. It should not get to decide what ships. Gate this.
Gathering context, drafting, running tests. These are the high-volume, low-stakes steps. Reading the codebase, proposing an implementation, running the test suite, generating a diff: all reversible, all contained, all cheap to redo. This is exactly the work you want an agent doing at speed, without a human in the path. Automate this.
Code entering the product. A merge is where an agent's output becomes something your users and your teammates depend on. It is accountable (someone owns that code now), often hard to fully reverse once other work builds on it, and its blast radius is whatever the change touches. Gate this. A human who can see the diff, the impact, and the test results should approve it.
Going to production. Deploy is the least reversible, highest-blast-radius decision in the whole flow. Accepting production risk is not something you delegate to an agent, no matter how good it is. Gate this, always.
Everything after, in monitoring. Detecting a problem is automatable. Deciding to roll back, page someone, or accept the risk is a judgment call. Gate the decision, automate the detection that feeds it.
The shape that emerges is not "humans everywhere" or "humans nowhere." It is humans at the accountable hinges (what to build, what merges, what deploys) and agents on the reversible, contained work in between. That is where autonomous work and unsupervised work part ways, and it is the concrete version of what a human approval should actually mean.
Match the intensity of oversight to the risk
Gating is not binary. A tiny, well-tested change to a low-risk area does not need the same scrutiny as a schema migration on the billing service, even though both are technically "code entering the product." Tuning the intensity of review to the risk of the change keeps the important gates meaningful, because reviewers are not worn down by rubber-stamping trivia. That routing deserves its own treatment, which is why confidence-based oversight is a topic of its own. The principle here is just this: a gate that fires on everything equally teaches people to ignore it.
The honest limitation
This framework reduces bad calls. It does not remove judgment, and it has failure modes worth naming.
The first is granularity. Gate too coarsely and a single approval covers a sprawling change no human can really assess, which is a rubber stamp wearing a badge. Gate too finely and you drown reviewers until they approve on reflex. There is no universal setting; the right granularity depends on your risk tolerance and how much a reviewer can genuinely hold in their head at once.
The second is that a gate is only as good as the human behind it. If the interface makes "approve" the path of least resistance and hides what actually changed, the gate is theater no matter how correctly you placed it. Oversight requires that the person can see what they are deciding, which is a design problem as much as a policy one.
And the third is that reversibility and blast radius are judgments, sometimes wrong ones. A change that looks contained can reach further than expected. That is why gates work alongside tests, staged rollouts, and the ability to roll back, not instead of them.
What you get from the framework is not certainty. It is a defensible, consistent answer to where a human belongs, which beats gating by habit or by fear.
This is the stance we designed into Loopsfinity: the accountable decisions (what gets built, what code merges, what goes to production) stay human, and the reversible work in between runs at the agent's pace. Not because the agent cannot be trusted with anything, but because "a person can meaningfully oversee this" should be true by design, and it is only true if the gates sit where the accountability does. The framework above is the one worth using whatever you build with, and it happens to be the one the coming rules will expect you to have.