Human-in-the-Loop Review Gates in AI Migration Agents

Human-in-the-loop review gates are the mechanism migration teams rely on to keep AI agents from doing irreversible damage, but the mechanism only works if the gates sit in the right place. Putting a gate in the wrong spot produces one of two failures in a team, a rubber-stamp loop that creates the appearance of oversight without the substance, or so much friction that engineers route around the gate; what decides whether human review means anything in an AI migration agent is not whether a gate exists, but where it sits.

Why migration agents create a different category of risk

A human stayed squarely in the execution path with earlier AI coding assistance. A developer would paste a block of XAML into a chat window, accept the rewrite the model proposed, run the build, and fix whatever broke before any of it reached production. The human was the last line of defense by construction, not by design, because nothing happened without that person physically running the next step.

Migration agents remove that structural safeguard. Review that happens after an action has executed can document the damage, but it cannot prevent it. The only point where human oversight retains any power over an irreversible action is before that action runs, not after. That constraint sets the terms for everything else in this piece: gates have to be positioned upstream of execution, and figuring out exactly where upstream is becomes the entire engineering problem.

How approval fatigue and bypass behavior develop

The first failure mode is the agent acting faster than review can catch it; the second is the human reviewer quietly stopping being a reviewer. The author approved every single one of those 16 requests without pausing to ask why a folder copy had generated a process that looked like a database migration.

The defect that actually mattered slipped through all 16 checkpoints. The author's own description of the experience is the clearest diagnosis available of this failure mode: "I was in the loop the whole time. I just wasn't reviewing the loop." If you get asked to approve something every four minutes, you don't produce 16 independent judgments. It produces one habituated reflex, repeated 16 times. Each request looked reasonable on its own, and that is exactly when a human stops evaluating and starts rubber-stamping.

This is not just an efficiency problem, because approval fatigue is an attack surface with a name and a date. An open threat-detection ruleset added an entry in March 2026 specifically titled "Human Approval Fatigue Exploitation." Poor gate placement doesn't just dilute oversight.

Gate placement: irreversibility and blast radius

Both failure modes, the agent that outruns review and the human who stops reviewing, trace back to the same root error: gates placed according to where a step falls in a process, rather than according to what that step could actually do if it goes wrong. Victoria Westerhoff, Principal Director of AI Red Team Operations at Microsoft, states the correct criterion directly: "Knowing where really big decisions are in the process and the tech stack should be the guiding principle of where you're mandating human review." That is a statement about irreversibility and blast radius, not about sequence. A step late in a migration plan might be trivially reversible; a step early in the plan might not be.

CRM migration practice encodes this principle architecturally rather than leaving it to policy alone: no single agent should both propose and execute an irreversible write. Least privilege applies to agent credentials exactly as it does to human ones in cloud infrastructure practice around identity. If an agent cannot hold admin keys, it cannot act irreversibly on those credentials, whether or not a review gate ever fires. That's a second line of defense, and it doesn't depend on a human paying attention at the right moment.

The practitioner account from the previous section supplies the negative proof of this principle. Gate density and gate type should be set by irreversibility and blast radius, the two variables that matter. Everything from here forward is about how to operationalize that judgment across the technical layers of a real migration agent.

The three-layer migration architecture that makes selective gating possible

The irreversibility-and-blast-radius principle only becomes workable once an agent can verify its own output against a running system, because verification is what frees the human reviewer from having to catch every possible error. You can see what that looks like in Uno Platform's three-layer pattern for AI-assisted WPF migration.

The first layer is a documentation MCP server, and its job is preventing confabulation. Without grounded access to current API documentation, an agent will generate plausible-looking XAML that doesn't actually compile against the current API surface, or it will invent control properties that no longer exist in the framework. The second layer is a runtime MCP, Uno's App MCP, which lets the agent walk the visual tree of the running application, read effective property values, capture screenshots, drive input, and assert post-action state.

The third layer is human review, and what's notable is how narrow its remaining scope becomes once the first two layers are doing their jobs. The human owns architectural intent, decisions like which screens get rewritten versus wrapped, or which singletons become dependency-injected services. The concrete loop makes this tangible: an agent generates SettingsPage.xaml, runs the build, deploys it under App MCP, walks the visual tree, and finds that a CheckBox bound to ViewModel.UseDarkMode has regressed from a TwoWay binding to OneTime. The agent patches the XAML itself, re-runs the build and verification, and only then does a human review the diff in the pull request, confirm intent, and merge. The gate fires once, and it fires at the point where human judgment is actually required. The broader lesson holds regardless of toolchain: the more an agent can verify of its own output, the more precisely a team can target the handful of decisions where a human gate adds real value.

Gate granularity options and what each catches

Once a team accepts that gates should sit selectively rather than uniformly, it has to ask which gate type fits which situation. This is a configurable design space, not a binary choice between approving everything and approving nothing.

Claude Code's permission system illustrates the range well. From version 2.1.283 onward, auto mode became the tool's built-in default, but you get six distinct modes to choose from. Bypass Permissions mode lets nearly everything run, and the documentation is explicit that it should be used only inside an isolated container or virtual machine.

A deny/ask/allow rule structure sits below these modes, encoded in a project's.claude/settings.json as three separate lists. Deny rules apply in every mode and are checked first, ask rules name specific tools or commands that always pause regardless of mode, and allow rules permit named actions to run without any prompt. This layering means a team doesn't have to choose one mode for an entire migration; it can pin down exceptions at the rule level.

The two are complementary checks operating on different questions.

What the Singapore Consensus and governance frameworks require

Regulatory and standards bodies have converged on the same direction as the technical architecture described above, calling for calibrated intervention at defined decision points. What they have not done is specify where those points belong, which leaves placement as a team-level engineering decision with real regulatory consequences attached to it.

The EU AI Act's Article 14 addresses automation bias directly: it requires that human overseers not over-rely on AI output, as a matter of risk management. The agentic workflow governance framework from Digital Applied shows how enterprise procurement checklists have begun encoding gate requirements as explicit controls: role-based access control scoped to the individual agent, audit trails covering every agent action and tool call, multi-level approval gates reserved for high-stakes decisions, and sandbox environments for testing agents before they ever touch production. The Human-on-the-Loop governance framework takes a related approach, assigning every AI-driven process a Control Tier designed to guard against the two opposite failure modes of the agentic era: human bottlenecks choking low-risk tasks, and runaway autonomy going unchecked on high-risk ones. That tiering is a direct architectural encoding of the irreversibility-and-blast-radius principle discussed earlier.

What none of these regimes do is specify the granularity at which gates must actually fire. Demonstrable oversight is a documentation requirement these frameworks enforce. Effective oversight is an engineering outcome they leave entirely to the team building the system.

The strongest objection: whether human review at scale can be genuine oversight at all

A gate that is well-placed still assumes that the human on the other side of it is capable of exercising real judgment at the volume an enterprise migration will demand. At the scale organizations are approaching, with agents running continuously across many repositories and many classes of action, that assumption strains. Multiplying that volume across an enterprise migration portfolio produces the same collapse even in gates that were positioned correctly on paper.

Adding more gates or more reviewers does not resolve this, because both responses recreate approval fatigue at a different scale. Where any one of those three conditions fails, the gate still fires, a record still gets produced, and the audit trail still looks complete. What's missing is a human actually exercising judgment, which is the exact gap the regulatory frameworks require teams to close and decline to specify how to close. Taking this objection seriously means accepting that most organizations currently running agent-driven migrations have more gates than they have genuine reviewer capacity to support.

A practical placement framework: how to assign gate type to action type in a migration agent

The way to answer the objection above, rather than wish it away, is to make gate placement a deliberate mapping exercise rather than a default setting left over from however the tooling shipped. The Digital Applied governance framework and the Digital Apprentice framework for human-directed agentic AI development both converge on this same structural move: assign a control tier or gate type to a class of action, not to a stage in the process. An action earns its gate type by what it is capable of doing, not by when in the migration it happens to occur.

High-irreversibility, large-blast-radius actions, schema migrations, credential operations, production data writes, cross-system API calls with effects outside the migrating system, warrant a blocking gate with expert human review, enforced so that no single agent both proposes and executes the change, with a mandatory audit trail. Actions with high irreversibility but a bounded blast radius, like deleting a file within the scope of a single project or pinning a dependency version, still warrant a blocking gate, but an automated test gate can run first, leaving the human to evaluate only what's left before a plan-level approval is given. Actions with low irreversibility but a large blast radius, reading across a large dataset or pulling a configuration with wide visibility into the system, fit an advisory gate: the action is logged and surfaced for batch review rather than blocked in real time, since blocking execution for something this cheap to undo would only multiply reviewer fatigue. Actions with low irreversibility and a bounded blast radius, file edits within project scope, read-only queries, in-memory operations, need nothing more than an automated quality gate; routing these through a human reviewer is exactly the kind of misapplied governance machinery the folder-copy account illustrates.

None of this works if the reviewer assigned to a gate lacks the expertise to evaluate the action independently. A gate placed on a database schema change needs a reviewer who can assess that migration on its own merits; placing the gate correctly but staffing it with someone who cannot validate the action produces the accountability theater that Forrester's Jess Burn has pointed to as the real failure hiding behind a technically compliant process. The framework for supervising AI coding agents and the three-pillar model built around transparency, accountability, and trustworthiness both treat this structured role assignment as a design responsibility from the outset, not as a fallback added after an incident. Mature procurement guidance, including Dataiku's enterprise agentic AI guidance, reinforces the same point from the infrastructure side: role-based access control scoped to the individual agent bounds the credential blast radius before any gate even has occasion to fire, and sandbox environments let a team validate its gate calibration against realistic scenarios before the agent ever touches production.

None of the gate assignments above are permanent. Related governance work points toward a principle of earned autonomy, where an agent that has built a track record of reliable behavior on a given class of action can see its gate type relaxed over time, moving from a blocking gate toward an advisory one as evidence accumulates. Gate placement is calibration work that continues for as long as the agent keeps operating, adjusted as a team sets it, revisits it, and adjusts it as the evidence about what the agent can be trusted to do on its own continues to come in.