Add AI tool middleware for Human-in-the-loop approvals. A step btween the AI Agent node and the tool, for human approval.
My use case:
My agent has a “send email tool” which it can trigger by request. But before the actual sending, I would like to approve the content. Currently i’m doing it by trigger another workflow and add human-in-the-loop component before the mail, but it has many drawbacks - the workflow input should be manually match and propogate the gmail input, it is handled in another workflow which increase maintanance, and it missing some original workflow context that need to be forward by workflow input.
I think it would be beneficial to add this because:
AI agnet that has access to sensetive tools (like sending emails) may benefit for human approval before being sent.
Starting strong with a smart suggestion: having humans approve actions remains key when AI deals with delicate work such as email. What you describe shows clearly how built-in middleware could help - keeping context intact matters, also making workflows easier to handle improves outcomes. Crucial details stay protected that way.
Recently, I started refining AI-written emails using a tool found at How Does an AI Humanizer Actually Work? before sending them for review. Instead of sounding stiff, the output feels more like something a person would actually write. With just one quick pass, the tone becomes smoother, clearer. Because of this tweak in my process, fewer messages get sent back for changes. Best part? It doesn’t cost anything, integrates without issues. If you’re dealing with machine-generated text regularly, giving this method a try might save time down the line.
This is the right shape of problem. I would separate it into two layers:
1. approval routing: who needs to approve this tool call before it runs
2. action receipt: what exactly was approved, what actually executed, and what evidence proves it
For a sensitive tool like send email, the approval step should not just be “approve/deny.” It should preserve a small signed payload:
- original user request
- proposed tool name
- recipient / target system
- exact email body or payload hash
- policy verdict
- approver identity
- execution result
- provider message id or other evidence
That avoids the main problem you called out: once approval happens in a separate workflow, context gets manually copied around and the audit trail becomes fragile.
The middleware abstraction I would want is:
`agent proposes tool call → middleware classifies risk → human approves exact payload if needed → tool executes → receipt is written back to the run`
If you were designing this as middleware, I would start by defining the receipt schema first, then wiring the approval UI around that schema. The useful test case is one tool call that sends or changes something outside n8n, because that is where the missing context matters most.