Deferred tool processors now scoped per run
n8n's AI agent framework now creates fresh tool processors for each run, preventing stale closures from leaking tool instances between runs.
When n8n's AI agent framework reused cached tool processors across multiple runs, it inadvertently carried forward stale closures from previous execution contexts. This meant tools could reference outdated state, creating subtle bugs that only appeared after the first run.
The fix is straightforward: each agent run now gets its own tool processor. Rather than caching the ToolSearchProcessor at module level, a fresh instance is created whenever the agent needs one. A new module consolidates the logic for filtering which tools the orchestrator can access—excluding builder-only tools like search-nodes and build-workflow, plus write operations on data tables like insert-data-table-rows.
The orchestrator still sees execution tools like run-workflow and get-execution, which now have output truncation to prevent context bloat. Builder-only and data-table-write tools remain accessible only through planned tasks submitted to sub-agents.
View Original GitHub Description
Summary
- Scope deferred
ToolSearchProcessorcreation to each run so deferred tools do not reuse stale run-scoped closures. - Extract the orchestrator domain-tool filtering into
tool-access.tswithout changing the existing builder-only or data-table-write exclusions. - Add unit coverage for per-run processor creation and orchestrator tool filtering.
How to test
Related Linear tickets, Github issues, and Community forum posts
Review / Merge checklist
- PR title and summary are descriptive. (conventions)
- Docs updated or follow-up ticket created.
- Tests included.
- PR Labeled with
Backport to Beta,Backport to Stable, orBackport to v1(if the PR is an urgent fix that needs to be backported)