Human in the Loop AI Agents: Where the Person Actually Sits

Search “human in the loop ai agents” and the first page agrees with itself. There are three models, in the loop, on the loop, and out of the loop. You should gate the consequential actions and let the rest run. Too many gates cause approval fatigue, so be selective. Log everything.

All of it is right, and none of it is usable on Monday. The pages stop where an engineering manager starts: which actions, exactly, wait for a person; who that person is, by name; what they read before they click; what record the click leaves; and how an action ever stops needing the click. This post answers those five questions for agents doing software work, with a YAGNI Team as the worked example.

What does human in the loop mean for an AI agent?

A human in the loop AI agent is one that stops before an act with consequences and waits for a person to say yes. The person sits between the agent’s decision and the world: the agent proposes, the person approves, then it happens. That is the whole definition, and the rest of the vocabulary hangs off it.

On the loop is the weaker cousin: the agent acts, and a person reviews afterwards with the option to reverse. For reversible work that is fine. For a merge to main, a deploy, or a data migration, review afterwards is a post-mortem, not oversight.

One disambiguation the glossaries blur. “Human in the loop” also names a training-time practice: people labeling data and ranking outputs before a model ships. That is a different loop. This post is about the runtime one, where an agent is doing work on your team today. The question is not whether to keep a person in it. Everyone says yes. The question is where, exactly, and the answer has to be specific enough to configure.

Which actions should wait for a person?

Decide by the consequence of the act, not by the confidence of the agent. An agent’s confidence is a number it reports about itself; the consequence of an act is a fact about the world. Sort the acts an agent can take on a software team by whether you can take them back.

Act	Reversible?	On a YAGNI Team
Propose the next ticket from the backlog	Yes, it is a proposal	Bailey proposes; a proposal always waits for a person
Write a plan for an accepted ticket	Yes, it is a document	Reeve plans; the plan line is supervised by default
Build the plan to a draft pull request	Yes, a draft in a sandbox	Wright builds; the build line is supervised by default
Post a code review	Yes, it is advice	Proctor reviews; autonomous by default
Boot the app and walk the change in a browser	Yes, evidence only	Fletcher (beta) tests; off until the environment is ready
Post what shipped to Slack	Yes, it is a report	Harper posts on its Rhythm
Merge to main	No	Never a line. Always a person’s click
Deploy, migrate data	No	Capped at supervised, permanently

Two things fall out of the table. Most of what an agent does on a ticket is reversible, so most of it should run with a record rather than a question. And the acts that are not reversible are few, the same few on every team, and sit at the stage boundaries rather than inside the work.

On a YAGNI Team a supervised ticket takes three human clicks: accept the proposal, approve the plan, merge. Everything between those clicks, the planning, the build, the review, the test walk, leaves a Receipt on the record and asks nothing. Autonomous coding agents covers the build half of that in detail; the rest of this post is about the clicks.

Who is the person, by name?

The ranking pages say “a human reviewer”, “a person with the right role”, or “route it to a Slack channel”. That is where human in the loop quietly fails. A gate addressed to a channel is addressed to nobody, so nobody answers it, or whoever is nearest does, and the record then shows an approval from someone who did not own the decision.

On a YAGNI Team every supervised line names its supervisor. The Team reports to exactly one accountable person, its owner, who is the default supervisor for every supervised line; a line can name someone else. The gate reads the same way everywhere it renders, on the ticket’s case file and in the Slack message: “supervised by Priya”. Any other member of the Team may still answer, and the record says who did. A gate left open for more than a day reminds its addressee daily.

This is the frame behind the story every engineering leader read this spring. The Financial Times reported that Amazon’s retail group would require senior engineers to sign off on AI-assisted changes after a run of outages, and Amazon disputed the framing. What Amazon mandating AI code review means for your team walks the sources. The lasting point is that a named senior person signing off on a change is the right shape, and it fails as a bare rule when the signer has nothing readable in front of them. Which is the next question.

What does the person see before they click?

The cost of human in the loop is the reading, not the click. If the approver has to reconstruct what the agent did from a diff and a chat transcript, the gate takes an hour and gets skipped. If the approver has a short document written for the decision, the gate takes minutes and gets read. Each of the three clicks on a YAGNI Team has a document designed for it.

Accept the proposal. Bailey reads the Team’s backlog in Jira or Linear, ranks what is ready, and proposes the next ticket as a spec: what it is, why now, and the evidence from the tracker. The person’s verbs are “Start plan” and “Doesn’t need work”. Bailey never starts anything on its own.

Approve the plan. Reeve plans the accepted ticket, and before the gate opens the plan’s own check runs it in rounds against five questions: half-measures, extra complexity, reach beyond scope, observability, and whether the failure cases are covered. The case file shows the rounds closed above the plan, so the person reads a plan that has already been argued with. The verbs are “Approve plan” and “Send back”. A plan whose own check asked for changes never builds on its own.

Merge. By the time the pull request is ready, Proctor has posted one review with a verdict, and the findings it set aside sit behind it with their reasons. If Fletcher’s line is on, its browser walk is attached with video and screenshots. The person reads the review, the evidence, and the diff, and merges on GitHub. Proctor’s approving verdict marks the draft ready; it does not merge, and nothing does except a person.

The pattern is the same at all three: the Agent that did the work writes the thing the person reads, and the decision is one of two verbs. That is what makes the gate affordable, and an affordable gate keeps getting used.

How does a line move from supervised to autonomous?

This is the question none of the ranking pages answers, and the one a manager asks in the second week. The Ladder on a YAGNI Team has two rungs, set per line of work, not per Agent and not per Team.

Supervised: the act is minted as a gate, pre-filled and addressed to a named member of the Team, and one click that is still that person’s dispatches it.

Autonomous: the act dispatches with a Receipt, capped per item where a loop is possible.

A person moves a line from supervised to autonomous with one explicit act, with the track record beside it: how many times this line ran, how many were sent back, how many were reversed. Nothing moves a rung on its own. There is no suggestion engine, and no error-rate threshold that graduates a line when it dips under five percent. One ranking guide proposes exactly that threshold (Pickaxe, as of October 2026), and it is the wrong lever: a line that has run clean forty times has earned a person’s decision, not a formula’s. The decision is a person’s, made once, recorded, and visible.

There is no demotion rung either. A line that misfires after it went autonomous is not sent back to a training tier; the reversal is one more count on its record, and the person who owns the line reads it and decides. And there is a permanent floor: irreversible and high-blast acts stay supervised at every level, deploy and data-migration capabilities cap at supervised, and merge is not a capability at all. There is no merge line.

The defaults on a new Team say where the floor sits in practice.

Line	Default rung	Why
Bailey proposes from the backlog	A proposal always waits	A proposal is an ask; accepting it is the first click
Reeve plans	Supervised	Approving the plan is the second click, and the cheapest place to catch a wrong direction
Wright builds	Supervised	A build spends real compute and opens a pull request; most Teams move this line up first
Proctor reviews	Autonomous	A review is advice, posted on GitHub; it cannot merge anything
Fletcher (beta) tests	Off	Stays off until the repository environment boots clean
Harper posts the Daily Brief	On its Rhythm	A report; it changes nothing
Merge	Not a line	A person’s click, always

Managing AI coding agents covers the Ladder from the manager’s side, including what should never be auto-approved no matter the track record.

What record does each click leave?

The clicks are only worth making if they leave a record someone can read later. The ranking pages say “log everything” and stop. On a YAGNI Team the record is the ticket’s case file, which holds:

• The proposal Bailey wrote and who accepted it.
• The plan Reeve wrote, the check rounds it went through, and who approved it.
• Every run Wright made, in which sandbox, and what each cost.
• The draft pull request, Proctor’s review with its verdict, and the findings it discarded with their reasons.
• Fletcher’s test plan, video, screenshots, and verdict, when its line is on.
• Each click a person made, by name, and when.
• What the ticket cost, per Agent, on the one rate card the Team shares with YAGNI Code developers.

Done is written only when the source says so: the merge webhook from GitHub, the ticket closed in Jira or Linear. That proof from the source is a Receipt. Shipped is not Done; the Receipt is.

Two more records sit beside the case file. The Decisions ledger holds the product-intent calls people make as the work happens, which every Agent reads before it guesses; a correction made during review lands there or in the Team’s Playbook as a rule. And Harper’s Daily Brief posts to Slack each morning: what shipped, what is in flight, and what needs a person, with the receipts attached.

What does one ticket look like with a person in the loop?

A Team owns a checkout service. Its backlog is a Linear project. Priya, the engineering manager, owns the Team; the plan and build lines are supervised by her, Proctor’s review line is autonomous, and Fletcher is on.

Stage	What the Agent did	What Priya did	What the record shows
Proposed	Bailey ranked the Linear backlog and proposed “reject a discount code after its end date, with a message”, citing the open ticket and two support threads	Read the proposal, clicked Start plan	The proposal, the evidence, the click, 9:14
Plan	Reeve wrote the plan; the check ran three rounds and tightened the failure cases (timezone at the boundary, a code with no end date)	Read a plan already argued with, clicked Approve plan	The plan, three rounds above it, the click, 9:31
Build	Wright built it in a sandbox and opened a draft pull request	Nothing	Two runs, their cost, the pull request
Review	Proctor posted one review, approving, with one finding set aside and why; the verdict marked the pull request ready	Nothing	The review
QA	Fletcher booted the environment at the commit, walked the discount form with a live code, an expired code, and one expiring at midnight; attached the video	Nothing	The test plan, the video, a pass
Done	Nothing. The GitHub webhook moved the ticket to Done and the Linear ticket closed	Read the review and the video, merged on GitHub at 14:02	The merge Receipt, the ticket closed at the tracker, the cost per Agent

Three clicks, each in front of a document written for it. Priya read a one-page proposal, a plan she did not have to write, and a review she did not have to reconstruct from the diff. Harper’s Daily Brief named the pull request the next morning. The agentic software development lifecycle walks the six stages in full.

How do you keep the person in the loop without approval fatigue?

Approval fatigue is real, and it comes from gating steps instead of acts. A reviewer asked to approve each tool call, each file edit, each commit, stops reading by the tenth one, and from then on the gate is theater with a timestamp. The fixes are structural:

1. Gate acts, not steps. Three clicks per ticket, at the boundaries where direction changes, not thirty inside the build.
2. Write for the click. A proposal, a plan, a review, each a short document the approver reads once. One review with a verdict beats thirty inline comments.
3. Make reversible work autonomous on purpose. Proctor’s review line ships autonomous because a review cannot merge anything. Move Wright’s build line up when its record earns it. Keep the floor.
4. Never approve on timeout. A gate that passes when nobody answers is not a gate. On a YAGNI Team an open gate reminds its addressee daily and waits.
5. Let corrections compound. A send-back that becomes a Playbook rule or a Decisions entry is a gate that will not need the same click next time.

None of this removes the person. A YAGNI Team carries work you would otherwise staff for, under a person who approves the plan and merges. That is the point of the loop, not a cost of it.

So where does the person sit?

At three places on every supervised ticket: accepting the proposal, approving the plan, and merging. Each click has a document written for it and leaves a record with a name on it. A line moves to autonomous only when a person moves it, with the track record beside the move, and the acts you cannot take back, merges, deploys, migrations, never leave a person at all.

YAGNI runs agent teams, managed like your engineering team: Bailey proposes, Reeve plans, Wright builds to a draft pull request, Proctor reviews, Fletcher (beta) tests in a browser, and Harper reports to Slack, with every gate addressed to a named person and merge always a person’s click. See how Agent Teams work, or book 30 minutes to put a Team on one of your repositories with the lines set the way you want them. The guide to AI agents for software development puts the three clicks and the Ladder inside the whole Team.