--- canonical: "https://websyi.com/blog/human-approval-in-ai-systems/" doc_version: "1.0" last_updated: "2026-09-19" title: "Where a human should approve before AI acts" description: "Most AI systems do not fail because the model is wrong. They fail because something went out under your name that nobody checked first." date: "2026-09-19" tags: [human approval, AI agents] service: "custom-ai-agents" --- Every automated system eventually reaches a point where it either sends something, changes something, or commits you to something. That moment is the one worth designing carefully, and it is usually the one that gets the least attention. The question is not whether to put a person in the loop. It is exactly where to put them, because an approval step in the wrong place is almost as bad as no approval at all. Put it everywhere and the system saves nobody any time. Put it nowhere and you find out about the problem from a customer. ## The test for whether a step needs approval One question settles most cases. If this action is wrong, who finds out, and how hard is it to undo? An internal summary that is slightly off gets corrected by the person reading it, in seconds, with no consequence. A quote sent to a client with the wrong figure in it is a phone call, a correction, and a small dent in how organised you look. Those two things do not deserve the same treatment. So sort your actions by blast radius rather than by how clever they are. Anything that only a colleague sees can usually run unattended. Anything a customer sees, anything that commits you to a price or a date, and anything touching money, contracts, or personal data should wait for a person. The useful side effect is that most steps turn out to be internal. The approval layer ends up smaller than people expect, which is what keeps the system worth having. ## Approve the output, not the process A common mistake is putting the checkpoint too early. Someone is asked to confirm that a workflow should run, before anything has been produced. They have no information to judge with, so they click yes every time, and within a week the approval is a reflex rather than a decision. Move the checkpoint to the end. Let the system do the work, produce the actual message or record, and present that finished thing for a yes or no. Now the person is reviewing something concrete and can catch the specific problem rather than approving an abstraction. This also makes the step fast. Reading a prepared email and pressing send takes a few seconds. Writing it took minutes. That gap is the entire value of the system, and it survives the approval step intact. ## What a good approval step looks like The reviewer needs enough context to decide without going to look anything up. In practice that means the draft itself, what triggered it, which record it relates to, and what happens next if they approve. It also needs a real second option. If the only button is approve, it is not an approval step. There should be a way to edit before sending, and a way to reject that puts the item somewhere a person will deal with it rather than dropping it silently. Two more things matter in the long run: 1. A record of who approved what and when, so a disputed message can be traced later. 2. A defined behaviour when nobody responds. Anything awaiting approval should either wait indefinitely and visibly, or escalate to a named person. It should never quietly time out and send itself, and it should never vanish. That last point is where otherwise careful systems go wrong. The approval logic is sound and the queue is fine, but nobody decided what happens at six in the evening when the approver has gone home. ## Decide the line while you are designing, not after Retrofitting approval into a running system is painful, because by then the workflow assumes it can act freely and the steps are not separated in a way that lets you insert a pause. Deciding early is cheap. When the workflow is being mapped, mark every step where something leaves the business or changes a customer-facing record. Those marks are your approval points, and the rest of the design gets built around them. It is also the right time to ask who the approver actually is. A step assigned to the whole team belongs to nobody. Name a person and a fallback, and make sure both of them know the queue exists. ## The part worth keeping Automation is meant to remove the repetitive work, not the judgement. A system that drafts, gathers, sorts, and prepares gives your team back the time they were spending on mechanics. The decision about what is good enough to send stays with the person whose name is on it. If you are working out where that line belongs in your own process, [send the project context](/contact/#form) with a description of what your system would be sending or changing. Websyi will map the workflow and mark the approval points before building anything. ## Sitemap See the full [sitemap](https://websyi.com/sitemap.md) for all pages.