Agent Autonomy and Human-in-the-Loop

Autonomy is not an on/off switch. You might let an AI draft an email by itself, require approval before sending it, and completely forbid it from transferring money. Each action can have a different safety level.

Low risk:    AI suggests → human decides
Medium risk: AI prepares → human approves → system acts
High risk:   restricted or handled entirely by a human

What You Will Learn

• What autonomy means in an agent and why it should be set per action.
• Where approval gates, escalation rules, and human review belong in the loop.
• How risk, reversibility, cost, confidence, and permissions affect the choice.
• Why a human-in-the-loop design needs useful context, not just an “Approve” button.
• How to increase autonomy gradually using evidence from evaluation and monitoring.

Module 8 taught you to place a task on a spectrum — how much of its execution needs dynamic decision-making versus fixed structure. This module asks a related but separate question: once you’ve decided a task needs an agent, how much of that agent’s actual execution should proceed without a human checking in? These are different dials.

A task can need agent-level flexibility and still warrant heavy human oversight — the payment-investigation agent from earlier in this course needs to reason dynamically about what to check, and it should still not be free to issue an arbitrarily large refund with nobody reviewing it first.

A grounding analogy, before the technical spectrum

It helps to have something concrete in mind before the terminology starts, and there’s a useful, widely-recognized real-world parallel worth borrowing: the automotive industry’s own scale for self-driving vehicle autonomy, formalized by SAE International and now standard vocabulary across that entire field. Level 0 is no automation at all — a human does everything. Level 2 offers real assistance — steering and braking help — but a human must stay fully attentive and ready to take over instantly.

Level 3 allows the car to handle driving under specific conditions, with the human expected to intervene only when asked. Level 4 operates fully on its own within a defined, bounded environment, no human attention required there. Level 5 removes the boundary entirely — full autonomy, anywhere, under any condition.

Notice this is the same underlying shape as this module’s own spectrum, industry-tested at enormous real-world scale and real stakes for years before most of today’s AI agent products existed. That’s the analogy. Here’s exactly where it stops being literal, because the difference matters: a self-driving car’s autonomy level is usually fixed for the whole vehicle, tuned for road and traffic conditions in general.

An AI agent’s autonomy, as you’re about to see, is far more useful when it’s not fixed uniformly — different actions, within the very same agent, warrant different levels, gated individually rather than as one setting for the whole system. Hold onto the shape of the automotive scale; don’t assume the “apply one level to everything” part carries over.

The spectrum

Human does everything
        ↓
AI suggests
        ↓
AI executes with approval
        ↓
AI executes with guardrails
        ↓
AI operates autonomously

At the far left, a human performs the entire task, with AI playing no role at all — the starting point every agentic system implicitly replaces some portion of. AI suggests means the system produces a recommendation — a drafted refund decision, a proposed email — that a human reviews and acts on themselves; the AI never touches the real system directly.

AI executes with approval means the agent takes the action, but only after a human explicitly signs off on that specific action first — this is where our support agent’s $650-refund scenario from Module 3 lives: the agent has done the real diagnostic work and knows the correct action, but a human confirms it before it happens.

AI executes with guardrails removes the per-action human checkpoint for most cases, replacing it with structural constraints — permission boundaries, spending caps, an automated risk classifier — that catch dangerous actions without requiring a human to review every single one. AI operates autonomously is the far end: the agent acts with essentially no real-time human involvement at all.

Three different postures for the human’s role

Three terms describe how a human relates to an agent’s execution, and they’re worth distinguishing precisely, because “a human is involved” can mean different things.

Human-in-the-loop means a human reviews and approves before an action executes — the human is a required, blocking step in the sequence. This maps directly onto “AI executes with approval” above. Human-on-the-loop means the agent acts on its own, but a human is actively watching and can intervene if something looks wrong — a real, meaningful safety net, but not a blocking checkpoint; the agent’s action has already happened by the time a human could stop the next one.

Human-out-of-the-loop means no real-time human involvement at all — the agent’s decisions and actions happen without anyone watching as they occur, and any review, if it happens, is after the fact.

Why more autonomy means more of both

Here’s the trade-off stated as plainly as this course states anything: more autonomy means more potential value, and more potential risk, at the same time — not one or the other.

The value side is straightforward and you’ve seen it throughout this course: an agent that can act without waiting for human approval at every step completes tasks faster, handles more volume, and doesn’t bottleneck on a human’s availability. The risk side is exactly as real. Go back to the support agent’s diagnostic work in Module 4 — every individual reasoning step in that trace was sound, and the final action was correct.

Now imagine that same agent operating with full autonomy on a case where its diagnosis happens to be subtly wrong, the way Module 4’s duplicate-authorization scenario showed is possible even with correct-looking reasoning at every step. In an approval-gated system, a human reviewing the proposed action has a real, final chance to catch that error before it causes harm. In a fully autonomous system, that error executes.

This isn’t an argument against autonomy — it’s the actual reason the spectrum exists at all, and the actual reason the engineering judgment in this module matters. The important skill isn’t “always prefer more human oversight” any more than Module 8’s skill was “always prefer workflows.” It’s correctly matching the level of oversight to how much a specific action’s potential error would cost if nobody caught it.

Claude Code’s permission modes: the entire spectrum inside one product

It’s worth seeing this full spectrum implemented, precisely and deliberately, inside a single real system — because Claude Code’s permission modes map onto nearly every rung of this module’s diagram, and the product’s own documentation is explicit about the trade-off each mode represents.

In default mode, Claude pauses and asks for your explicit approval before running a bash command or making a significant file write —, per-action human-in-the-loop, closest to “AI executes with approval” on this module’s spectrum. Plan mode goes further toward the cautious end: Claude is structurally restricted to read-only operations entirely, explores and proposes an approach, and requires your explicit sign-off before any real execution begins at all — functionally, “AI suggests” formalized into an actual product mechanism, not just an informal description.

Accept edits mode shifts one notch toward more autonomy: file edits are auto-approved, while commands run through the shell still require your confirmation — a, deliberate split in which specific class of action still needs a human, rather than an all-or-nothing toggle.

Auto mode is the clearest real illustration of “AI executes with guardrails” you’re likely to find: rather than a human reviewing every command, an automated classifier reviews each one and decides whether it’s safe to run without asking, reserving human prompts for risky-looking commands. This is a structural guardrail replacing a per-action human checkpoint — not the complete absence of oversight, but oversight implemented as an automated system rather than a person. (Claude Code, Choose a permission mode)

And bypass permissions mode is the far end of the spectrum, described in Claude Code’s own documentation with language worth noting directly: it’s referred to as the “danger zone,” intended only for isolated environments — containers, VMs — specifically because it skips permission checks entirely, with no protection against a request that turns out to be harmful.

Real, documented consequences of this mode’s real risk have already surfaced publicly — one widely-circulated case study describes a user running Claude Code in bypass mode discovering their session had encountered and interacted with a remote-access trojan already present on their system, precisely the kind of consequence that per-action human review or a risk classifier would have had a chance to catch, and bypass mode’s entire design explicitly forgoes.

Some organizations disable this mode entirely for their users via managed settings, rather than leaving the choice to individual judgment on a case-by- case basis. ([Claude Code Permission Modes, explainx. ai](https://www. explainx. ai/blog/claude-code-permission-modes-explained-2026))

This is worth sitting with as a complete, concrete case study: one product, five different points on this module’s spectrum, each one a real, deliberate trade-off between speed and oversight — and a real, documented example of what can go wrong at the far, autonomous end when nothing is checking the agent’s work.

OpenAI’s tiered approach: gating specific actions, not everything uniformly

You’ve already encountered this example from earlier in this course, and it’s worth revisiting specifically through this module’s lens. OpenAI’s ChatGPT agent doesn’t apply one blanket autonomy policy to everything it does — it implements tiers. A “takeover mode” hands control directly back to the user for anything requiring login credentials or payment information, deliberately pausing its own screenshot capture during that handoff for privacy.

And separately, the system requires explicit user confirmation before any action it classifies as “significant” — submitting an order, sending an email — while allowing lower-stakes actions, like navigating a page or reading content, to proceed without interrupting the user at all.

This is directly the answer to a question this module has been building toward: autonomy doesn’t have to be a single dial applied uniformly across an entire agent’s behavior. The sophisticated version, visible in both this example and Claude Code’s permission modes above, gates specific classes of consequential action — payments, credential entry, destructive commands — while letting everything else proceed with less friction, precisely matching oversight to actual risk rather than applying maximum caution everywhere or none anywhere.

Klarna: a real, public example of autonomy walked back after the fact

It’s worth closing the real-world examples with one that shows this lesson learned the hard way, in public, by a real company — because it demonstrates that getting this dial wrong isn’t a hypothetical risk, it’s a documented business outcome.

In 2024, Klarna deployed an AI customer service agent with substantial autonomy — handling 2. 3 million chats in its first month alone, a volume the company compared to roughly 700 human agents, and paused most customer-service hiring for over a year afterward. By 2025, the company reversed course and began rehiring human staff. CEO Sebastian Siemiatkowski’s own public explanation is worth quoting directly: “We focused too much on efficiency and cost. The result was lower quality, and that’s not sustainable.”

Reporting on the reversal points specifically to the AI handling routine, high-volume queries well while struggling with harder cases — emotionally sensitive situations, multi-step problems requiring real judgment — precisely the kind of case where a human-in-the-loop or human-on-the- loop checkpoint would have had a real chance to catch a problem before it reached the customer, and a fully autonomous system simply didn’t have.

The lesson worth taking from this isn’t “autonomy failed.” It’s that Klarna initially measured and optimized for volume and cost, and only discovered the quality cost of that autonomy level after scaling to real, full production traffic — a direct, real-world instance of the value-and-risk trade-off this module opened with, learned the expensive way rather than designed around from the start.

When approval should be mandatory

Pull all three examples together and a real, usable pattern emerges, worth stating as criteria rather than a vague feeling. Approval should be mandatory — human-in-the-loop, not merely on-the- loop — when an action is hard to reverse: sending money, deleting data, sending an external communication that can’t be un-sent.

It should be mandatory when the potential cost of being wrong is high relative to the value of skipping the checkpoint — Module 3’s $650 refund threshold is a direct, concrete instance of a company drawing exactly this line.

And it’s worth mandating specifically for the narrow set of consequential action types an agent has access to, rather than applied as a blanket policy across everything it does — precisely the design choice both Claude Code’s permission modes and OpenAI’s takeover-mode-plus- confirmation approach make deliberately, and precisely the discipline Klarna’s experience suggests was missing at the scale they initially deployed.

None of this is a reason to avoid autonomy — Module 8 already established that unnecessary caution has its own real cost. It’s a reason to apply the caution specifically where it earns its keep, which is exactly the judgment this module has been building toward.

Applying the spectrum to our own recurring agent

It’s worth making this concrete against the support agent you’ve followed since Module 1, rather than leaving the criteria abstract. Its available tools split cleanly across this module’s spectrum once you apply the reasoning rather than just state it.

get_customer and get_payment_history are read-only lookups — nothing about calling them can cause harm even if the agent’s reasoning is completely wrong at that moment, which makes them appropriate for full autonomy, no approval needed, the same way Claude Code auto-approves read operations in every permission mode without exception. check_payment_gateway and check_account_status are the same category — pure observation, no real-world effect, autonomous by default.

create_support_ticket sits a notch higher: it doesn’t directly affect the customer’s account or money, but it does create real, lasting internal records and route work to a human team, which makes “AI executes with guardrails” a reasonable fit — let it run automatically, but log every creation for review rather than requiring a human gate before each one.

send_email is more consequential, since it reaches a real customer directly; a reasonable middle ground is guardrails plus monitoring — human-on-the-loop — rather than blocking approval, unless the email’s content itself touches something sensitive. And retry_payment is exactly where mandatory human-in-the-loop approval belongs once the amount crosses a real threshold, precisely mirroring Module 3’s $650 example: hard to reverse cleanly, consequential if wrong, and worth the latency cost of a human checkpoint specifically for the cases where that cost matters.

Notice what this exercise demonstrates: a single agent, built from a single toolset, doesn’t sit at one point on this module’s spectrum at all. Different tools, within the same agent, warrant different autonomy levels — exactly the same lesson Claude Code’s and OpenAI’s tiered designs demonstrated at the product level, now applied at the level of one small, familiar toolset you’ve known since the start of this course.

How this gets implemented in code

Everything above has described autonomy conceptually and shown you real products that implement it. It’s worth closing with what that implementation looks like in code, because “require human approval” isn’t magic — it’s a real, structural check in your orchestration logic, extending exactly the tool-execution pattern from Module 5.

Recall handle_tool_call from that module — it validated arguments, then executed. An approval-gated version adds one meaningful decision point before execution ever happens:

def handle_tool_call(tool_call, tool_registry, approval_policy):
    tool = tool_registry.get(tool_call.name)

    if tool is None:
        return error_result(f"Unknown tool: {tool_call.name}")

    validation_error = validate_arguments(tool_call.arguments, tool.schema)
    if validation_error:
        return error_result(validation_error)

    if approval_policy.requires_approval(tool_call):
        pending = save_pending_action(tool_call)
        notify_human_for_review(pending)
        return waiting_result(pending.id)  # loop pauses here try:
        result = tool.execute(**tool_call.arguments)
        return success_result(result)
    except Exception as e:
        return error_result(str(e))

Notice what changed from Module 5’s version: a new check, approval_policy.requires_approval(tool_call), sits between validation and execution. When it returns true, the function does not call the tool — it persists the pending action somewhere durable, alerts a human, and returns control without ever touching the real system. This is the literal mechanism behind “human-in-the-loop” from earlier in this module: not a suggestion in a prompt, a real branch in your code that the tool call structurally cannot get past without a separate, later confirmation.

The approval_policy itself is where this module’s actual criteria become code, not just discussion:

class ApprovalPolicy:
    def requires_approval(self, tool_call) -> bool:
        if tool_call.name == "retry_payment":
            return tool_call.arguments["amount"] > 500
        if tool_call.name in ("create_support_ticket",):
            return False  # guardrails tier: logged, not gated
        if tool_call.name in ("get_customer", "get_payment_history",
                               "check_payment_gateway", "check_account_status"):
            return False  # read-only, always autonomous
        return True  # unrecognized or unlisted actions default to caution

This is the whole mechanism — the $650 threshold from Module 3, and the tool-by-tool sorting from earlier in this module, expressed as real, enforceable code rather than a policy document nobody checks. Notice the final line especially: an action this policy doesn’t explicitly recognize defaults to requiring approval, not to autonomy — a deliberate, important choice, since a newly-added tool nobody’s classified yet should fail safe, not fail open.

The “guardrails” tier — Claude Code’s auto mode, conceptually — works the same way structurally, just with an automated check standing in for a human reviewer instead of pausing the loop entirely:

def spend_guardrail(tool_call, running_total, cap=1000):
    if tool_call.name == "retry_payment":
        if running_total + tool_call.arguments["amount"] > cap:
            return blocked_result("Task-level spend cap exceeded")
    return None  # allowed to proceed

This runs automatically, on every call, with no human involved unless it trips — exactly the structural difference this module drew between “AI executes with approval” (a person, every time) and “AI executes with guardrails” (code, checking every time, escalating only when something crosses a line). Module 11 goes considerably deeper on building guardrails like this properly — this is deliberately just enough to make the mechanism concrete, not the full treatment.

When Human Approval Is Worth the Delay

Require approval for actions that are expensive, difficult to reverse, legally important, privacy-sensitive, or outside the agent’s normal confidence and permission boundaries. Low-risk, reversible actions can often proceed automatically within strict limits.

Common Misconception

Incorrect idea: Adding an approval button automatically creates meaningful human oversight.

Why it is incorrect: The reviewer needs the proposed action, evidence, risk, alternatives, and consequences. A rushed person approving an unexplained request is not an effective safety control.

Key Takeaways

• Task complexity (Module 8) and human oversight level (this module) are separate dials — a task can require agent-level flexibility and still warrant heavy approval requirements at the same time.
• The spectrum runs from a human doing everything, through AI suggesting, executing with approval, executing with guardrails, to fully autonomous operation — each step trading a real checkpoint for real speed.
• Human-in-the-loop is a blocking, required checkpoint before an action executes; human-on-the-loop is active monitoring with the power to intervene, but not a blocking gate; human-out-of-the-loop has no real-time human involvement at all.
• More autonomy means more potential value AND more potential risk simultaneously — not a trade where you pick one side, a trade where both sides grow together.
• Claude Code’s permission modes — default, plan, accept edits, auto, and bypass — implement nearly this entire spectrum inside one real product, including a documented real-world consequence (a discovered RAT) at the fully autonomous, unchecked end.
• OpenAI’s ChatGPT agent and Claude Code both demonstrate the same sophisticated pattern: gate specific, consequential action types — payments, credentials, destructive commands — rather than applying one blanket autonomy policy uniformly across everything an agent does.
• Klarna’s real, public 2024-2025 reversal is a documented instance of this exact lesson learned after the fact — high autonomy optimized for volume and cost, with the quality risk only becoming visible once deployed at, full production scale.

Think Like an AI Engineer

• Look back at the support agent’s available tools from earlier in this course: get_customer, get_payment_history, check_payment_gateway, check_account_status, retry_payment, create_support_ticket, send_email. Sort them into which ones warrant mandatory human-in-the-loop approval and which ones don’t, using this module’s criteria — irreversibility and potential cost of error — rather than intuition alone.

• Claude Code’s auto mode uses an automated classifier instead of a human to decide whether a command is safe to run without asking. What are the real trade-offs of trusting a classifier over a human reviewer here? Under what circumstances would you want that classifier itself audited or reviewed?

• Klarna measured volume and cost savings and only discovered a quality problem after scaling to full production. Design one specific metric you’d want tracked before increasing an agent’s autonomy level, that might have surfaced Klarna’s actual problem earlier rather than after the fact.

• A teammate proposes putting every single action an agent takes behind human approval, “just to be safe.” Using this module’s argument, what’s the cost of that decision, and what would you propose instead?

Module 10 turns to something this module has already previewed several times without naming it directly: how agents fail in practice — hallucinated tool arguments, wrong tool selection, infinite loops, and more — with a, practical answer for each one: what happened, why, how to detect it, how to prevent it, and how to recover.