Hey everyone,
I’ve been exploring a pattern for controlling expensive or sensitive tool calls in n8n AI workflows.
The flow is:
AI Agent
→ Call n8n Workflow Tool
→ Shared Guard Sub-workflow
→ decision check
→ allow / deny
→ optional human review
→ costly tool/API call
I put together an importable example with two versions:
-
Native n8n guard pattern
A Guard Sub-workflow with a mock Code node for budget/repetition logic.
-
ProceedGate-powered guard pattern
The same Guard Sub-workflow, but the mock Code node is replaced by an HTTP Request to /v1/check, then routed on allowed.
The goal is not to replace n8n. n8n still handles orchestration, approval, and workflow UX. The external guard only handles the shared decision/check before costly tools run.
Possible use cases:
-
OpenAI / LLM calls
-
SerpAPI / Firecrawl / Apify
-
CRM or SAP API calls
-
email/outbound automation
-
repeated tool calls from agents
I added free workspace keys with 5,000 checks/month so people can test the pattern without a card.
Guide + workflow JSONs:
https://proceedgate.dev/n8n.html
I’m mainly looking for feedback from n8n users:
-
Is the import/setup flow clear?
-
Does the Guard Sub-workflow pattern feel natural?
-
Would you keep this as an HTTP Request/template pattern, or would a community node eventually make more sense?
Still treating this as an early pattern/template, not a polished n8n node.
The Guard Sub-workflow pattern feels natural for n8n — reusing it across multiple agents as a shared callable is exactly how sub-workflows are meant to be used.
On the “template vs community node” question: keeping it as a workflow template is probably the right call for now. A node would lock in the interface before the pattern is fully settled, and a template is much easier for people to fork and adapt to their own budget/approval logic.
One thing worth considering: the optional human review step — are you using n8n’s Wait node with a webhook resume for that, or routing to an external approval tool? That’s often where these patterns get complicated in practice.
That’s super helpful, thank you.
I agree — starting as a workflow template feels like the right move for now. A dedicated node would probably be too early until the pattern is tested in more real workflows.
The human review point is a good one. I haven’t fully settled that part yet.
My current thinking is to keep the first version as native to n8n as possible: if ProceedGate returns a “review/warn” type decision, the workflow should route into n8n’s own Wait / approval-style step before the expensive or sensitive tool runs.
Later, if people need approvals across multiple workflows or teams, then maybe an external approval layer makes sense. But for the first template, I think staying close to native n8n is probably cleaner.
Do you think the example should include a concrete Wait-node review path from the start, or keep it simpler with just allow/deny first?
I’d start with just allow/deny - it makes the core pattern easier to understand and import. The Wait-node review path adds meaningful complexity (resume URL handling, timeout logic) and people who need it usually already know they need it. Better to have a clean v1 that works, then document the human-review extension as a separate step or a second template variant.
That makes sense — thanks, this is a good point.
I’ll keep the first template focused on just allow/deny so the core pattern stays easy to understand and import.
The Wait-node / human review path probably deserves to be a separate follow-up template once the basic version is tested by a few people. That way the first example stays clean, and the more advanced review flow can handle resume URLs, timeouts, and approval logic properly instead of making the starter template harder to use.
Appreciate the clarity — this helps me avoid overcomplicating the first version.
I like the sub-workflow approach for this. It feels more natural in n8n than making it a custom node too early, because people can inspect and adjust the logic for their own budget/risk rules.
Human review is useful, but adding Wait nodes, resume URLs, timeouts, and approval routing might make the starter version harder to understand.
A clean v1 plus a second “with review step” template later feels easier for people to adopt.
1 Like