Blog · Agents
Human in the loop: designing approvals people do not skip
Human in the loop means an AI agent stops before a consequential action and a person decides whether it goes ahead. It only works if that person actually reads and thinks, so the real design problem is asking rarely, asking clearly and making a considered answer as easy as a careless one.
An approval that is clicked without reading protects nothing. It only moves the blame. This guide covers why approvals get skipped, how to choose what deserves one and how to design the step itself.
Why approvals get skipped
Anyone who has clicked "Accept all" on a cookie banner knows the pattern. Three things cause it.
Too many prompts. If an agent asks permission for every file it reads, the person learns within minutes that the answer is always yes. After that the hand moves before the eyes do. This is often called alert fatigue, and it is well known from fields where people work with many warnings. A system that raises frequent low-value alerts trains people to ignore all of them, including the one that matters.
Prompts that say nothing. "The agent wants to run a command. Allow?" gives the person nothing to judge. If a proper decision requires opening three other windows, most people will not do it.
Trust built on a good record. When an agent has been right many times in a row, checking feels like a waste. People relax, which is natural, and is sometimes called automation complacency. The rare error then arrives when attention is lowest.
None of these is a failing of character. They are predictable responses to poor design, so the fix is in the design.
Decide what deserves an approval
Not every action needs a person. A useful test has two questions: can it be undone, and does it reach beyond the agent's own working area?
| Kind of action | Examples | Sensible default |
|---|---|---|
| Reading and searching | Opening files, looking things up | Allow without asking |
| Changes inside a sandbox | Editing files on an isolated copy, writing a draft | Allow, review the result later |
| Changes to shared things that can be undone | Merging a branch, editing a shared note | Ask, showing the exact change |
| Actions that cannot be undone or that reach other people | Sending email, paying, deleting, publishing, installing software | Always ask, every time |
The more work you can move into the second row, the fewer prompts you need. An agent that works on a copy of a repository can edit freely, because nothing counts until a person merges. See why coding agents should work on a copy of your repo. An agent that prepares an email as a draft can write whatever it likes, because nothing leaves until a person sends.
This is the most effective single move: turn many small approvals into one meaningful review. Rather than approving forty edits one at a time, review one diff. Rather than approving each sentence, read one draft.
Design the prompt so it can be judged
When you do ask, the person should be able to decide from the prompt alone.
- Show the actual thing. The full email with its recipients. The diff. The exact command. The name, source and version of the package to be installed. Never a summary in place of the real content, because the summary is written by the same agent whose work is being checked.
- Say what will happen and whether it can be reversed. "This will send to four external addresses and cannot be recalled" is different from "this saves a draft".
- Put the risky details first. External recipients, deleted files and production systems should stand out, not sit on line thirty.
- Give the reason. One line on why the agent wants to do this, linked to the request that started it.
- Offer more than yes and no. "Edit first", "ask the agent to revise" and "reject with a reason" all produce better results than a bare refusal, and give the agent something to work with.
- Make no the safe default. Closing the window, timing out or pressing Enter by reflex should not count as approval.
Avoid the traps
Blanket "always allow". A remembered permission is sensible for narrow, harmless things such as running the test suite. It is dangerous for broad ones such as running any command. If you offer it, scope it tightly and make it easy to see and withdraw.
Approval by the wrong person. The approver should be someone with the authority and the context to judge. In shared spaces that is usually the owner of the agent or the owner of the thing being changed. See when agents owned by different people work in one room.
Bundles that hide things. Batching is good, but a batch of fifty items where one is unlike the rest is a trap. Group similar things and pull the unusual item out so it is seen.
Rejections that do not stick. If a person rejects something and the agent proposes it again an hour later, people give up. A rejection should be remembered, with its reason.
Urgency. Anything that pushes for a fast answer, such as countdowns or repeated reminders, lowers the quality of the decision. If a decision can wait, let it wait in a queue.
Keep a record
Every approval and rejection should be logged: what was proposed, the exact content at the time, who decided, and when. This has three uses. It lets you trace a problem back afterwards. It shows patterns, such as an approval that is accepted every time without changes, which may be safe to automate, or one that is rejected often, which points to an agent that needs better instructions. And it makes accountability real, because a named person decided on the basis of specific content.
Check that it is working
A few signs are worth watching. If approvals are nearly always granted within a second or two, people are not reading. If nothing is ever rejected or edited, either the agent is perfect or the review is a formality, and the first is unlikely. If people complain about the number of prompts, believe them and cut the number, rather than asking them to pay more attention. Attention is limited, and good design spends it only where it counts.
Where Prism fits
Prism Desktop is built on the rule that a person decides. Agents propose; people approve a finding, a merge, an email or an install, and decisions are recorded. Coding sessions run on an isolated copy of the repo, so you review one diff and you merge. Every mail send is prepared first and then confirmed by a person, and agents propose edits to your notes for you to approve. The Store adds a consent step before any install. See the security page for more.