Human in the Loop vs Fully Agentic AI: How to Choose

Choose between human in the loop and fully agentic AI one kind of job at a time, not one tool at a time. Score the job on five things: how reversible it is, how far a mistake would spread, how often it happens, what an error costs before anyone notices, and how easily the output can be checked by something other than a person’s judgement. Work that is easy to undo and easy to check can run fully agentic. Work that is hard to undo and hard to check needs a person to decide. Most work sits in between, and the answer there is a middle ground: a person on the loop rather than in it, and approval thresholds that stop the agent only where it matters.

Where exactly a person should step in once you have decided to keep one involved is covered in human in the loop for AI agents, and twelve worked cases are in human-in-the-loop AI examples. This piece is the step before both: deciding how much autonomy a job should get in the first place.

Four levels, not two

“Human in the loop or agentic” sounds like a switch. In practice there are four settings, and most teams use all of them at once for different jobs.

1. The person does the work and the AI assists: suggestions, drafts, summaries the person may ignore. Sometimes called AI in the loop; see AI in the loop vs human in the loop.
2. Human in the loop: the agent prepares each action and a person approves it before it happens.
3. Human on the loop: the agent acts on its own, a person watches the record, samples the results and can stop it.
4. Fully agentic within a boundary: the agent acts and nobody watches in real time. The boundary is its permissions, and the safety net is the record of what it did.

Anthropic’s own guidance on building agents↗ (opens in a new tab) describes agents as “systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks”, and notes that this autonomy means “higher costs, and the potential for compounding errors.” The same guidance says agents can “pause for human feedback at checkpoints or when encountering blockers.” Choosing a level is choosing where those checkpoints go.

The five questions

1. Reversibility

How easily is a wrong result undone, and by whom? Moving a card back, reverting a commit and restoring a soft-deleted record are cheap. An email to customers, a payment, a dropped column and a published price change are not. Reversibility is the strongest single signal, because it decides whether a mistake is an inconvenience or an incident.

2. Blast radius

If it goes wrong, what does it touch? One file on a branch, one team’s board, every customer, the company’s money? A change that is technically reversible but reaches ten thousand people before anyone reverts it has a large blast radius all the same.

3. Frequency

How often does the job come up? Frequency does not make work safer, but it decides whether per-item approval is sustainable. A person asked to approve forty routine actions a day will start approving without reading, and at that point the loop is still drawn on the diagram but no longer exists. Rare, weighty jobs can afford a person every time; frequent, small ones usually cannot.

4. Cost of error

What does a mistake cost in the time before somebody notices it? A wrong label on a bug costs a minute of someone’s confusion. A wrong figure in an invoice run costs money and trust. Count the cost of the error while it is live, not just the cost of fixing it.

5. Verifiability

Can the output be checked by something mechanical, such as a test suite, a type check, a schema or a row count, or only by a person’s judgement? Work a machine can check can run with less supervision, because the check does the supervising. Work only judgement can check, such as tone, strategy or whether a plan solves the right problem, needs a person somewhere. How to design that review so it holds up is in verifying AI-generated work.

A simple matrix

Put the two strongest questions on the axes, reversibility and verifiability, and use the other three to move a job one cell towards the person.

                   Easy to check              Hard to check
                   (tests, schema, diff)      (judgement only)

Easy to undo       Fully agentic              Agentic, person on the
                   within its permissions     loop: sample the results

Hard to undo       Agent prepares; a          Human in the loop:
                   threshold decides who      a person decides
                   presses the button         every time

Move one step towards the person if: blast radius is wide,
or an error is expensive while it is live.
Move one step away if: the job is frequent and low-stakes,
and per-item approval would be rubber-stamped.

Four jobs, scored

• Fixing lint errors on a branch: undone by a revert, checked by the linter and the tests, touches one branch, happens daily. Fully agentic.
• Filing bugs it notices while working: undone by a delete, checked by a person glancing at To Do, touches only the backlog, happens constantly. Agentic, with a person on the loop who triages weekly.
• Replying to a customer complaint: cannot be unsent, checked only by judgement, reaches a customer, happens often. Human in the loop, with the agent drafting.
• Renaming a column in the live database: hard to undo, partly checkable on a copy, touches every user. The agent writes and tests the script on a copy; a person runs it on live.

The middle ground: on the loop, and thresholds

Human on the loop is the setting most teams underuse. The agent does not wait for anyone, but everything it does is recorded under its name, a person reads that record on a schedule, and the person can stop it at once. It suits frequent, reversible work where per-item approval would be theatre. It only works if the record is kept by the tool rather than the agent, and if stopping is one action; an audit trail for AI agents covers the first half.

Approval thresholds are the other half. Instead of one level for the whole agent, you set a line: below it the agent acts, above it a person approves. Good thresholds are about what the action is, not how sure the agent says it is. Refunds under a set amount, edits on a branch, comments and new tasks go ahead; anything touching production, money, customers or access waits.

Claude Code expresses thresholds directly. Its permission rules↗ (opens in a new tab) have three lists, allow, ask and deny, evaluated in the order deny, then ask, then allow, and MCP tools are named mcp__<server>__<tool>. A project’s .claude/settings.json can let routine work run while making the rest wait for you:

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint *)",
      "mcp__fenbs__fenbs_comment",
      "mcp__fenbs__fenbs_create_item"
    ],
    "ask": [
      "Bash(git push *)",
      "mcp__fenbs__fenbs_update_item"
    ],
    "deny": [
      "Bash(npm publish *)"
    ]
  }
}

The documentation is explicit that these rules are enforced by Claude Code, not by the model: instructions in CLAUDE.md shape what it tries, while permission rules decide what it may do. That is the right place for a threshold, because a threshold that depends on the agent remembering it is a suggestion.

Setting the levels on a fenbs board

On fenbs the same choice is made with things the board already has, and the tool enforces it rather than the agent’s good intentions.

• Scopes set the outer level. An assistant connected with read and comment only is at level one or two: it can report and propose, and every change is a person’s. Add write and it can act.
• Moving between lanes is its own permission, separate from adding and editing tasks. Roles are defined per company, so a role that can add and edit but not move gives you agentic filing with a person deciding what reaches Completed.
• The test status is a threshold marker. An assistant that finishes something it cannot fully check sets it to Needs owner check, and those tasks stand out on the board for a person.
• History records every change with who made it, an assistant’s as “Claude via” the person it acts for. That is what makes human on the loop possible at all.
• Revoking an assistant’s token stops it at once without signing its person out, which is the stop button on-the-loop supervision depends on.