Human in the loop for AI agents: where people should step in

Human in the loop, for AI agents, means a person takes part in the decisions that matter rather than approving every step or none. In practice there are three points where a person should step in: before an action that is hard or impossible to undo, when an agent says its work is finished, and when the scope of the job changes. Reading, searching, drafting, filing and reporting progress can run without anyone watching, as long as it is all recorded under the agent’s name. On a task board you build those three points out of lanes, permissions and a simple habit: the agent proposes in a comment, and a person makes the move.

What human in the loop means

IBM defines human in the loop↗ (opens in a new tab) as “a system or process in which a human actively participates in the operation, supervision or decision-making of an automated system.” The key word is actively. A person who clicks Approve on a hundred prompts a day without reading them is present, not participating.

The idea is written into the protocols agents use. The MCP specification↗ (opens in a new tab), which is how assistants such as Claude and Cursor call tools, says that for trust, safety and security there should always be a human in the loop with the ability to deny tool invocations, and that clients should ask for confirmation on sensitive operations. It leaves where and how to the application, which is the question this piece answers for a task board.

Regulation points the same way. Article 14 of the EU AI Act↗ (opens in a new tab) requires high-risk AI systems to be designed so that they can be effectively overseen by people while in use, including being able to decide not to use a system’s output, to override or reverse it, and to interrupt the system with a stop button or a similar procedure. It applies to systems classed as high-risk, not to every coding assistant, but its list is a good test for any setup: can a person understand what the agent did, overrule it, and stop it?

Point one: before anything hard to undo

The first question about any action is what it costs to reverse. Moving a card back is one click. Deleting a production table, emailing every customer, paying an invoice or deploying to a live site is not. The rule is simple: an agent may prepare an irreversible action as far as it likes, and a person pulls the trigger.

• Needs a person: deploying to production, running a database migration, sending anything to customers, spending money, deleting data outside a soft delete, changing who has access.
• Can run: anything the tool records and can reverse, such as creating a task, commenting, writing a plan, moving a card into In Progress, or a soft delete that keeps the number and history.

On a board, the irreversible step belongs on a card of its own, so the approval is visible. “Run the pricing migration on live” is a task a person moves to In Progress; the agent prepared and tested the script under a different card.

Point two: when the agent says it is finished

An agent’s “done” is a claim, and agents make it with the same confidence whether it is right or not. A person should read the evidence before work counts as finished: what changed, the commit, how it was checked. That review is also the cheapest place to catch a misunderstanding, before it is built on.

This is where automation bias creeps in: the more often an agent is right, the less carefully its work gets read. Article 14 names it as something overseers must be kept aware of. The defence is to make the evidence quick to check, a test name that passed, a screenshot, a one-line summary, so reading it properly takes a minute rather than an hour.

Point three: when the job changes

Agents discover things. The bug turns out to be a design flaw; the small enhancement needs a schema change; the feature conflicts with another one. At that point the agent is no longer doing what it was asked, and continuing is a decision about priorities that a person should make.

The practical rule: the agent may rewrite its plan as it learns, but if the problem itself has changed, it stops, comments what it found, and waits. On fenbs every task keeps the Problem, what was reported, separate from the Plan, how it will be done, so “the plan grew” and “the problem is different” are visibly different things. A new problem becomes a new task, filed in To Do, linked to the original with relatesTo.

What to automate fully

Everything else, provided it is recorded. Putting a person in front of low-risk, reversible work does not add safety; it adds a queue, and a queue of approvals is the fastest way to teach people to approve without reading.

• Reading the board, searching, summarising what changed this week.
• Filing what it notices into To Do, after searching for an existing task.
• Writing and rewriting the plan on a task it has been given.
• Commenting progress, findings and refusals it met.
• Keeping AI context notes current, signed with its name.

Building the loop on a board

The three points map onto a board without adding anything to it. On fenbs there are four fixed lanes and no approval workflow to configure, so the loop is made from things that already exist.

Lanes as gates

Next Up is a person’s decision: agents file into To Do and take work only from Next Up, so nothing is worked on that a person did not choose. Completed is a person’s decision too: the agent leaves finished work in In Progress with its evidence, and a person moves it on.

Comment, then move

For anything at one of the three points, the agent writes what it would do as a comment and stops. “Migration script ready and tested on dev; run it on live?” A person reads and acts. Moving cards between lanes is its own permission on fenbs, separate from editing, so an agent can be allowed to write and comment without being able to move anything at all. To draw attention to a card that is waiting, an agent can flag it for everyone with fenbs_flag_item, where the board allows.

Read-only for the first week

Connect a new agent with read and comment scopes only. For a week it can do nothing but report what it would do, and you act on the reports. If every comment is one you would have acted on, add write. The week tells you where it needs a person and where it does not, which no amount of guessing in advance will. How to keep an AI agent from wrecking your board goes through that first week in more detail.

## When to stop and ask
- Before anything that cannot be undone (deploy, migration, email to
  customers, payment, deleting data): comment the exact step and stop.
- When finished: comment what changed, the commit and how you checked it.
  Leave it In Progress. A person moves it to Completed.
- If the problem is not what the task says: comment what you found,
  file the new problem in To Do with relatesTo, and stop.
- Everything else: go ahead.

Oversight after the fact

A loop is not only approvals in advance. It is also being able to see what happened and to stop it. On fenbs every change is recorded with who made it, an assistant’s as “Claude via” the person it acts for, so a week of agent work can be read as a list; an audit trail for AI agents explains what that record contains. And revoking an agent’s token stops it at once without signing anyone out, which is the board’s version of a stop button.