The idea is:
Add a “Max Tool Interactions” (or max_iterations) parameter to the AI Agent nodes. This setting would allow users to define a hard limit on how many times the agent can call tools during a single execution. Once the limit is reached, the agent should either return the information it has gathered so far or trigger an error, stopping the process immediately.
My use case:
I use n8n to automate complex workflows where agents have access to multiple tools (search, database queries, and custom APIs). Occasionally, if a tool returns an unexpected result or if the agent gets “confused” by conflicting instructions, it enters an infinite loop—calling the same tools repeatedly. This results in unnecessary latency and, more importantly, massive consumption of LLM tokens in a very short period.
I think it would be beneficial to add this because:
- Cost Control: It prevents “token bleeding” caused by logical loops that the agent cannot break on its own.
- Predictability: It ensures that a workflow won’t run for minutes trying to solve an unresolvable task.
- Alignment with Industry Standards: Most AI orchestration frameworks (like LangChain or CrewAI) already implement a
max_iterations safety net by default.
- Debugging: It makes it easier to identify when an agent is failing to reach a conclusion within a reasonable number of steps.
Any resources to support this?
Since n8n’s AI nodes are heavily based on LangChain, this feature is likely already supported in the underlying library via the max_iterations parameter in the AgentExecutor.
Are you willing to work on this?
I am willing to help with testing and providing detailed feedback on the implementation, but I would prefer a core contributor or someone more familiar with the n8n node architecture to handle the integration.
Hi @leonardo-turque : interesting idea.
As I understand it, n8n already has a Max Iterations setting on the AI Agent node, so the main gap here may be less about iterations in general and more about putting a stricter cap on tool interactions specifically. That feels useful if the agent gets stuck in a loop or keeps calling tools too many times.
I also think a system prompt can help guide the agent’s behavior, but that is still guidance rather than hard enforcement. So for loop prevention, a runtime guardrail would be the safer protection.
Nice feature request; I can see why this would matter for production workflows.
Don’t forget to vote for your own request too 
I would have voted as well, but I already reached my current vote limit.
1 Like
This is a strong feature request.
One distinction I’m trying to understand: would a “Max Tool Interactions” setting be enough for most production workflows, or would you also want a reusable pre-call guard before expensive tools?
For example: before OpenAI, Replicate, SerpAPI, Firecrawl, Apify, CRM, or internal API calls — check whether the same task/tool is repeating too much or crossing a budget threshold, then block before the paid call runs.
I’m asking because recursion/max-iteration limits catch loops, but they don’t always protect against a few expensive tool calls happening before the loop is obvious.
1 Like
Hi @Doru_Gradinaru
For cost sensitive tools, I think a planning layer is important so the agent knows when to call a tool and when to stop. Max Iterations is still useful as the fallback ceiling, but by itself it is more of a safety net than a real budget or precall guard.
1 Like
Yeah, that makes sense.
Max interactions feels like a good emergency brake, but probably not enough for tools that cost money every time they run.
I guess the tricky part is deciding where that guard should live.
Would you see this more as a setting inside the AI Agent node, or as a separate node you put before expensive tools like OpenAI, SerpAPI, Firecrawl, Apify, etc.?
1 Like
Hi @Doru_Gradinaru 
I think the cleanest design is a hybrid one.
For me, the main pieces are:
-
Max Iterations in the AI Agent as the emergency brake: since n8n already uses it as the limit on how many times the model can run to try to produce a good answer.
-
Session-aware memory - state: because n8n memory keeps chat history for the current session, and if you are not using the Chat Trigger you manage sessionId manually.
-
Human review or “programmatic limits” for sensitive or costly tools: because n8n already supports pausing the workflow before a tool runs and waiting for approval. Alternatively, an IF node can be used right before a tool specifically as a budget counter to prevent runaway API costs.
-
A planner first layer for harder or more expensive jobs: since n8n’s Plan and Execute Agent first creates a high- evel plan and then executes it step by step.
-
A ReWOO style pattern as inspiration: because ReWOO separates reasoning from tool observations and is specifically designed to reduce repeated prompts and tool churn.
So; prompt alone is not enough, and an IF or Switch step by itself should not be the main control layer unless it’s specifically acting as a programmatic budget counter before a costly API.
I would treat the (1) prompt as guidance, the (2) memory session as state, the planner as the control layer, (3) human review- budget checks for critical tools, and (4) Max Iterations as the final safety ceiling.
1 Like
Thanks, that’s a really helpful way to frame it.
I like the hybrid approach — prompt as guidance, memory as state, planner for control, budget/human checks before risky tools, and max iterations as the final brake.
The part I’m still thinking about is the budget check before costly tools. For one workflow, an IF/Switch node is probably fine. But if you have many workflows calling OpenAI, Replicate, SerpAPI, Firecrawl, Apify, or internal APIs, I imagine those checks can get repetitive.
Do you think a reusable guard node would be useful there, or would you still keep it custom per workflow?
Keep workflows DRY (Don’t Repeat Yourself):
Many Workflows ==> One Guard Sub-workflow ==> Shared - Check ==> Approve/Deny ==> Optional Human Review for the Risky Tool
Here is how you can build this natively in n8n:
1. Call n8n Workflow Tool Node
Instead of giving your main AI Agents direct access to a costly API like Firecrawl or Apify you abstract it behind the Call n8n Workflow Tool node.
-
The AI Agent calls this node as a standard tool.
-
It triggers a single, centralized Guard Sub workflow and passes data like session_id and estimated_cost.
-
This sub workflow queries your shared state, like a Postgres DB or Redis, logs the tracking metrics, and evaluates your budget policy
-
If the budget is blown, the sub-workflow simply returns a string back to the agent: "Tool execution denied: Budget limit reached." The agent can then gracefully explain this to the user.
2. The Manual Gate: Native Tool Approval
If the sub workflow approves the budget check, the data flows back to the main workflow.
For highly sensitive or exceptionally risky operations, you can layer n8n’s native Human Review panel directly onto the tool call itself.
The workflow will elegantly pause right before the gated tool runs, waiting for a human to click approve or deny in the n8n UI, ensuring your API wallet is perfectly protected.
1 Like
This diagram makes it click.
I agree n8n should stay the orchestration layer here. The interesting part for me is the shared guard sub-workflow.
In your diagram, the DB/Redis + budget evaluation + logs are the pieces that every team would need to build and maintain themselves.
That’s where I think an external guard could fit: the n8n sub-workflow calls a guard API, gets back allow / warn / deny + reason, and n8n decides whether to continue, stop, or ask for human review.
So not replacing the n8n pattern — more like making the shared policy/state/audit part reusable.
I think my next step should be a small n8n template for this exact flow.
@Doru_Gradinaru
I put together these 2 JSON examples to illustrate the architecture, but I haven’t had the time to test this specific build end-to-end on my own instance today.
Give it a spin when you have a moment, and let me know if it behaves exactly as expected or if the sub-workflow routing needs a slight tweak!
Workflow 1: The Guard Sub-Workflow - Costly Tool Wrapper
Workflow 2: Main AI Agent Workflow:
to test this end-to-end:
-
Paste Workflow 1 and click Save.
-
Grab the Workflow ID for Workflow 1 ( in your URL, for example: /workflow/xyz123).
-
Paste Workflow 2.
-
Open the Call n8n Workflow Tool node in Workflow 2 ==> paste your ID into the Workflow ID field. Make sure “Require Human Approval” is toggled ON.
-
Open the Chat window ==> ask the agent to run the data lookup ==> watch the Human Review UI natively intercept the request before sending it to the guard flow
1 Like
This is great, thank you.
I like that this keeps n8n as the orchestration layer and hides the costly tool behind a shared guard workflow.
I’ll import both workflows and test the native version first. Then I’ll try swapping the mock “Evaluate Budget Limits” step with an external guard call, so the sub-workflow gets back allow/deny + reason instead of managing the budget logic locally.
That feels like the clean split: n8n handles routing and approval, while the guard layer handles shared policy/state/audit.
I ended up sneaking in a quick initial test of this setup on my instance, and the structural routing works flawlessly!
As you can see, the main AI Agent triggered the Call n8n Workflow Tool. Since the mocked budget rule in the sub-workflow evaluation path failed, it gracefully passed the denial text string back up to the parent canvas.
==> The Agent then cleanly caught that message and explained it to the user in the chat without throwing a hard execution error or breaking the UI loop.
The next step from here is to gradually build out and fine tune the sub-workflow’s internal logic like replacing the mocked Code node with an actual database read-write to log live API usage, and dialing in the specific threshold parameters.
1 Like
This is excellent — thanks for testing it.
The key part for me is that the denial path works cleanly: the guard sub-workflow can reject the tool call, return a plain message to the parent agent, and the agent explains it without breaking the chat flow.
That makes the pattern much more practical.
I agree with your next step for the native version: replacing the mock Code node with real DB/Redis state + budget logic.
The version I’m going to test is the same architecture, but swapping that internal budget check with an external guard call. So the sub-workflow would call /v1/check, get back an allow/deny/zone decision, and n8n would still handle routing, denial messages, and optional human review.
So the split would be:
n8n = orchestration / approval / UX
guard service = shared decision / state / audit layer
I’ll try wiring that replacement next and see if the same clean deny path still holds.
1 Like
Thanks again — your example helped me frame this much better.
I documented the same pattern here:
https://proceedgate.dev/n8n.html
The way I’m thinking about it now is:
n8n stays the orchestration / approval / UX layer.
ProceedGate handles the shared guard decision/check before costly tools.
So instead of rebuilding the same budget/repetition logic in every guard sub-workflow, the sub-workflow can call /v1/check and route on allow/deny.
Curious if this split feels right, or if you’d still keep the whole guard fully native in n8n.
Nice work; glad the idea helped and great to see you turning it into a practical pattern.
1 Like
Thanks, really appreciate it.
Your example made the architecture much clearer.
I’ll keep refining this as a practical n8n guard pattern rather than trying to replace n8n’s native flow. The next thing I want to test is whether people prefer this as a simple HTTP Request pattern, an importable template, or eventually a dedicated community node.
That sounds like a very good path forward.
Happy building: I think starting with the simple pattern and then seeing how the community uses it is a great way to evolve it.
1 Like
Thanks — that makes sense.
I’ll keep it simple for now: HTTP Request pattern + importable workflow examples, then see where people get friction.
If a few people actually use it and the setup feels repetitive, then a dedicated community node would be the next logical step.
Small update: I cleaned this up into an importable n8n pattern and added the ProceedGate-powered guard workflow too.
The flow is:
AI Agent → Call n8n Workflow Tool → Guard Sub-workflow → ProceedGate /v1/check → allow/deny → optional human review → costly tool
I also 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
Still treating this as an HTTP Request / workflow-template pattern for now, not a dedicated n8n node yet. I’d love feedback from anyone willing to sanity-check the import flow.
1 Like
