Human-in-the-Loop Architecture: When Humans Approve Agent Decisions

Idea in 30 seconds

Human-in-the-Loop Architecture is a governed scheme where the system involves a human before executing a risky action.

The agent can propose an action, but the final decision for critical steps is made by a human: approve, reject, or revise.

This is not manual control of every step. A human is involved only where risk is truly high.

When needed: when agent actions can change state, spend money, touch sensitive data, or create legal risk.

The LLM must not execute critical side effects (state changes) on its own. It only proposes an action, and the system moves it into a controlled approval process.

Problem

Without Human-in-the-Loop, a system often falls into one of two extremes:

• either the agent acts too autonomously;
• or the team manually reviews almost everything and loses speed.

Typical failures without a clear HITL layer:

• a risky action is executed without approval;
• it is not visible who approved an action and why;
• it is hard to roll back or explain consequences of an error;
• escalation process differs across teams and becomes chaotic.

In production, this turns into incidents, slow releases, or weak auditability.

Solution

Add Human-in-the-Loop Architecture as an explicit approval boundary between the agent decision and actual action execution.

This layer defines:

• which actions run without approval;
• which actions require human confirmation;
• how to handle approve, reject, revise, and timeout.

Analogy: like dual sign-off in financial operations.

The system may prepare a payment, but a large amount requires confirmation from a responsible human.

Human-in-the-Loop works the same way: important steps are not executed automatically.

How Human-in-the-Loop Architecture works

Human-in-the-Loop Architecture is a governed layer between Agent Runtime and action execution that moves critical steps into human approval mode.

This cycle preserves automation speed while keeping control over critical actions.

In code, it looks like this

class HumanInTheLoopArchitecture:
    def __init__(self, policy, approval_queue, tool_execution):
        self.policy = policy
        self.approval_queue = approval_queue
        self.tool_execution = tool_execution

    def execute_action(self, action, context):
        decision = self.policy.check(action=action, context=context)
        mode = decision.get("mode")

        if mode == "allow":
            return self.tool_execution.execute(action=action, context=context)

        if mode == "require_approval":
            ticket_id = self.approval_queue.create(
                action=action,
                context=context,
                reason_code=decision.get("reason_code", "approval_required"),
            )

            # Simplified synchronous example for illustration.
            review = self.approval_queue.wait(ticket_id=ticket_id, timeout_s=300)
            if review is None:
                return {"ok": False, "reason_code": "approval_timeout"}

            status = review.get("status")
            if status == "approved":
                approved_action = review.get("action_override", action)
                return self.tool_execution.execute(action=approved_action, context=context)

            if status == "revise":
                return {
                    "ok": False,
                    "reason_code": "approval_revision_required",
                    "feedback": review.get("feedback", ""),
                }

            return {"ok": False, "reason_code": "approval_rejected"}

        return {"ok": False, "reason_code": decision.get("reason_code", "policy_denied")}

In this example, wait(..., timeout_s=300) is shown for clarity.
In production, HITL is more often asynchronous: the system creates an approval ticket, ends the current run with pending_approval, and then resumes after a human decision.

How it looks at runtime

Request: "Export customer database to an external CRM and send an email to all contacts"

Step 1
Agent Runtime: forms action -> export_customers + send_campaign_email
HITL Gate: classify -> require_approval (high_risk_data_export)

Step 2
System creates an approval ticket with context and reason
Human: revise -> allow only the "active_customers" segment, no bulk mailing

Step 3
Tool Execution Layer: executes only the approved action
Runtime: returns result + reason_code to trace

Human-in-the-Loop does not block automation entirely. It adds control at points of real risk.

When it fits - and when it does not

Human-in-the-Loop Architecture is useful where the cost of error is high and a responsible human is needed at critical steps.

Fits

Does not fit

In such cases, policy-gates without manual approval are often enough:

decision = policy.check(action, context)
if decision["mode"] == "allow":
    execute(action)

Typical problems and failures

A stable HITL layer needs more than an "Approve" button; it needs clear operational discipline.

How it combines with other patterns

Human-in-the-Loop Architecture works as a governed control layer over core execution mechanisms.

• Agent Runtime - Runtime drives the loop, while HITL decides which steps need a human.
• Tool Execution Layer - after approval, action executes through a controlled tool gateway.
• Policy Boundaries - policy rules define when require_approval is triggered.
• Hybrid Workflow Agent - HITL is often embedded in workflow commit steps for high risk.
• Orchestration Topologies - in multi-agent systems, HITL is applied to selected branches or the final merge step.

In other words:

• Policy Boundaries define what is risky
• Human-in-the-Loop Architecture defines how exactly a human confirms or blocks that action

How this differs from Supervisor Agent

Supervisor Agent and HITL can be combined: the supervisor performs pre-filtering, and a human approves only the highest-risk steps.

In short

FAQ

Q: Does HITL mean every action must be approved by a human?
A: No. Practical approach: only high-risk actions go to approval, the rest execute automatically.

Q: What is better for fail-safe: timeout = allow or timeout = deny?
A: For risky write actions, fail-closed is usually used: timeout => deny or a safe fallback.

Q: In HITL, can you not only approve but also modify an action?
A: Yes. revise mode allows a human to approve an action with constraints (amount, segment, scope).

Q: When is it better to choose Supervisor Agent instead of HITL?
A: When you need fast automated policy control without manual intervention at every risky step.

What Next

Human-in-the-loop reduces risk. The next step is to see how this connects to technical system boundaries:

• Policy Boundaries - which actions to allow, block, or send to approval.
• Hybrid Workflow Agent - where deterministic workflow fits, and where bounded agent decisions fit.
• Orchestration Topologies - how to split decisions across multiple agents.
• Production Stack - how to assemble this into a managed production architecture.