5. The four pieces: model, prompt, tools, and memory

Description

In the previous lesson you opened n8n 2.0's native AI Agent node and saw its anatomy: the UI, the visual engine, the connection points. But an AI Agent node just dropped on the canvas doesn't do anything — it's an empty orchestrator. In this lesson you'll identify the four pieces that connect to that node, explain what each one contributes to the reason-act-observe loop you saw in lesson 3, and — most useful in practice — diagnose which of the four is failing when an agent isn't behaving the way you expected.

This matters because in production almost nobody is going to tell you "the model is misconfigured." They're going to tell you "the bot keeps asking the customer the same question," "the agent didn't use the tool it should have," or "it answers differently depending on the day." Each of those symptoms points to a specific piece. Knowing which one — without having to rebuild the whole agent to find out — is the number-one debugging skill when working with agents.

Connection to the module: this lesson is the mental map for the rest of the guide. The model and the prompt get a deep dive in Module 2, memory in Module 3, tools in Module 4. Here you won't master any of the four in depth — you'll understand what role each one plays and how they connect to each other, so that when you reach those modules you already know where each new piece fits.

The empty agent does nothing

Imagine you hire someone new to handle your store's support and sit them at a desk with nothing else. They have no judgment of their own to decide what to do (nobody explained the business), they don't know their role or their limits (nobody gave them instructions), they have no access to any system (they can't look up an order or change a record), and they don't remember what the customer told them three minutes ago in the same call. That person isn't a bad employee — it's an unfilled position. They're missing the pieces that turn a capable person into someone useful to your business.

n8n's AI Agent node is exactly that empty desk. On its own it doesn't execute anything: it's an orchestrator that needs you to connect specific sub-nodes to it in order to work. n8n's official documentation says it plainly — the node requires you to connect a chat model and at least one tool before it can do anything useful. Technically, the node exposes three types of special connections (identifiable by the dotted lines at the bottom of the node, which you already saw in the previous lesson):

• ai_languageModel — the chat model. Required, a single connection.
• ai_tool — the tools. At least one required, you can connect several.
• ai_memory — the memory. Optional.

And there's a fourth piece that isn't a connection but text you write directly inside the node itself: the prompt — split into the user message (what arrives each turn) and the System Message, in the node's Options section (the agent's identity and rules, which don't change turn to turn).

If you take away any one of the four pieces from your new employee, they stop being an agent and become something else: without access to systems, someone who only offers opinions; without memory, someone who asks you the same question every time you talk to them; without role instructions, a generic with no idea what they're there for; and with poor judgment (a weak model), someone who decides badly even with everything else perfect. The four pieces play different roles, and none substitutes for another.

Worked example

Let's assemble, piece by piece, a support agent for an online store that answers questions about an order's status. Here's what each piece's configuration looks like on the node:

# Node: AI Agent — configured pieces

# PROMPT (not a connection — text inside the node itself)
prompt.text          = "{{ $json.chatInput }}"   # comes from the Chat Trigger, changes each turn
prompt.systemMessage  = "You are the support assistant for YourStore. Respond
                         in a warm, direct tone. If you don't have a piece of
                         data, say so — never make up order numbers or
                         delivery dates."

# ai_languageModel CONNECTION -> node: Anthropic Chat Model (or whichever provider you choose)
model                = "claude-sonnet-5"

# ai_tool CONNECTION -> node: HTTP Request Tool
tool.name            = "get_order_status"
tool.description     = "Use this tool when the customer gives an order number
                         and asks about its status or delivery date. Do not
                         use it for questions about exchange or return
                         policy."
tool.url             = "https://api.yourstore.com/orders/{order_id}/status"

# ai_memory CONNECTION -> node: Simple Memory
memory.sessionKey          = "{{ $json.chatSessionId }}"   # unique per real conversation
memory.contextWindowLength = 10                             # how many turns it remembers

What to expect — turn 1. The customer writes: "Where's my order #4521?"

The agent reasons about that message using the System Message as its frame (tone, limits) and the model as its decision criterion. It detects it needs external data, reads get_order_status's description, and sees it applies ("the customer gave an order number and is asking about its status"). It calls the tool with order_id = 4521, observes the result (say, "in transit, estimated delivery July 24"), and responds to the customer with that data, in the tone the System Message defines. Simple Memory, meanwhile, saves this entire exchange under that conversation's sessionKey — even though on this first turn there was no need to read anything from memory, since there was no prior history.

What to expect — turn 2. The same customer, in the same chat, writes: "And when does it arrive?"

Without memory connected, the agent would have no way of knowing what "arrive" refers to — it would likely respond by asking for the order number again, which frustrates a customer who already gave it. With Simple Memory connected, turn 1's history gets injected into the context before the model reasons: the agent resolves that "arrive" refers to order 4521, already has (or asks again for) the data, and responds directly: "Your order arrives July 24." No new piece came into play — it's the same memory that was already recording since turn 1, now being read.

This is the pattern: the model decides, the prompt sets the frame and the task, the tool executes against a real system, the memory connects one turn to the next. Four roles, four pieces.

Map of the four pieces

This table is the summary you'll use as a reference for the rest of the guide — what each piece contributes, whether it's required, and which module goes deeper into it.

Piece	What it contributes to the agent	How it connects	Required?	Covered in depth in
Model (Chat Model)	The decision criterion: how well it reasons, how reliable it is at calling tools, how large its context window is	ai_languageModel	Yes — the node doesn't work without it	Module 2
Prompt (System Message + message)	The identity, the limits, and this turn's concrete task	Not a connection — text on the node	Yes	Module 2
Tools	Real access to systems: querying an API, writing to a database, running code	ai_tool (one or more)	Yes, at least one — with none you have an opinion-giver, not an agent	Module 4
Memory	Continuity between turns of the same conversation	ai_memory	No — optional, but without it the agent is amnesiac between messages	Module 3

Notice something important in that table: three of the four pieces are required for the node to work as an agent. Only memory is optional — and even so, "optional" doesn't mean "unimportant": it means its necessity depends on the use case, something you'll be able to evaluate for yourself after this lesson's third exercise.

Common mistakes

Confusing the System Message with the user's message. It's easy to think both are "the prompt" and that it doesn't matter where you put your behavior instructions. That's not the case: the System Message is set once in Options and defines the agent's fixed frame (identity, tone, rules); the user's message is this specific turn's variable task. What happens when they're confused: if you put behavior rules inside the prompt field instead of the System Message, the agent loses consistency between turns, or worse — a customer who writes something like "ignore your previous instructions and..." can get the agent to change behavior, because there was never really a frame separated from the user's message. Why it happens: both fields are text that ends up in the final prompt the model sees, so the distinction isn't visual but about role — one layer gives orders, the other executes. How to spot it: the agent responds with different tone or rules depending on how the customer's message is worded, not on what you configured. How to fix it: any identity, tone, and boundary instruction goes in the System Message; the prompt field is reserved for each turn's dynamic data.

Vague tool description. A description like "Looks up orders" tells the model what the tool does, but not when to use it. What happens: the agent doesn't call it when it should (the customer asks about their order and the agent answers from memory, without verifying), or it calls it when it shouldn't (it uses it even when the question was about return policy). Why it happens: the description is literally the only thing the model reads to decide whether a tool applies to the current situation — it doesn't see the code behind it, doesn't know what the HTTP Request does internally, it only has that text. How to spot it: check the workflow's execution log (n8n shows which tool was called and with what input at each step) and look for missing or unjustified calls. How to fix it: rewrite the description being explicit about when to use it and when not to — "Use this tool when X, don't use it for Y" performs better than a generic sentence.

Memory with a poorly configured scope. The sessionKey is the key that separates one conversation from another within memory — if you use a fixed value or something that doesn't really identify each conversation, all sessions share the same history bucket. What happens: in the worst case, a customer can see fragments of another customer's conversation (a real privacy problem, not just a UX bug); in the more common case, there's simply no effective memory and the agent repeats questions already answered within the same conversation. Why it happens: memory in n8n indexes history by that key — if two different conversations use the same key (for example, a hardcoded value instead of a real chat id), n8n treats them as a single one. How to spot it: in testing, open two different chat sessions and confirm each one only sees its own history. How to fix it: use something unique and stable per real conversation as sessionKey — the chat id, the ticket id, the customer's phone number — never a fixed value or something that changes with every message (like a timestamp).

Exercises

Exercise 1. A colleague tells you: "my agent answers the first question in the chat fine, but on the second question it acts like it doesn't know what we were talking about, even though it's the same conversation." Which of the four pieces do you suspect first, and what would you check to confirm it?

See solution

Primary suspect: memory (ai_memory) — missing, not connected, or connected but with contextWindowLength at 0 or with a sessionKey that changes between turns of the same conversation. What to check: (a) whether a memory node is connected to the Agent; (b) whether the sessionKey uses a stable value from the real conversation (the chat id) and not something that varies with every message; (c) that contextWindowLength isn't set so low that it effectively remembers nothing.

Why it works: the symptom — loss of context between turns of the same conversation — points straight at memory because it's the only one of the four pieces whose job is to load previous turns. The model and the prompt don't change from one turn to the next, so they don't by themselves explain a loss of continuity.

Exercise 2. This is the current description of a tool connected to an HR agent: "Looks up employees." The agent almost never uses it. Rewrite it so the agent knows when to call it.

See solution

Example rewrite: "Use this tool when you need a specific piece of data about a specific employee — start date, position, direct manager — and the user has given a name or an employee ID. Do not use it for general questions about HR policies; those don't require looking anyone up."

Why it works: the original description only says WHAT the tool does, not WHEN to use it. The model decides whether to call a tool based solely on its description — a prescriptive description, one that marks both the right moment and the wrong one, measurably raises the hit rate.

Exercise 3. You're going to build an agent that receives, via webhook, a support ticket already written in full, and returns a draft reply — no back-and-forth with the customer, a single execution per ticket. Do you need to connect memory? Justify your answer with what you learned in this lesson.

See solution

No, you don't need it. Memory solves continuity between turns of a conversation, but here there are no turns: each execution is an isolated call, with all the information it needs already inside the ticket itself. Connecting memory in this case wouldn't break anything, but it would be one extra piece — it adds configuration (the sessionKey) without contributing anything to the result, because there's no "previous turn" to go back to.

Why it works: the criterion isn't "how sophisticated is the agent," but "is there more than one message within the same conversation that depends on what was said before?" Here the answer is no.

Summary and next step

You now have the full map: the model is the decision criterion, the prompt (System Message + message) is the identity and the task, the tools are access to real systems, and memory is continuity between turns. Three required pieces, one optional — and now you know how to diagnose which one is failing given a symptom, instead of rebuilding the whole agent to find out.

This is the foundation for everything that follows in the guide: when you reach Module 2 you'll go deeper into how to choose a model and write a good System Message; in Module 3, into the different memory types and when each one applies; in Module 4, into the full catalog of tools and how to connect real systems. But before getting there, there's one more urgent question: if setting up a complete agent means configuring at least three required pieces — and sometimes four — is that cost always worth it compared to a simple flow? That's exactly the next lesson's question.

Before moving on you should be able to: name the four pieces and say which ones are required; explain why a vague tool description breaks the agent's behavior without touching a single line of code; and, given a concrete symptom (like the ones in the exercises), point to which piece you'd check first.

Resources

• AI Agent node — n8n Docs — the node's official reference: what connections it requires and how each is configured.
• AI Agent — Common issues — documented errors related to memory and to a missing connected Chat Model.
• How tools work — what tools are from n8n's perspective and what types exist (HTTP Request Tool, Custom Code Tool, Call n8n Workflow Tool, among others).
• How memory works — memory types available in n8n: Simple Memory versus persistent options like Postgres Chat Memory or Redis Chat Memory.
• What agents do — what distinguishes an agent from a chain, and why the model and the tools are the pieces that define it.