AI Agents in n8n: LLMs, Tools, Memory and When You Do Not Need an Agent

The AI nodes are what draws many people to n8n right now, and the tooling genuinely is ahead of its neighbours: model, tools, memory and a vector store assemble on one canvas. But this is also the easiest place to build an expensive, unpredictable system where a single request would have done.

Model call or agent

The distinction is fundamental and worth settling before you start building.

A plain model call is one step: send the prompt and the data, get an answer. Predictable in time, cost and behaviour. It covers most tasks: triaging tickets, extracting fields from text, summarising, generating a templated reply.

An agent is a model handed tools and the right to decide what to call. It can search, hit your API, look in a database, do it again, then answer. One agent run means several model calls.

The selection rule is simple: if the sequence of steps is known in advance, you do not need an agent. Build it with nodes and get something cheaper, faster and reproducible. An agent earns its place when the steps depend on the content of the request.

Tools

A tool is anything the agent can invoke: a search, an HTTP call to your service, a database read, another workflow.

The practice that determines agent quality is descriptions. The model picks a tool by its description, not its name. “Get data” is a poor description; “Find a customer by email and return subscription status and last payment date” is a good one. Half of all “the agent does not call the right tool” problems are fixed by rewriting descriptions rather than switching models.

The second rule: give it the fewest tools you can. Fifteen options degrade decision quality and multiply pointless calls.

And a third, on safety: a tool is a real action. An agent holding a “delete record” tool will eventually call it. Either do not expose dangerous operations at all, or put a check between the agent and the action.

Memory

By default each run is independent - the model does not remember the previous message. Conversational scenarios, Telegram bots and support flows need memory tied to a participant identifier.

The detail people miss: memory is keyed by a session id. Get the key wrong and every user lands in one shared context and reads someone else’s conversation. In a bot the key should be the chat identifier - that is both functionality and a privacy matter.

The second point: memory grows, and the cost of each request grows with it, because the whole history goes to the model. For long conversations, cap the window.

Your own documents and RAG

The stock request is “make it answer from our knowledge base”. The pattern is standard: documents are chunked, embedded and stored; at query time the relevant chunks are retrieved and sent to the model alongside the question.

What actually determines the result: chunking quality (too small loses context, too large dilutes relevance) and index freshness - documents change while the vectors stay stale until you reindex. Build reindexing in as a scheduled workflow from the start, rather than discovering six months later that the bot answers from a superseded policy.

Cost

An agent is a variable cost, and that changes how you operate it. One run may cost a cent, or considerably more if the agent wanders through its tools.

What to do before production:

• Cap the agent’s step count, or the “call a tool, think, call again” loop can run a long way.
• Match the model to the task. Classification does not need your most expensive model; the saving is a multiple, not a percentage.
• Log spend per run. Without it the month-end invoice is a surprise.
• Test on junk input. An empty message, emoji, text in another language - the agent should not spiral on nonsense.

What breaks in production

Wrong response shape. The model returned prose instead of JSON and the next node failed. If the answer feeds downstream processing, require structured output and validate it - data of the wrong shape remains the leading cause of failures here too.

Non-determinism. The same input yields different answers. Normal for a model, unacceptable for a process that needs reproducibility.

Silent degradation. The agent keeps answering, just worse - the prompt drifted, the index went stale, the model changed. Nothing fails, and the error workflow stays quiet. The only defence is a human spot-checking answers, even once a week.