Human in the loop framework: design the boundary, not just the approval

Key takeaways

• Give each human role clear authority over a defined decision.
• Require approval for consequential actions; sample some low-risk actions for monitoring.
• Hold the exact request in durable state, expire stale decisions, and record the outcome.

A human in the loop framework is an authority system around an agent action. The visible approval button is only one part. The harness must decide who can act, what they see, which request is held, when their decision expires, and how execution can resume safely.

What is a human in the loop framework?

Human-in-the-loop means that a person has a defined role in an AI system's decision or execution path. Those roles and responsibilities need to be clearly defined and differentiated. A loose instruction to "get human approval" leaves the most important part unresolved: which person has authority over which consequence?

The configuration can sit anywhere from fully autonomous to fully manual. Three common modes make that range concrete:

1. Autonomous decision: the AI system makes the decision.
2. Human deferral: the AI system sends the decision to a human expert.
3. AI advice: the AI system gives an additional opinion to a human decision-maker.

The human does not play the same role in all three. In one mode, the system has decision authority. In another, a person has it. In the third, the person decides with another input available. That is why the authority assignment belongs in the architecture, not in interface copy.

That distinction answers what human-in-the-loop means when using AI. Human participation does not describe one fixed arrangement. The person may receive a deferred decision or make a decision with AI advice, while another configuration may leave the decision with the AI system. The useful design question is therefore specific: who decides in this mode, and what responsibility does that role carry?

Clear role names are not enough on their own. Two people can both be called reviewers while holding different decision authority. Define the responsibility beside the role so the runtime request reaches a person who can make the decision being deferred. This keeps the human step tied to authority instead of mere visibility.

At runtime, a human-in-the-loop workflow can send a request to an operator and wait for a response before execution continues. The request-and-wait pattern explains how human-in-the-loop works, but it still does not define what the response authorizes. The system needs an explicit contract around that pause.

For a compact definition of the concept, see our human-in-the-loop glossary entry. The engineering question is deeper: what must remain true between the moment an action is proposed and the moment it takes effect?

Design the boundary before you build the gate

As agents gain permission to access datasets and other systems, permission-based controls become important. We use the Boundary Design Canvas to specify the intervention before implementation begins. It is an eight-field design aid, not a claim that one pattern fits every system.

Historical approval is not current execution authority. The expiry rule prevents an old decision from remaining open-ended permission, while the durable-state and replay fields preserve the held work without treating an earlier approval as permanently valid.

If you are formalizing that boundary in code, our approval gate definition gives the gate itself a precise place in the harness.

Which actions need human approval?

Require approval when the next action is irreversible, costly, regulated, or capable of a high blast radius. Sensitive customer commitments, account-state changes, money movement, and other irreversible actions should remain human decisions even when AI supplies the evidence and proposes the action.

The same rule applies when an AI-assisted decision can materially affect a person's rights, access, or opportunities. Human review in that setting supports explanation, error correction, and accountable decision authority. The reviewer is not a decorative stop in the workflow. The reviewer holds authority over the consequential decision.

Low-risk work can use a different pattern. One sampled-approval design reviews every high-risk action while sampling 5 to 20 percent of low-risk actions to monitor drift and identify issues. That range is an example pattern, not a universal benchmark. The sampling rate still needs to fit the workload and its context.

An at-a-glance rule is useful during design:

• Full approval: the action is irreversible, costly, regulated, or high in blast radius.
• Human decision authority: the action makes a sensitive customer commitment, changes account state, moves money, or materially affects rights, access, or opportunities.
• Sampled approval: the action is low risk, and a 5 to 20 percent sample is being used to monitor drift and surface issues.

The two approval patterns serve different decisions. Full approval governs whether a consequential action may proceed. Sampled approval observes a portion of low-risk actions for drift and issues. Sampling does not replace full approval for an action that meets one of the four consequence triggers in this pattern.

Context remains part of the decision. Trustworthiness characteristics must be balanced for the system's context of use, and human judgment should set the particular metrics and thresholds. A low-risk label does not select its own monitoring rate. A person still decides what the system will measure and which threshold changes its execution path.

This creates two policy choices before any gate is built. First, classify the action by consequence: irreversibility, cost, regulation, and blast radius. Then use human judgment to set the metrics and threshold values for the trustworthiness characteristics relevant to that context. The first choice places the action on an approval path. The second defines how that path is measured and monitored.

This division keeps human attention concentrated at consequential boundaries while preserving a monitoring path for routine work. Once that policy exists, the harness has to enforce it at execution time.

How does the decision become an enforced workflow?

An approval becomes real when the execution path checks it before the tool call. One current platform example separates the responsibility for deciding whether approval is required from the responsibility for moving the request and response. In the Microsoft Agent Framework and AG-UI integration, the framework decides whether a tool needs approval. AG-UI transports the request to the client and returns the client's decision.

Transport is only part of enforcement. A deterministic gate can check the decision state and persisted approval, then verify approver status, role continuity, approval freshness, policy-version continuity, and delegation conditions. These checks turn a past response into a current authorization decision at the point of execution.

The transport layer carries a request and a decision. The deterministic gate checks the stored decision against the execution conditions, including approval freshness and role continuity.

The held work also needs explicit states. One checkpoint decision model distinguishes pending, approved, rejected, resolved, and expired. Expired means that the timeout passed without a decision. These states let the runtime distinguish a request that is still waiting from one that may proceed, one that must stop, and one that is no longer current.

Persisting those states gives the gate a durable decision to inspect after a pause or restart. It can test the stored state alongside the current approver, policy, freshness, and delegation conditions. That is a stronger execution contract than accepting a client response and immediately forwarding the tool call.

Recovery belongs in the same path. A checkpoint-aware runtime can restart a failed node without rerunning completed steps. That behavior matters because a process failure after a human decision should not force the whole trajectory to begin again or silently repeat finished work.

Frameworks expose these mechanics differently. Our LangGraph human-in-the-loop implementation guide shows how this boundary maps into one specific framework.

A worked outbound-email approval boundary

Outbound email is a useful human-in-the-loop AI example because the intervention point is exact. Approval must intercept execution before the email API call. Once the SMTP transaction completes, the side effect is irreversible. A review that happens after that call can record an opinion, but it cannot authorize the already completed send.

Here is the full pre-send trace:

1. Intercept the send. The agent prepares the proposed email, but the harness holds the action before the email API call. The approval request refers to that exact outbound action.
2. Persist the context. Store the agent context durably so the pause-and-resume path survives a process restart. The reviewer should not depend on the original worker process remaining alive.
3. Present the decision. For an interface designed around a 30-second decision, show the rendered HTML preview, full recipient address, agent-context panel, and deadline countdown. The reviewer sees the proposed effect and the context attached to it.
4. Make both edges idempotent. Enforce idempotency on the approval callback and on the email send call. Duplicate callbacks and repeated execution attempts then reach controls at both places where repetition could enter the path.
5. Apply the action's timeout. Define the approval timeout by email action type. One global timeout does not govern every email action.

The trace exposes why an approval prompt alone is too small a design. The prompt can display a choice, but the surrounding harness holds the request, persists the context, controls duplicate execution, and applies the relevant expiry policy.

The timeout is part of authority, not just interface behavior. When the deadline passes without a decision, the checkpoint can become expired. Execution then evaluates a current state instead of treating an old request as an open-ended permission.

The 30-second interface target also creates a concrete context requirement. The review surface includes the rendered message, the complete destination address, the agent's context, and the remaining decision time. Those four elements belong to the interface designed for that quick decision. A different email action can carry a different timeout policy.

Double idempotency is equally deliberate. The approval callback and the send call are separate entry points. Each gets its own idempotency control because the supported email pattern requires both. The result is a pre-send boundary that remains legible across a reviewer response, a retry, and a process restart.

Test the paths that break approval systems

The happy path proves very little about a consequential boundary. Test the same outbound-email action under normal, expired, reassigned, duplicate, outage, and emergency-stop conditions.

• Normal: confirm that an approved request reaches the send path once.
• Expired: confirm that a timed-out request moves to expired instead of carrying old authority forward.
• Reassigned: recheck the approver's current status and role continuity before execution.
• Duplicate: repeat the callback and send attempt to exercise both idempotency controls.
• Outage: restart the process and resume from the durable agent context.
• Emergency stop: exercise the approval path under its defined emergency-stop condition.

These tests apply pressure to authority, state, and execution separately. A working button does not establish that the system behaves correctly when the reviewer changes, a deadline passes, or a worker disappears.

Run the six scenarios against one held request so the observation stays concrete. The expired and reassigned cases exercise current authority. The duplicate case reaches the callback and send controls. The outage case exercises persisted context and checkpoint-aware restart without rerunning completed steps. The emergency-stop case exercises the path defined for that condition.

Human review does not end operational oversight

Human approval is one control inside an operating system. Monitoring agentic AI should be treated as a permanent operational expense, not a one-time project cost. The boundary will keep producing events, decisions, tool calls, outputs, retries, and outcomes that need to remain observable.

The right control mix depends on context. In financial-services AI risk mitigation, there is no one-size-fits-all approach. Candidate practices include oversight, monitoring, explainability, and interpretability. That list does not establish one universal configuration. It identifies practices that can be selected for the risk being managed.

Permanent monitoring changes the cost model of the system. It belongs in ongoing operations instead of a one-time launch checklist. Oversight can place a person in a decision path, while monitoring continues after individual decisions. Explainability and interpretability are additional candidate practices in the financial-services context, not automatic products of an approval step.

This is why we treat the execution trajectory as the useful object of review. The final output alone leaves out the approval state, the authority check, the tool call, and the recovery path. A replayable record makes those parts available for ongoing monitoring and investigation.

Use the Boundary Design Canvas on one consequential action in your system. Fill all eight rows, then test the resulting hold under expiry, reassignment, duplication, outage, and emergency stop. To place that intervention boundary inside the wider execution path, examine our agent loop architecture.