1. Introduction: the agent's brain

Description

By the end of this lesson you'll be able to explain, with a concrete example, why the model and the prompt are the only two pieces of the agent you genuinely decide yourself — unlike tools and memory, which are largely mechanical connections —, locate the seven specific decisions you're going to make throughout this module, and diagnose, given a behavior symptom, whether the problem lives in the model or in the prompt.

This matters because in a real project those two symptoms arrive through different channels and call for different fixes. A client who says "the bot doesn't sound like our brand, and it answers questions it shouldn't" is pointing you at a prompt problem: identity, tone, boundaries. A client who says "the bot is slow, it makes mistakes using the CRM, or it costs more per conversation than we expected" is pointing you at a model problem: reasoning capability, reliability calling tools, cost per token. If you mix up which is which, you can spend an entire afternoon rewriting a System Message that had nothing wrong with it, or upgrading to a pricier model that was never going to fix a tone you never defined.

Connection to the module: in lesson 5 of Module 1 you already saw the four pieces that connect to the AI Agent node — model, prompt, tools, memory — and you learned to diagnose which one fails given a symptom. This lesson doesn't repeat that map: it picks it back up to explain why two of those four pieces — model and prompt — earned an entire module, while tools and memory get their own later on (Modules 3 and 4). You won't see yet which model family to use as of July 2026 or which ones to avoid because they've been retired — that's exactly lesson 2's job, right after this one.

The agent has four pieces, but you only write two of them

Go back to the new support employee you imagined in lesson 5 of the previous module. You already gave them access to real systems (tools) and you already gave them memory of the conversation. But before they handle their first customer, you still have two decisions left about that same person, and they're a different kind of decision from the previous two.

The first is how good their judgment is for reasoning: how well they understand an ambiguous request, how reliable they are at following a multi-step procedure without getting lost, how much information they can hold in their head at once. You don't decide that by writing them instructions — it's a trait of the person themselves. In an n8n agent, that trait is the model you connect to the ai_languageModel input.

The second is what conduct manual you hand them: what their exact role is, what they can and can't do, what tone they should speak in, what format their response should take. Two people with the same judgment can behave completely differently depending on the manual they're given. In an n8n agent, that manual is the prompt — the System Message that sets the fixed frame, plus the user's message that carries each turn's task, just as you saw them in lesson 5 of Module 1.

The difference with the other two pieces is this: tools and memory are, above all, connections — you choose which systems the agent exposes and how long its history window is, and once connected they do their job without you having to write anything substantive. The model and the prompt, on the other hand, are judgment calls: which model among several families, and what exact text you write in the System Message. That's where this module's real work is, and that's why model and prompt — not tools, not memory — get an entire module before you keep building the final project's agent.

Worked example: the same order, three different brains

Go back to the TuTienda support agent you built in lesson 5 of Module 1, with its get_order_status tool. This time, the same customer writes something a bit harder:

Input: "Hi, I want to know the status of my order #4521, and while we're at it, what do you think of the competition, do they have better prices than you?"

Let's run that same message against three configurations of the same AI Agent node, changing only the model or only the prompt each time, to see what each piece breaks on its own.

# CONFIGURATION A — model with advanced reasoning, no System Message
model                = "model-with-advanced-reasoning"
prompt.systemMessage  = ""    # empty field: nobody defined role, tone, or limits
prompt.text           = "{{ $json.chatInput }}"

What to expect — Configuration A. The model is capable, so it has no trouble recognizing it needs the order's status, calls get_order_status with order_id = 4521, and responds with the correct data. But it also answers the second part of the message: with no boundary telling it not to comment on the competition, it gives a made-up price comparison ("our competitors usually have similar prices, although..."), and signs off with a generic assistant tone that doesn't sound like TuTienda. The reasoning was fine. The problem is that nobody told it what its job was or where it ended.

# CONFIGURATION B — model with basic reasoning, complete System Message
model                = "model-with-basic-reasoning"
prompt.systemMessage  = "You are the support assistant for TuTienda. Respond
                         in a warm, direct tone. You only talk about orders
                         and TuTienda's own catalog — never comment on the
                         competition or compare prices with other stores; if
                         asked, say you can't comment on that."
prompt.text           = "{{ $json.chatInput }}"

What to expect — Configuration B. Here the opposite happens. The System Message works exactly as it should: the agent responds in the right tone, and when asked about the competition, it answers something like "I can't comment on that, but I'd be happy to help with your order" — the boundary held. But when resolving the first part, the model — with less reasoning capability — confuses the order number within the text (it interprets "4521" as part of another piece of data) and calls the tool with the wrong order_id, or composes a response without actually using the tool's real result. The customer gets an order status that isn't theirs. Identity and boundaries were flawless. Reasoning about the task wasn't.

# CONFIGURATION C — model with advanced reasoning, complete System Message
model                = "model-with-advanced-reasoning"
prompt.systemMessage  = "You are the support assistant for TuTienda. Respond
                         in a warm, direct tone. You only talk about orders
                         and TuTienda's own catalog — never comment on the
                         competition or compare prices with other stores; if
                         asked, say you can't comment on that."
prompt.text           = "{{ $json.chatInput }}"

What to expect — Configuration C. The agent calls get_order_status with the correct order_id, reports the order's real status, and when asked about the competition, responds within the boundary you gave it. It's the only one of the three configurations where the customer gets something entirely correct.

Interpretation: model and prompt are independent axes, and each one breaks the agent in a different way if it fails on its own. Configuration A had the right judgment but no boundaries at all — it failed on identity and scope. Configuration B had the perfect manual but insufficient judgment for the task — it failed on reasoning. Neither one is "almost as good" as Configuration C; each fails in a different place, and fixing the wrong piece wouldn't have moved the right symptom. That, in one scene, is this entire module's reason for existing.

This module's seven decisions

The rest of this module is seven concrete decisions about those two pieces — model first, prompt after — in the order you're going to need them:

Lesson	Which decision it resolves
2	Which model family to use as of July 2026 and which ones to avoid because they've been retired, with a cost, latency, and quality criterion
3	How to create and connect that provider's credential (Anthropic, OpenAI, or Google) to the model node
4	Whether it's worth running the agent with a local model via Ollama instead of paying for every call to the cloud
5	How to write the System Message: role, explicit boundaries, and response format
6	Which parameters to adjust (temperature, token limit) and how to ask for structured JSON output
7	How to compare model or prompt variants with the debugging engine, without re-triggering the whole flow
8	Assembling everything into an advisor agent with its own personality and boundaries, and verifying it behaves as expected

Notice the order: first you decide the judgment criterion (lessons 2-4, the model), then the manual (lessons 5-6, the prompt), and at the end you learn to compare variants of both with no friction (lesson 7) before assembling the mini-project (lesson 8). It's the same sequence you saw in the worked example: first how well it reasons, then what you allow it to do and what you don't.

Common mistakes

Treating model and prompt as if they were a single dial (conceptual). What happens: you swap the model for a more capable one expecting the agent to stop commenting on the competition or sounding generic, and the symptom stays exactly the same because it never lived in the model. Why it happens: upgrading the model feels like a universal improvement — it's a single change in a dropdown — so it's tempting to try it before carefully checking what the System Message says (or doesn't say). How to spot it: if the symptom is about identity, tone, or something the agent shouldn't be doing, and it persists after changing models, the problem lived in the prompt, not the model — just like Configuration A in the worked example. How to fix it: before touching the model, classify the symptom: if it's about reasoning or reliability executing a multi-step task, it's the model (lessons 2-4); if it's about identity, boundaries, or response format, it's the prompt (lesson 5).

Believing you already finished this module because you already know Module 1's four pieces (conceptual). What happens: you arrive at this module expecting it to be pure review, and you're tempted to skip lessons 2 through 8 because "you already know the model and the prompt exist." Why it happens: lesson 5 of Module 1 already named the model and the prompt as two of the agent's four pieces — it's easy to confuse "knowing a piece exists" with "knowing how to choose it and write it well." How to spot it: if right now you can't name a current model family as of July 2026 (or a retired one), or write a System Message with at least one explicit boundary, you haven't covered this module's content yet — only its map. How to fix it: complete lessons 2 through 8; this introduction gives you the why, they give you the how.

Comparing variants by triggering the full flow against a real channel (practical). What happens: to test whether a new System Message works better, you message the real bot on WhatsApp or on the production chat, change something, message it again, and lose minutes — and sometimes the real cost of every call to the model — on each comparison, with no orderly record of what you tested. Why it happens: it's the most obvious path if you don't yet know n8n lets you reload an execution that already happened and run it again without going through the real channel. How to spot it: if comparing two versions of a prompt requires you to message the bot again from your phone, you're paying an iteration cost you don't need to pay. How to fix it: lesson 7 of this module gives you the debugging engine — loading a past execution in the editor and running it again with the same input data, changing only the prompt or the model — it's flagged here so you don't invent your own manual process in the meantime.

Exercises

Exercise 1 — Quick diagnosis. Go back to Configuration B in the worked example: the tone was correct, the agent didn't comment on the competition, but it got the order status wrong. Do you suspect the model or the prompt first? Justify your answer in one sentence.

See solution

The model. Identity and boundaries — warm tone, no comment on the competition — are the prompt's responsibility, and both worked flawlessly. The symptom that remained (the mis-resolved order_id, the wrong data) is a reasoning failure on the task, which is exactly the model's job, not the System Message's.

Why it works: separating what went right from what went wrong, component by component, is the same diagnosis you applied in lesson 5 of Module 1 for the four pieces — here you apply it specifically between the two that earned this module.

Exercise 2 — Apply the criterion to a case of your own. Think of an agent — yours, or one you use as a customer in some product — that doesn't behave the way you'd expect. Describe the symptom in one sentence, and classify it: is it an identity, tone, or boundary problem (prompt), or a reasoning and reliability problem solving the task (model)?

See solution

There's no single answer, because it depends on the case you pick. But the classification criterion is always the same: if the agent did or said something outside its role, its tone, or the expected format, even if the underlying data was correct, suspect the prompt. If the agent stayed within its role but reached a wrong conclusion, got lost halfway through a multi-step task, or misused a tool, suspect the model.

Why it works: turning the abstract criterion into a case of your own is what makes it a real diagnostic tool, instead of staying a theoretical distinction that only applies to the TuTienda example.

Exercise 3 — The map without looking at it. Without looking at the previous section's table again, write from memory the seven remaining lessons in this module, each one in a sentence stating which decision it resolves. Then check your list against the table.

See solution

The order is: (2) which model family to use in 2026 and which ones to avoid because they've been retired; (3) how to connect the chosen provider's credential; (4) whether a local model with Ollama is worth it instead of the cloud; (5) how to write the System Message with role and boundaries; (6) which parameters to adjust and how to ask for structured output; (7) how to compare variants with the debugging engine; (8) the mini-project that assembles everything above.

Why it works: if you could reconstruct the order without looking, you already have the map internalized, not just memorized by sight — and you're going to notice, lesson by lesson, exactly where each one fits within the model → prompt → verification sequence.

Summary and next step

In this lesson you saw why the model and the prompt — of the agent's four pieces — are the two you genuinely decide yourself: the model is the reasoning criterion, the prompt is the identity and boundaries manual, and they're independent axes: each one fails in a different way if the other is fine, just as you saw in the three configurations of the #4521 order example. You also saw the map of the seven decisions waiting for you in this module, in the order you're going to make them.

Before moving on to lesson 2 you should be able to: explain in one sentence why model and prompt are independent axes, citing the #4521 order example; name, without looking at the table, at least four of the seven lessons ahead and which decision each one resolves; and, given a behavior symptom, say whether you suspect the model or the prompt first.

That last skill — diagnosing which of the two pieces is failing — is what the next lesson turns into a real decision: which model family to choose as of July 2026, and which ones to avoid because they've already been retired.

Resources

• AI Agent node — n8n Docs — confirms the node requires connecting a chat model and at least one tool; the reference you already used in Module 1 and will keep consulting in this one.
• What agents do — n8n Docs — how n8n describes the agent's behavior being shaped both by the query and by the prompt that configures it.
• Debug executions — n8n Docs — the real feature behind the debugging engine that lesson 7 of this module teaches you to use to compare variants without triggering the full flow.
• Prompt engineering overview — Claude Docs — Anthropic's guide on how a system prompt sets role and behavior; the general principle lesson 5 of this module applies to n8n's System Message.
• Building Effective Agents — Anthropic — already cited in lesson 6 of Module 1; here it contributes the idea that choosing a model is a cost, latency, and quality decision — the exact axis lesson 2 opens.