An ops lead at a mid-size DTC brand built her lead-qualification agent in n8n back when the AI Agent node still asked you to pick an "agent type": Conversational, OpenAI Functions, Plan-and-Execute, among others. It worked, she stopped thinking about it, and eighteen months later a routine n8n upgrade threw a deprecation warning she'd never seen before. The agent-type dropdown was gone. Every one of her workflows had quietly been running on a setting n8n now plans to delete entirely. She isn't alone: n8n consolidated every agent type into a single Tools Agent as of version 1.82.0, and the old configuration path will be removed from n8n 3.0. If you built an AI agent in n8n any time before late 2025, here's what actually changed, why, and what to check before it breaks on you.
What was wrong with the old n8n AI Agent node?
It gave you five different ways to configure the same underlying reasoning loop, and picking the wrong one for your use case was a common, undocumented source of failures. Different agent types handled tool-calling loops differently, some hung when the LLM returned an ambiguous tool call, and memory was stateless by default unless you wired a memory node in yourself, resetting context on every execution. We've covered both failure modes in depth: why your n8n AI agent's tool call crashes the whole workflow and n8n AI agent memory: window buffer vs. vector store. Five configuration paths meant five sets of these bugs to track, most of which fell further behind as n8n improved its one recommended default.
What does the Tools Agent actually do differently?
It's a single consolidated architecture instead of five: connect a chat model and one or more tools, and the agent decides which tools to call to complete the task. In practice that's a ReAct-style loop: the model reads the task plus the name, description and parameter schema of every connected tool sub-node, picks one, the sub-node executes it and returns the result as an observation, and the model decides whether it has enough to answer or needs another tool call. One architecture instead of five means one thing to debug, and it means future n8n improvements to loop termination and error surfacing land for every workflow, not just whichever agent type someone happened to pick back in 2024.
At least one tool sub-node is now mandatory, which closes off the old failure mode of an "agent" configured with zero tools that could only ever produce text with nothing to act on.
What is Chat Hub, and does it replace your existing workflows?
No, it's a new interface layer on top of them, not a replacement. Chat Hub, in beta as of n8n 2.1.0, is a single chat interface that lets you converse with Claude, GPT and Gemini in one place while maintaining context, trigger your existing n8n workflows directly from chat, and get AI-powered analysis of your automation data.
It solves a governance problem, not a modeling one. A new "Chat only" user role lets you hand a non-technical teammate a ChatGPT-style interface to one specific agent workflow without exposing the underlying automation logic they could otherwise edit or break, while IT keeps centralized credentials and model access control. If your actual problem is "the sales team keeps pinging engineering to run the lead-scoring workflow manually," Chat Hub is the fix: wrap that workflow behind a chat-only agent and let them ask for it in plain language instead of filing a ticket.
- It's still beta, and early community reports show rough edges worth testing before you route a real team through it: local Ollama connections initially broke (fixed in 2.1.2), and custom Base URL configurations for OpenAI/Azure OpenAI weren't being applied inside Chat Hub even though the same credentials worked fine in standard workflows.
- Test your exact model-and-credential combination inside Chat Hub itself before depending on it for anything client-facing.
What should you check before n8n 3.0 ships?
- **Audit every AI Agent node for the old agent-type setting.** Any workflow still configured on a pre-1.82.0 agent type is running on a path n8n will delete, not just hide.
- **Replace Postgres/MySQL-specific legacy agent configurations.** n8n's own migration guidance is to use a Postgres/MySQL tool sub-node with a current Agent node instead of the deprecated type.
- **Re-test tool-calling behavior even if no settings visibly changed.** Consolidating five agent types into one changes the exact reasoning loop your workflow runs under the hood.
- **If you're adding MCP-based tools to a Tools Agent**, pair the migration with a look at MCP server security for enterprise AI agents, since n8n's MCP server registry plugs new external tool surfaces directly into the same loop.
How AIBOOTSTRAPPER helps
We build and maintain client automation on n8n because the tool-calling model it just standardized on matches how we architect agents everywhere else. For Leon & Vera (see case studies), Vera already runs this exact pattern: she decides for herself whether to answer an enquiry, check calendar availability, or escalate, calling external tools across WhatsApp, Instagram and the studio's own calendar rather than following one scripted path, and books the first open slot without a human touching the handoff, 24/7, from a €10/day ad budget the owner controls directly.
If your n8n workflows predate this consolidation, or you want an agent that doesn't silently fall over when a tool call fails, talk to us about an automation audit, or see our AI automation services.
Want this done for you?
Book a free strategy call and we'll show you how to build and market your business with AI.