Human in the Loop: Deliberate Decisions and the Limits of Autonomy

Imagine an agent asked to fix a small bug. It finds the right file, prepares a change and passes the checks. Then it decides that, for compatibility, it also needs to add a database migration and publish a new version of a package. The model may be technically right about the need, but the original assignment gave it no right to take those two extra actions. Where does carrying out a task end and a new decision begin?

Learning outcome. After this unit you will be able to tell work that can be delegated in advance from a decision that requires human authority; describe the boundary of a permission and the evidence it needs; check whether a permission still matches the current action; and name a concrete condition for stopping or escalating.

Prerequisites. It is enough to understand that an agent carries out steps through tools and that an orchestrator coordinates those steps (see Building Your Own Orchestrator). No prior knowledge of approval systems is needed: the necessary concepts are explained below.

Human in the loop is a way of organising work in which the policy owner decides in advance which decisions and actions need human judgement or authority, while the system prepares the evidence those decisions require and technically enforces that boundary. It does not mean manually confirming every read, test or tool call. Nor is it a button that turns a vague "yes" into unlimited trust.

Building on the orchestrator, this unit concentrates on the boundary between technical execution and human responsibility: who sets the goal, who controls the resource, which action needs a separate permission, how a person can verify the consequence, and how attention affects control. The unit on text-only course production and publishing moves on to publishing knowledge; here, decisions concern a specific task and its impact.

Who is responsible, what is allowed, and where the permission ends

Assign the human roles

A model can propose an action and a tool can execute it. Neither of these, by itself, creates the authority to change the goal, accept a business risk or take responsibility for data. So before work starts, it matters to name people by their function rather than asking the abstract question "who will approve the work?".

Role	What they are responsible for	Which decision agent text cannot stand in for
Goal owner	What needs to be produced and by what criteria it is useful	Whether the result meets the real need
System or data owner	Access, technical constraints, data classification and retention	Whether the action is allowed on this particular resource
Change author	Implementing a bounded plan, explaining the diff and known risks	Whether the change is complete and verified at the stated revision
Reviewer	Independently comparing the result against the criteria and evidence	Whether there is a specific defect or deviation from the agreed scope
Owner of the risky action	Deciding on publication, access, money, production or deletion	Whether a specific residual risk is acceptable to the organisation

In a small team one person may hold several roles; in a regulated or high-risk process, policy may require them to be separated. Either way, each role must be tied to authority in a specific system. A message saying "the agent believes this is safe" does not prove that the person had the right to permit this particular action.

Not every kind of work needs a separate human approval. An authorised person can delegate defined checks or local, recoverable changes in advance, provided there are boundaries, criteria and a way to stop. But the model cannot widen such a permission through its own reasoning.

Assess an action by impact and recoverability

The labels "read" and "write" are too coarse to determine permission on their own. Reading a small local configuration file is different from reading a medical database; writing to a temporary branch is different from changing production access. At a minimum, check the scale, the sensitivity of the resource, whether the effect is external, the cost of a mistake, whether the result can be rolled back, and whether it can be noticed.

Class of action	Typical autonomy boundary	Evidence before or after the action
Public or local read for the assigned task	Can run automatically within the permitted area	Source, the relevant fragment and the version
Reading personal or secret data	Only with an explicit need, minimal scope and a permitted purpose	Data owner, category, purpose and minimisation method
Local reversible change in a dedicated branch	Can be delegated within the contract	Diff, commit, checks and recovery procedure
External write, sending or publication	Boundary depends on the audience, the data and irreversibility	Target, content, recipient, preview and permission owner
Access, secrets, payments or accounts	Requires least privilege and special control	Exactly which role, amount or secret changes and how the action is constrained
Production, migration or deletion	Usually needs stronger evidence and a policy gate	Revision, environment, recovery plan, window and accountable person

This is a guide for analysis, not a universal permission table. If an action relies on conflicting data, touches a broader resource or has a larger blast radius, its risk can grow even though the tool name stays the same. The policy owner sets the level of autonomy; the agent only checks whether a given step has stayed inside it.

Grant a bounded permission through a contract

The instruction "fix the bug" defines an outcome, but it does not yet answer questions about the resource, side changes, audience or the limit of action. An autonomy contract makes these specific:

• the goal and acceptance conditions;
• the repository, environment, data, client or other resource;
• the permitted types of operation and explicitly forbidden side actions;
• the starting revision, branch or state snapshot;
• the budget, validity period, maximum scope and limit of external impact;
• stop conditions, the escalation route and the evidence required;
• the decision owner and the requirement for separate review.

The permission applies to a defined version of the plan, not to every step the model later calls "necessary". If the requirement grows, the system must flag the deviation and show its consequence. For example: "Originally, only changing files in the branch was permitted. The plan now adds a migration and a package publication; neither action is covered by the permission."

A practical permission is best written as checkable fields rather than a long paragraph. For example, a rule might say: "permitted to change files in src/ on the task branch, run local tests and open a draft pull request (PR); forbidden to merge, publish the package, change secrets or run a migration." The system checks every tool call against such a rule. An approved plan does not automatically become permission for a new resource or a different tool.

OpenAI's official guide describes interrupting a run before a sensitive call and resuming the same session after approval; it also advises checking policy next to the tool that produces the external effect, because agent-level guardrails do not run at every step of the chain (OpenAI: guardrails and approvals). In Anthropic's Managed Agents, a policy can allow an action, wait for a human, or hand the evaluation to the server; the toolset configuration and the application's own custom tools have separate boundaries, and a session that is already running keeps the configuration it was created with (Anthropic: permission policies). These examples show possible product mechanisms, not a ready-made policy for every organisation.

"Read-only" does not always mean "safe"

Reading can violate privacy, contract terms or data-retention rules. For example, an agent may be allowed to view client records in local storage, yet sending those records to an external tool for analysis may be forbidden. Nothing changed on disk; it was the movement of the data that crossed the boundary.

Likewise, a local operation can launch a script with a side effect that changes a shared environment, and "reading" a large table can create load or copy a secret into a log. Check not only the tool's verb but the full route the information takes: where the input came from, who will see it, where the output is stored, how long it stays there, and whether that vendor is permitted.

A practical approach is to reduce the required scope first: aggregate locally, strip direct identifiers, filter columns or use test data. If the decision genuinely needs raw sensitive records, stop and involve the data owner. That may require human permission even when the external call is formally labelled read-only.

Make an approval understandable and valid for the specific action

A decision package must show the consequence

Before asking for permission, prepare a short, checkable package. It should answer practical questions without the person having to redo the whole investigation:

1. What exactly is planned? One description of the action in plain words, not a generic "continue the work".
2. Where will it happen? Repository, branch and commit, table, recipient, environment or payment account.
3. What changed, and why? A link to the diff, request, dataset or plan; separate fact from assumption.
4. What are the alternatives? For example, stop after the local fix, prepare the migration without running it, or anonymise the data.
5. What is the possible impact, and how would we recover? Who is affected if it goes wrong, whether there is a backup, and who can roll the action back.
6. What has not been verified? Open risks, missing sources, unknown consequences or a dependency on another team.
7. What does the decision permit? A clear scope, completion condition and validity period; approving one action must not silently cover the next.

If the action will take place on a new revision, show its identifier; if the content changed after the package was prepared, the old review does not confirm the new version. The reviewer's conclusion must refer to the same artefact that will be executed. Approving only a polished summary is dangerous: the person needs enough of the source or evidence to check any material claim.

GitHub's documentation describes pull request review as a space for comments, suggestions, approval or a request for changes before merging. It also lets administrators require reviews on protected branches (GitHub: about pull request reviews). In GitHub Actions, a dedicated environment can wait for a designated reviewer before a job runs; in that mode its secrets are unavailable until approval, and for a protected environment self-review by the initiator can be disabled (GitHub: deployment environments). These mechanisms are specific GitHub capabilities and depend on the plan and configuration; they do not mean that every PR or every deployment in every product must wait for manual approval. The mechanics of reviewing and publishing this course are covered in text-only course production and publishing; what matters here is binding an approval to a specific artefact and its revision.

Place a gate where it actually changes the risk

A gate is a check without which the next action does not start. Define gates through policy, not through a universal rule such as "always ask again before a write". Typical decision points:

Point	Question for the gate	What the person needs to see
Change of goal or a substantial expansion of scope	Does the owner agree to the new outcome?	The original contract and the specific difference
Architectural trade-off or a new dependency	Who bears the future maintenance cost?	Options, consequences, risks and constraints
New permission, role or secret	Does this identity have the necessary authority?	Purpose, scope, duration and the ability to revoke
Merge, production or publication	Has the release policy been followed?	Revision, checks, recipients and recovery plan
Destructive migration or deletion	Do the required copies and a recovery owner exist?	The exact resource, expected impact, rollback and window
Billing or spending external funds	What budget or commitment is being created?	Amount, period, recipient and limit

The system can automate the safe preparation that comes before a gate: collect test results, compare the list of files against the permitted scope, prepare a migration plan, calculate an amount or create a draft message. The person makes precisely the decision that was not delegated in advance. Conversely, if policy allows an automatic merge after independent review and successful continuous integration (CI) checks, demanding one more manual "yes" just because it is a merge may add no control at all.

A gate does not remove the need for technical constraints. If the system has already given the agent production access and then relies only on a conversational "ask the human", a missed request can turn into a real write. Least privilege, environment isolation, a narrowly scoped secret, server-side argument validation and gates must complement one another. OpenAI specifically stresses that control belongs next to the tool with the side effect; Anthropic describes containment through a restricted execution environment (a sandbox) as another layer of protection (OpenAI: guardrails and approvals, Anthropic: how we contain Claude).

Bind the decision to a version and a time limit

An approval is an event concerning a particular object, not a property of the user such as "I trust this agent". The minimal record should contain the decision maker, their role, the rule or request, the object and its revision, the limit of action, the date or validity period, the outcome and a link to the evidence. Where needed, a permission can be single-use, limited in the number of uses, or revocable by a separate action.

Re-approve an action if any material aspect of it has changed: the commit, the recipient, the environment, the list of data, the scope, the model's proposal, the budget or the consequences for other people. After an external call times out, do not treat either the approval or the execution as complete until the actual state has been checked. An expired or cancelled permission must never be silently carried over to a new session.

A condensed form in pseudocode:

PSEUDOCODE
approval = {
    actor: authorized_reviewer,
    action: "run migration",
    resource: "staging/database-17",
    proposal_revision: "commit:abc123",
    scope: "tables: invoices, dry_run: false",
    expires_at: "<task-specific timestamp>",
    decision: "approve",
    evidence: ["review:482", "backup-check:77"],
}

if not valid_for_current_action(approval):
    pause_and_request_a_new_decision()
else:
    execute_only_approved_action()

This is an illustration of fields, not the schema of any particular application programming interface (API). Changing the environment from staging to production, or the commit from abc123 to new code, makes this permission unusable without a fresh review. In the schemas of your own tools, the validator must check this context before the action, not merely ask the model to paste in similar-looking text.

Stop on a specific uncertainty

The agent should prepare whatever can be safely done and then name exactly which decision is missing. Stopping is appropriate when the required access is lacking; sources contradict each other; the action goes beyond the agreed scope; an important assumption carries high consequences; or an external effect remains ambiguous after a timeout.

A bad message: "I can't continue — what should I do?" It hands the person all the unresolved work. Better: "Local tests passed on commit abc123. The plan includes a migration of two tables that is not in the original permission. I have prepared the database migration plan and a backup check; a decision is needed on whether the migration may be run in staging only. Production has not been changed."

If the responsible person is unavailable, the system stays blocked, keeps the evidence package and does not carry out the action later under the old permission. The same applies to a rejection: reject is a completed decision for that request, not a signal to rephrase the same request until somebody clicks approve. A new proposal may be submitted only after a real change in the option or the evidence, with an explicit explanation of the difference.

Do the permitted work before disturbing a human

If a source is already available within the task, read it. Run the permitted local checks. Check the format, constraints, base revision and known recovery conditions. Do not ask a person to find an instruction, answer a question that is answered in a file, or approve a test if that test is explicitly part of the contract. Prepare a conclusion with links to the relevant sources.

At the same time, the ability to investigate an option is not permission to implement it. The agent can write a proposed migration plan and a list of risks without running the migration. It can draft an email and check the recipient without sending it. It can compare quotes without creating an invoice. This separation leaves the meaningful decision to the person and saves their attention.

Human attention, accountability and evolving the policy

Managing the number of requests is part of safety

If the agent asks about every step, interruptions pile up for the person. Over time they click "approve" faster, put off the whole queue, or stop distinguishing an ordinary read from a risky publication. If there are no requests at all, on the other hand, the system can hide a decision that should have been seen. The goal is not the smallest possible number of dialogues; the goal is for the important request to get attention.

In an engineering post dated 25 March 2026, Anthropic reports that Claude Code users approved about 93% of permission requests; the authors describe this as a possible source of fatigue from frequent approvals (approval fatigue). In its May write-up on containment, Anthropic reports an 84% reduction in such requests: writes were allowed within a defined workspace, and network access was blocked by default (Claude Code auto mode, how Anthropic contains Claude). These are the vendor's own telemetry and engineering account, not a universal measure for all agents.

The same account shows why approval should not stand in for the right environment boundary: in the case it uncovered, a repository's local configuration could execute a hook before the user saw the prompt asking whether to trust the directory. The company deferred reading and executing local settings until trust had been established. The engineering lesson is not that people must read every warning more carefully; in this case, the sequence of prompts itself was insufficient. The risk had to be blocked before the untrusted configuration ran.

To wear down attention less, you can:

• group dependent decisions, while allowing each risky part to be declined separately;
• separate informational messages from actions that need a real decision;
• show urgent, irreversible or external actions first, rather than producing an even stream of notifications;
• assemble a single change map: resource, revision, consequence, test, unknowns and recovery plan;
• leave the person able to stop a longer process without forcing them to assess every small operation.

Grouping must not hide authority behind a multi-step "approve all" button. A package can show related actions in one view but record separate decisions: permit the code change, reject the migration, bring in the data owner for the publication. A refusal or an unanswered item must not be interpreted as tacit approval.

Remove dependence on the founder while keeping a human owner

In The E-Myth Revisited, Gerber distinguishes working inside a business from working on the system that should deliver a repeatable result without the founder manually coordinating every step. A narrow transfer of this principle is useful for agentic work: repeatable, low-risk decisions can be encoded into clear procedures and delegated, but someone remains the owner of the rules, the exceptions and changes to the policy. The book is about small business; it offers an analogy for systematisation, not a technical standard for agents.

Peopleware examines human working conditions, time for focused thinking and the effect of interruptions; in particular, the table of contents of the third edition includes chapters on Flow, incompatible multitasking, partial attention and meetings. If every ordinary step demands immediate review, the quality of attention drops and the work becomes fragmented. The conclusion is not to remove all approvals: it is to define which decisions actually need competent judgement and to plan a suitable package for them.

Team Topologies, 2nd edition, is useful here as a principle of clear owners and interactions, and of managing teams' cognitive load. A system owner should know how to ask a security or operations role to review a specific change, rather than sending someone into an undefined chain of chats. Teams can divide areas of competence: for example, the change author prepares the evidence, the data owner assesses the export, and the person responsible for operations decides on the launch. Do not copy team typologies onto an impersonal set of agents; organisational responsibility and authority remain human.

Record the decision so that it can be reconstructed

A useful approval log answers these questions: who made the decision and in what role; which action and resource were shown; what the revision was; which policy applied; what was permitted, rejected or made conditional; whether the action took place; and what evidence the outcome rests on. Also keep the real system's result — an object identifier, commit, deployment number or receipt — not just the agent's phrase "all done".

For quick auditing, group the record into three parts:

• Decision: who made it and what they permitted, rejected or constrained.
• Basis: the rule, task, revision and links to checkable evidence.
• Outcome: whether the action happened and what the external system confirmed.

The log should be sufficient but not boundless. Record a short description of the decision, a link to the artefact, the policy reason and the observed outcome. Do not copy passwords, full client tables or other unnecessary personal data into a comment or notification. Do not try to replace evidence with the model's hidden chain of reasoning: a person needs checkable claims, sources and consequences, not an internal stream of thought.

In an audit store it makes sense to have events such as approval_requested, approved, rejected, expired, revoked, action_started, action_completed, action_failed and result_verified. Capture the causal link through the task identifier and the contract revision. If a permission was rejected, store that outcome so that another worker or a new run does not treat the absence of an action as evidence of permission.

Expand autonomy on evidence, not on good impressions

Review the rules when the model, tool, access, environment, data category, workflow or task volume changes. Watch the real consequences: how many requests were rejected; how many were unnecessary; how many decisions needed correction; where the agent drifted from the agreed scope; how often people stopped an action; whether an error happened despite approval. Waiting time and fatigue matter, but on their own they do not measure safety.

A few successful runs are a weak basis for unlimited permission, especially if the examples covered only familiar or risk-free situations. Expand the boundary one controlled category at a time, record what changes, and keep a way to return quickly to the previous policy. If a new class of uncertainty appears, reduce autonomy in that area instead of adding yet another general warning.

Four worked examples

Example 1: instead of a small change, the agent adds a migration and a publication

The original task allows the agent to change one module, preserve compatibility and open a PR. The agent discovers that a new column is needed, adds a destructive migration and proposes publishing the package so that other teams can use the fix. The person approved only the code change.

The system compares the new plan with the contract: the migration file falls outside the permitted directory, and publication is not part of the goal. The worker can finish the local tests on the approved part and prepare separate proposals for the migration and the release; it executes neither. The goal owner sees why the scope changed; the database administrator or owner sees the plan, the target, the backup and the recovery method; the package manager sees the new version, the audience and the release conditions. If the team decides to postpone both actions, the agent can still finish and submit the permitted PR with the limitation clearly described.

A fresh decision is needed here not because the model has become suspicious, but because the new impact was not part of the authority granted. External effects go into the log separately; an approved PR does not automatically create permission for a migration or a publication. The person can choose a partial path: approve only a staging plan for the migration, or send the author back to an option without it.

Example 2: the same migration for staging and production

The migration file is identical, but the environment changes the risk. The test database contains synthetic data and a recoverable copy; in production, customer invoices are being written at that very moment, and a rollback may be difficult. The name run_migration does not determine whether the agent should act autonomously.

The contract allows the agent to check the plan, the backup and the impact on staging automatically. If staging complies with the policy, the agent runs the migration there only and keeps the result. For the move to production it assembles a new package: the target environment, the migration revision, a time estimate, the expected locking, the backup status, rollback or forward fix, the launch window, the accountable person and the known uncertainties. An authorised person can approve, reject or postpone this specific production step.

If GitHub environments are used, a separate deployment gate can be configured: the workflow waits for a required reviewer, and environment secrets become available only after approval. GitHub lets you prevent self-review by the initiator, but the availability and behaviour of these features depend on the repository settings and the plan. Approval for staging does not carry over to production here, because the data, the blast radius and the accountability are different.

Example 3: exporting client records without changing the source

An analyst asks for the reasons users leave the service. The agent has read access to the profiles table and can call a third-party service to classify text. The export will not change any database rows, but it will hand the third party email addresses, correspondence and purchase history.

The agent must stop before creating the external request: first name the fields, the vendor, the storage location and the purpose; check the agreement and the data-transfer policy; and show that the analysis could start on a local aggregated sample or synthetic examples. The data owner assesses this specific transfer. If there is an approved service and the necessary fields can be reduced, the decision may permit only a specific set with a limited retention period. Otherwise, the agent stops and asks the data owner to propose a different route.

The outgoing package records the fields, the number of records, the recipient and the minimisation method, but it does not duplicate all the records in the approval comment. Read-only access to the source is not permission to export. The danger lies in confidentiality, the contract and uncontrolled copying, not only in modifying the database.

Example 4: the reviewer receives questions that already have answers

The agent asks the person to determine the format version, suggest a permitted directory, approve local tests, choose a variable name and find the link to the schema — even though all of this is already in the documentation and the contract. After ten such messages, the real question about data or rights will appear on screen.

Before escalating, the worker reads the available documentation, checks the schema, makes the permitted diff and runs the usual local checks. Instead of six requests it submits a short package: "The format and directory are defined by document X; the checks passed on revision Y. The only open question: is it permitted to publish the selected records to the external service Z? Here are the fields, the purpose, the data retention, an alternative without the transfer, and the decision owner."

Grouping removes noise but does not mix unrelated decisions. The person can permit the external analysis and still reject a publication if one comes up later. The checks run autonomously under the contract; permission for the transfer is decided by a separate owner. This way the person answers for their own authority rather than redoing the agent's research.

Summary

Human approval should concern the decision that genuinely remains with an authorised person. The policy owner sets the boundaries; the agent does the permitted work, gathers checkable evidence and stops when the action, resource, revision or risk changes. Technical constraints should make it impossible to step outside the boundaries, and the log itself should show the decision and the outcome without secrets or excess data.

Sources and further reading

Official documents and publisher pages were checked on 10 October 2026. The product properties below belong to the documentation cited and may change.

• OpenAI, Guardrails and human review — configurable approval of tool calls, interrupting and resuming a run from saved state, the limits of guardrails. Checked 10 October 2026.
• OpenAI, Safety best practices — an example of giving a human access to the sources needed to verify a summary; general platform recommendations, not the policy of any given organisation. Checked 10 October 2026.
• Anthropic, Managed Agents permission policies — the always_allow, always_ask and auto policies, the boundaries of built-in, MCP and custom tools, toolset configuration in a running session; the feature is marked as beta. Checked 10 October 2026.
• Anthropic Engineering, How we built Claude Code auto mode, 25 March 2026, and How we contain Claude across products, 25 May 2026 — the company's own observations on approval of permission prompts, sandboxing, environment boundaries, and a discovered vulnerability that could take effect before the trust dialog was shown. The vendor's own telemetry is not an independent universal measurement.
• GitHub, Pull request reviews and Deployments and environments — reviewer decisions, required reviews, preventing self-review, and environment secrets becoming available only after approval. Details depend on the plan and settings.
• Tom DeMarco and Tim Lister, Peopleware: Productive Projects and Teams, 3rd edition, Addison-Wesley Professional, 2013, Pearson page and table of contents — human working conditions, flow, interruptions, incompatible multitasking, partial attention and team practices.
• Michael E. Gerber, The E-Myth Revisited, 1995, author's official page — working on the business and a repeatable system instead of constant manual management; used only as an organisational analogy, not an engineering standard.
• Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, 2nd edition, IT Revolution, 2025, official second-edition page — cognitive load, clear ownership of boundaries and responsibility for team interactions. Checked 10 October 2026.