Most AI agent demos end at the moment the agent decides to do something: send the email, refund the order, update the CRM record. In a real business, that moment is where the engineering starts. The question a client asks us most often after "can it do this?" is "what stops it doing the wrong thing?"
This post is the pattern we use when we build agents for small and mid-sized businesses in the USA, UK, Canada and Australia: sort every tool the agent can call by risk, and put a person in front of the risky ones. The examples use n8n because it has human review built into its AI agent tooling, but the design works in any framework.
Step 1: list every tool and give it a risk level
An agent is only as dangerous as the tools you give it. Before writing a prompt, write a table:
| Tool | What it changes | Who sees the result | Can it be undone? | Risk |
|---|---|---|---|---|
| search_orders | nothing | the agent | n/a | low |
| draft_reply | nothing until sent | staff | yes | low |
| send_email | the customer's inbox | the customer | no | high |
| update_crm_stage | one record | sales team | yes | medium |
| issue_refund | money | the customer | partly | high |
| delete_contact | one record | everyone | no | high |
Three questions decide the level: does it leave the building (a customer, a supplier, a regulator)? Does it move money? Can it be undone in one click? Any "yes" puts the tool in the high column.
Read-only tools (search, look up, summarise) can usually run freely. Tools that write internal data can run with logging. Tools that send, pay or delete wait for a person.
Step 2: make the agent propose, not perform
For high-risk tools, the agent's job changes from "do it" to "prepare it". The tool call becomes a proposal with everything a reviewer needs on one screen:
{
"action": "issue_refund",
"order_id": "10482",
"amount": "the full order total",
"reason_from_customer": "Item arrived damaged, photo attached",
"agent_reasoning": "Policy allows a refund for damage reported within 14 days; reported on day 3",
"source_documents": ["refund-policy.md#damaged-items"]
}
Two fields matter more than they look. agent_reasoning lets the reviewer check the logic, not just the output. source_documents points at the policy the agent relied on, which is how you catch an agent that has misread a rule.
Step 3: put the approval where people already work
An approval step nobody sees is a queue that never empties. Send it to the place the team already watches: a Slack or Teams channel, an email, or a simple internal form.
In n8n, there are two ways to do this:
- Human review on agent tools. n8n's documentation describes a human-in-the-loop option for AI agent tools: you can require a person to approve a tool call before it runs. This is the cleanest option, because the gate sits on the tool itself rather than in your prompt.
- Send-and-wait steps. Several n8n messaging nodes can send a message and pause the workflow until someone responds. That suits approvals outside the agent loop, such as a weekly batch of proposed CRM updates.
Whichever you use, the gate must live in the workflow, not in the system prompt. "Always ask before sending emails" in a prompt is a request; an approval node is a control.
Step 4: decide what happens on "no" and on silence
Every approval has three outcomes, and teams usually design only one:
- Approved: the tool runs with exactly the proposed values. Don't let the agent regenerate the action after approval; run what the person saw.
- Rejected: record the reason and return it to the agent or to a person. A rejection reason is the best training data you will get for improving prompts and policies.
- No answer: set a timeout. After it, escalate to a second person or close the request with a holding reply. Never default to "approved".
Step 5: log every step
For each agent run, keep: the user's request, the tools called with their inputs, the proposals made, who approved or rejected them and when, and the final result. n8n's execution history covers part of this; for anything customer-facing, also write a row to your own log table so the record outlives the tool's retention settings.
The log is what turns "the AI did something odd" into a ten-minute investigation instead of a guess.
Step 6: loosen the gate with evidence, not optimism
Approval steps cost staff time, so teams want to remove them. Do it with numbers. After a few weeks, look at each high-risk tool: how many proposals were approved unchanged? If a tool's proposals are almost always approved as-is, consider moving it to medium risk with a value limit (for example, refunds under a set amount run automatically and are reviewed afterwards). If people keep editing or rejecting them, the agent needs better instructions or better data, not more freedom.
A minimal checklist
- Every tool has a risk level written down.
- High-risk tools produce a proposal with reasoning and sources.
- Approval happens in a channel people already watch.
- Approved actions run with the exact values shown.
- Rejections and timeouts are handled, and silence never means yes.
- Every run is logged outside the agent framework.
- Gates are relaxed only from approval data.
We build agents this way for clients at Dzimark, and the AI agent development page shows the kinds of customer service, sales and operations agents we put these guardrails around.
FAQ
Doesn't human approval defeat the point of an agent?
No. The agent still does the reading, looking up and drafting, which is most of the time spent. The person spends seconds checking a prepared action instead of minutes doing the task.
Can I enforce approval in the prompt instead?
Not reliably. Prompts guide behaviour; they don't block it. Put the gate in the workflow or the tool layer.
Which tools should never run without a person?
Anything that sends a message to a customer, moves money, or deletes data, at least until you have weeks of approval history showing the agent gets it right.
Does this work outside n8n?
Yes. In code-first frameworks the same idea is a tool wrapper that returns "pending approval" and resumes when a person responds.
Background reading on the Dzimark blog: AI chatbot vs AI agent.
Top comments (2)
This is the framing small businesses actually need — not “can it do this?” but “what stops it doing the wrong thing?” The part about silence never meaning yes is the one I’d underline twice. In a property or service business, an unanswered approval for a refund, a tenant message, or a record deletion can’t just sit there and then go ahead by default.
I also like approving the exact proposed values, not letting the agent regenerate the action after approval, and treating rejection reasons as training data. That’s how the guardrail gets smarter instead of just slower. The risk table up front is a good discipline too — it forces you to decide, before you automate anything, what actually leaves the building.
the prompt is a request; the workflow gate is the control. do you treat reviewer edits as a new proposal that needs a second approval?