Human-in-the-loop AI agents pause a workflow when a decision requires authorized human judgment, then continue only after the application validates that decision. A reliable approval workflow binds the reviewer’s choice to an exact proposed action, preserves state while waiting and records what was eventually executed. A chat message saying “approved” is not enough when the target, permissions or business record may have changed.

This guide proposes an architecture for approval, escalation and audit trails using a fictional service-credit request. It includes a state-transition design, a review-screen specification and failure scenarios. The design is illustrative engineering guidance; it does not claim a completed client implementation or substitute for an organization’s financial approval policy.

When should an AI agent request human approval?

Request approval when an operation crosses an agreed authority boundary: sending an external commitment, changing a sensitive record, moving money, granting access or making a judgment that an authorized person must own. Use deterministic policy to define those boundaries. Confidence in a model’s answer is not equivalent to business permission.

• Read-only, permitted lookup: may run automatically within established access limits.
• Draft or recommendation: can often be prepared automatically while clearly remaining unexecuted.
• External or consequential change: requires the approval path defined by the business owner.
• Missing evidence or conflicting records: should route to a reviewer rather than be guessed away.
• Unclear authority: stops the action until the responsible owner resolves it.

An architecture that separates proposal from execution

Give the agent responsibility for gathering permitted evidence and preparing a structured proposal. Give an application policy service responsibility for routing that proposal. Give an authorized human responsibility for the decision. Give a bounded execution service responsibility for applying the approved operation and checking its prerequisites again.

A workflow framework can help persist and resume execution. For example, LangGraph interrupts provide a mechanism to pause for external input, while its persistence features maintain state. Those mechanisms still need application-level reviewer authorization and an enforceable execution policy.

Define approval states before implementing the UI

The following state model is a proposed starting point, not a framework-specific API. Keep the distinction between a decision and execution: an approved action may still fail validation, encounter an upstream error or expire before it runs.

Use an atomic state transition or equivalent concurrency control when claiming an approved action. Two workers should not independently execute the same approval. State alone is not a duplicate-prevention mechanism unless the underlying update and execution strategy are designed for concurrent workers and uncertain outcomes.

Worked example: an agent proposes a service credit

Suppose a customer-service agent assembles evidence that a fictional customer may qualify for a service credit. The agent may retrieve permitted ticket facts and draft a recommendation. It cannot change the customer’s balance. An authorized operations reviewer must decide, using the organization’s actual policy.

Step 1: prepare a bounded proposal

The proposal identifies the customer account, the exact credit amount and currency, the reason, source references and relevant record version. It also records the workflow identifier and the policy version used for routing. If required evidence is missing, the proposal remains incomplete rather than silently adopting an assumed value.

Step 2: route and persist

The policy service selects an eligible review queue based on the requested operation and organizational rules. The workflow persists the proposed action and evidence references. A notification links the reviewer to the authenticated application; it does not carry an unauthenticated “approve anything” command.

Step 3: capture an exact decision

The reviewer sees the target, amount, evidence and expected effect, then approves or rejects the specific proposal. Store the reviewer identity, decision time, proposal version and any required rationale. If the reviewer changes the amount, create a revised proposal and evaluate whether that revision requires a new approval path.

Step 4: revalidate and execute

Before applying the credit, the executor checks that the approval is valid, the reviewer was authorized, the operation matches the approved payload and the customer record has not changed in a relevant way. It uses the business service’s supported duplicate-prevention mechanism where available. It then records the authoritative result instead of treating a tool call being sent as proof of success.

This example shows why proposal preparation and execution should use separate operations. For integration-layer choices, see MCP vs function calling vs REST APIs.

Design a review screen that supports a real decision

A useful review interface answers “What will happen if I approve?” before asking for a click. Put the requested change and affected record near the decision controls. Present retrieved evidence with source references and clearly identify generated interpretation.

• Action: the business operation and affected account or record.
• Before and after: the proposed field changes or transaction details.
• Evidence: source links, relevant excerpts and their timestamps.
• Uncertainty: missing evidence, conflicting facts and assumptions.
• Authority: why this reviewer is eligible, without exposing unnecessary access details.
• Decision controls: approve, reject and request changes with accessible labels and visible focus states.
• Validity: proposal version and expiry where relevant.

Avoid preselected approval and ambiguous labels such as “Continue” when the click authorizes a business change. Keep the action usable by keyboard and ensure the record and proposed change remain understandable on a narrow screen. A notification preview is not a replacement for the full review context.

Handle expiry, escalation and retries explicitly

Approval expiry

Set validity according to the business workflow. A proposal involving rapidly changing account state may need a shorter window than an internal content draft. When the window expires, the executor stops and requests renewed review. A timeout must not become automatic approval unless an explicitly authorized policy permits that exact behavior.

Escalation and reassignment

If a reviewer is absent, route to another eligible reviewer or queue. Preserve the original request and reassignment events. Do not broaden permissions simply because a deadline is approaching. If nobody is authorized, report that the operation remains pending.

Restart and recovery

Persist the proposal and decision outside a single process’s memory. Test a worker restart while waiting for review and another restart after execution begins. When using a framework’s resume mechanism, understand which code may run again; keep irreversible side effects outside replayed preparation steps or protect them with appropriate duplicate controls.

Uncertain execution

If the downstream service times out after receiving a request, the operation may already have succeeded. Mark the result as uncertain, query the authoritative system using a correlation or operation identifier and reconcile before retrying. “No response” is not proof that no change occurred.

What should the audit trail contain?

The audit trail should explain the chain from evidence to proposal, decision and actual result. It should not simply preserve a transcript and expect an investigator to infer authority from conversation text.

Protect sensitive evidence and tokens from ordinary logs. Store references or controlled summaries when full content is unnecessary. Define retention, investigation access and correction procedures with the data owner. An audit record is useful only if the organization can trust its integrity and retrieve it appropriately.

Acceptance tests before enabling a write operation

1. Unauthorized reviewer: a valid login without the required review role cannot approve.
2. Changed payload: changing the target, amount or important parameters invalidates the previous approval.
3. Changed record: a relevant upstream record change triggers revalidation and, where required, renewed review.
4. Expired approval: the action cannot execute after its validity window closes.
5. Concurrent workers: duplicate processing does not apply the business effect twice.
6. Uncertain result: an upstream timeout enters reconciliation rather than unrestricted retry.
7. Rejected request: the agent cannot route around the rejection by reformulating the same action.
8. Restart: a persisted review request resumes without losing its evidence or decision history.
9. Malicious evidence: instructions in a retrieved document cannot select a reviewer or grant approval.
10. Accessibility: a reviewer can inspect evidence and make the decision with keyboard navigation.

Track review queue age, rework, escalation, incorrect routing and reconciliation frequency alongside task completion. These reveal process problems that a simple “percentage approved” metric can hide. Establish a baseline before claiming improved efficiency.

Common questions about human-in-the-loop AI agents

Plan reviewable AI workflows

Discuss an AI agent integration assessment with Prominent AI Services LLP. Start with a defined action, the person accountable for its approval and the evidence needed to make that decision.

Technical references reviewed 2 November 2026. The state model and service-credit scenario are proposed examples, not measured client outcomes.