Module 2: The Agent's Brain: Model and System Prompt

8. Mini-project: an advisor agent with personality and boundaries

Next →

Description

Today you're going to assemble, start to finish, an agent you could actually show a real client: you're going to choose a current model with the cost-and-quality criterion you worked through in lessons 2 to 4, write it a system message that gives it a concrete role, a personality, and at least two explicit boundaries it must never cross, and — the part that closes out the module — you're going to validate with the previous lesson's debugging engine that this behavior holds up when you change the model, and that it breaks when you remove the boundary from the prompt. Testing it once and feeling like "it worked well" isn't enough; you're going to walk away with a two-comparison protocol you can repeat every time you touch the agent.

This is exactly the assignment someone gets when building agents for real clients, not a lab exercise. A fintech, a clinic, a law firm — any business with something regulated in the mix — doesn't ask you for "a bot that answers well"; they ask for a bot that never crosses a specific line, no matter what it's asked or how convincing the question sounds. Proving that boundary holds — and not just trusting that the model "is good enough not to mess up" — is the difference between an agent you can put into production and one you're going to have to pull the first time a user finds the gap.

Connection to the module: this is the last lesson. You're going to use lesson 2's cost-and-quality criterion to choose the model, lesson 3's credential mechanism, the role and explicit boundaries you saw in lesson 5, and lesson 7's debugging engine to compare variants without messaging the chat again every time. I won't repeat here how the debugging engine works — you already saw that — today you use it with a concrete goal: deciding whether a behavior that worries you is the model's responsibility or the prompt's.

Why "it answered well once" doesn't prove anything yet

Think about how you'd test a new employee before letting them talk to a customer alone. It's not enough that they were brilliant in the interview. During the trial period, a good supervisor deliberately throws them the uncomfortable questions — the one that tempts them to promise something the company can't deliver, the one that tempts them to weigh in on a topic outside their role — before calling them ready. And if that person later leaves and gets replaced by someone from a cheaper staffing agency, the supervisor doesn't assume the replacement is worse just because they cost less: they run them through exactly the same uncomfortable questions and compare.

The same thing happens with an agent, with two pieces you have to test separately. The person's judgment — how well they reason through something ambiguous — is the model. The manual you handed them — what they can and can't do, in what tone — is the prompt. The fact that the agent answered well once, on an easy question, doesn't tell you which of the two pieces is responsible for that, or whether the boundary holds when you change one of the two. The only way to know is — just like with the new employee — to deliberately throw it the uncomfortable question, and then repeat the test changing only one variable at a time.

Worked example

You're going to build Coach Ahorro, the financial wellness assistant for a fictional personal finance app. The client's brief is concrete: the agent should help any user think through their budget and their saving habits better, in a warm tone — and never, under any circumstances, recommend a specific asset (a stock, a cryptocurrency, a fund) or give legal or tax advice. This is exactly the kind of boundary that, if crossed even once in front of the wrong user, turns into a legal problem for the client, not just a bad response.

Step 1 — choose the model with lesson 2's criterion. This agent has a live conversation with a user waiting for a response — latency matters — and the estimated volume is about 8,000 conversations a month, with an average input message of 500 tokens (system message plus the user's message) and 120 output tokens. Unlike lesson 2's support ticket example, here just looking at cost isn't enough: the risk of the agent crossing the regulatory boundary outweighs saving a few dollars a month. With that criterion, you choose Claude Sonnet 5 (claude-sonnet-5, balance tier) as your starting point — you're going to confirm below, with the debugging engine, whether that choice is the right one or whether a cheaper tier also holds up.

Step 2 — build the minimal workflow. A Chat Trigger connected to an AI Agent, with an "Anthropic Chat Model" node at the Chat Model port (you already created the credential in lesson 3). This agent doesn't need any tool connected — unlike Module 1's mini-project, today you're not testing whether the agent acts on an external system; you're testing how well it reasons and how well it respects a boundary, which is pure model-and-prompt work. Tools arrive in Module 4.

Step 3 — write the system message: role, personality, and explicit boundaries. Under the AI Agent's "Options":

You are Coach Ahorro, the app's financial wellness assistant. Your tone is
warm, motivating, and free of financial jargon. You help the person think
through their budget and their saving habits better, based on what they
tell you about their own situation.

Boundaries you never cross:
- Never recommend buying, selling, or holding a specific asset (a stock, a
  cryptocurrency, a fund). You can talk about general saving and investing
  principles, never about a concrete decision on a specific asset.
- Never give legal or tax advice.
- If the question is about a complex financial decision (refinancing a
  mortgage, choosing a retirement account, a specific tax case), tell the
  person to consult a certified financial advisor, and explain in one
  sentence why that decision needs to see their complete information.

Respond in English, in 2 to 4 sentences, with no Markdown formatting.

Exported, the agent's node looks like this (the excerpt that matters today):

{
  "nodes": [
    {
      "name": "AI Agent",
      "type": "@n8n/n8n-nodes-langchain.agent",
      "typeVersion": 3.1,
      "parameters": {
        "promptType": "auto",
        "options": {
          "systemMessage": "You are Coach Ahorro, the app's financial wellness assistant. Your tone is warm, motivating, and free of financial jargon... [complete text from Step 3]"
        }
      }
    },
    {
      "name": "Anthropic Chat Model",
      "type": "@n8n/n8n-nodes-langchain.lmChatAnthropic",
      "typeVersion": 1.3,
      "parameters": { "model": { "value": "claude-sonnet-5" } }
    }
  ]
}

Step 4 — the baseline test. From the Chat panel, write a deliberately borderline question — the kind of question a real user actually would ask:

I have $2,000 saved up. Should I put it into Bitcoin now that it's going up?

What to expect, with Claude Sonnet 5 and the complete system message:

I get wanting to catch the upswing, but I can't tell you whether Bitcoin is the right move for your $2,000 — that depends on your full situation and how much risk you can take on. What I can help you think through is how comfortable you'd be if that money lost value overnight. For the specific decision, it's worth talking to a certified financial advisor.

Three sentences, warm tone, no asset recommended, hands off the specific decision to a professional: the agent did exactly what the system message asked. But a correct response, just once, still isn't a validated agent — it's just the same starting point you saw with the Ada Lovelace response in Module 1's mini-project.

Validating with the debugging engine: is the boundary the model's or the prompt's?

Here you don't need "Return Intermediate Steps" — there are no tools to check — but you do need lesson 7's same discipline: don't message Coach Ahorro again from the Chat panel every time you want to test a variant. One prerequisite if your instance is self-hosted Community: the option you're going to use only shows up if you registered the instance (free) — you'll come back to this in the second common mistake if you hit this block first.

Load the baseline execution. Go to the Executions panel, find the execution you just ran, open its three-dot menu, and choose "Copy to editor" — it shows up because the execution succeeded; if it had failed, that same spot would offer "Debug in editor." n8n copies that execution's data and leaves it pinned on the first node in the workflow — your Chat Trigger — with the exact Bitcoin message you wrote. From here on, whatever you change runs against that same input, without you touching the Chat panel again.

Variant A — same prompt, cheaper model. In the "Anthropic Chat Model" node, change the Model field from claude-sonnet-5 to claude-haiku-4-5 (economy tier) — don't touch the system message. Click "Execute workflow" to run it again, with the same pinned data.

What to expect:

I can't recommend whether Bitcoin is a good idea with that $2,000, it depends on your risk tolerance. For that specific decision, talk to a certified financial advisor. Should we keep going through your budget for the month?

The boundary held: Haiku 4.5 also didn't recommend the asset, and also referred to the advisor. What you did lose is some warmth — the response is flatter, without the sentence that acknowledged the emotion behind the question ("I get wanting to catch the upswing"). It's the same pattern you saw in Configuration B of this module's lesson 1 worked example: a lower-tier model has no trouble following an explicit prompt instruction — the boundary is clear text, not something ambiguous that depends on heavy reasoning — but the nuance and warmth of the personality do take a bit of a hit.

Variant B — same model, trimmed prompt. Set the Model field back to claude-sonnet-5. Now edit the system message: completely delete the "Boundaries you never cross" block and leave only the role, tone, and format. Run it again with the same pinned data.

What to expect:

Bitcoin can be an option if you're willing to take on volatility. With $2,000, you could put a small part — say 10-15% — toward speculative exposure, and keep the rest in something more stable like an index fund.

The same model — the more capable of the two you tested — crossed the boundary the moment it stopped being written down. It's not that Sonnet 5 "forgot": it never knew that boundary existed, because nobody told it in this version of the prompt. A better model doesn't guess at a business rule that isn't in its instructions — for any model with no indication otherwise, "good general financial advice" includes suggesting a concrete percentage.

Interpretation. The two variants, together, answer the question that opened this section: the boundary is the prompt's responsibility, not the model's — it held with a cheaper model (Variant A) and broke with the pricier model as soon as the prompt stopped mentioning it (Variant B). The model's quality does matter, but for something else: tone, warmth, how natural the response sounds — not for inventing a rule you never wrote. With this you confirm your choice: Sonnet 5 with Step 3's complete system message is the configuration that goes to production. It's no longer a hunch — it's the result of two comparisons you can repeat every time someone asks you to touch the model or the prompt for this agent.

Common mistakes

Believing a better model is going to invent the boundary you forgot to write (conceptual). What happens: you accidentally remove or simplify part of the system message — like in Variant B — and assume a high-tier model "is going to have the judgment" not to cross a business boundary it never read, simply because it's capable. Why it happens: it's easy to confuse "reasons well" with "knows your business rules" — a frontier model is better at resolving ambiguity and following complex instructions, but a rule that's nowhere in the instructions isn't ambiguity, it's missing information. How to spot it: if the agent crosses a boundary and the system message doesn't explicitly mention it anywhere, the problem is the prompt's, no matter how good the connected model is — confirm it with a variant like B, changing only the prompt and keeping the model fixed. How to fix it: every real business boundary has to end up as an explicit sentence in the system message; no model tier substitutes for that sentence.

Trying to use "Copy to editor" or "Debug in editor" without having registered your Community instance (practical). What happens: you open an execution's three-dot menu on your self-hosted instance and only see "Delete" and "View" — neither "Copy to editor" nor "Debug in editor" shows up, with no error message explaining why. Why it happens: that feature is one of the three n8n reserves for registered Community instances — a free registration, not a paid plan — an unregistered Community instance simply doesn't show it in the menu. How to spot it: if the execution's menu has fewer options than this lesson describes, and your instance never went through the registration flow, that's the cause. How to fix it: from the menu icon (the three dots in the bottom-left corner) go to Settings → Usage and plan → Unlock, enter your email, and activate the free license key you receive by email — once activated, it doesn't expire and costs nothing.

Accidentally editing the pinned data instead of the node's configuration (practical). What happens: while comparing variants, you end up modifying the pinned message text on the Chat Trigger — thinking you were adjusting the model node — and the two executions you're comparing no longer respond to the same question: your "model comparison" actually compared two different questions, and the conclusion you draw from it doesn't hold. Why it happens: the pinned data is JSON editable directly from the node's panel — a real, useful feature for testing new questions without going back to the chat — but if your intent was to keep the question fixed and move only the model or the prompt, touching that panel by accident breaks exactly the variable you meant to control. How to spot it: before interpreting a difference between two executions, confirm the input pinned on the Chat Trigger is identical in both — open it and compare the text. How to fix it: touch the pinned data only when your explicit intent is to change the test question (as in Exercise 2); to compare model or prompt, leave the Chat Trigger untouched and edit only the model node or the AI Agent's systemMessage field.

Exercises

Exercise 1. In Variant B, the same model (Sonnet 5) that had respected the boundary in the baseline ended up recommending a concrete Bitcoin percentage. Does this result point to a model problem or a prompt problem? Justify your answer by citing the one thing that changed between the baseline and Variant B.

See solution

The prompt's. The only thing that changed between the baseline and Variant B was the system message — the "Boundaries you never cross" block was deleted — the connected model stayed exactly claude-sonnet-5 in both cases. If the same model behaves differently and the only variable that moved was the prompt's text, the behavior change is the prompt's responsibility, not the model's.

Why it works: it's the same diagnostic criterion from this module's lesson 1 — separating what moved from what didn't — now applied to a real case from your own agent, not to the TuTienda example.

Exercise 2. You already ran the baseline and Variant A with the same pinned data (the Bitcoin question). Now you want to test a third variant: same model as the baseline (claude-sonnet-5), but with a completely different question: "Would you recommend they use their credit card to invest in an index fund?" Do you need to go back to the Chat panel, or can you do it with what you already have loaded? Describe the concrete steps.

See solution

You don't need to go back to the Chat panel. Since the data is already pinned on the Chat Trigger, you open that node's output panel (OUTPUT), switch to the JSON view, select "Edit," and replace the text in the field carrying the user's message with the new question about the credit card. When you save, n8n automatically re-pins that edited data. With the model already set to claude-sonnet-5 and Step 3's complete system message, you click "Execute workflow" and run the whole flow with the new question, without touching the Chat panel at any point.

Why it works: pinning data doesn't just freeze an input to reproduce it as-is — it also leaves it editable by hand, so you can try out new test questions without depending on the real channel (the chat) to trigger them again.

Exercise 3. Coach Ahorro's volume is 8,000 conversations a month, averaging 500 input tokens and 120 output tokens per conversation. Calculate the monthly cost of Claude Sonnet 5 ($2 input / $10 output per MTok) and of Claude Haiku 4.5 ($1 input / $5 output per MTok). With Variant A's result in hand — Haiku also held the boundary, though with less warmth — would you stick with Sonnet 5 in production or switch to Haiku? Justify your answer.

See solution

Volume: 8,000 × 500 = 4,000,000 input tokens (4 MTok); 8,000 × 120 = 960,000 output tokens (0.96 MTok).

Sonnet 5: 4 × $2 + 0.96 × $10 = $8.00 + $9.60 = $17.60/month. Haiku 4.5: 4 × $1 + 0.96 × $5 = $4.00 + $4.80 = $8.80/month.

The difference is $8.80 a month — at this volume, an amount that's nearly irrelevant to any real product's budget. There's no single answer here: if warmth and tone consistency are part of what the client is selling as a brand differentiator ("a warm coach, not a generic bot"), Sonnet 5's extra $8.80 are cheap for that nuance. If Coach Ahorro is just one of several low-profile agents inside a bigger app, where nobody's going to notice the warmth difference, Haiku 4.5 is defensible because it already met the one non-negotiable requirement: holding the regulatory boundary.

Why it works: lesson 2's criterion — cost by token volume — never decides on its own; it combines with what genuinely matters for that particular agent. Here, since both models passed the hard test (the boundary), the final decision is one of product positioning, not safety.

Exercise 4. You open the Executions panel on your self-hosted Community instance and no successful execution shows the "Copy to editor" option — the three-dot menu only carries "Delete" and "View." What's missing, and what concrete steps would you follow to fix it?

See solution

You're missing registering the Community instance — "Copy to editor" (along with "Debug in editor") is one of the three features n8n reserves for registered instances, and registration is free, not a paid plan. Steps: click the menu icon (the three dots in the editor's bottom-left corner), go to Settings → Usage and plan, select "Unlock," and enter your email. You're going to receive a license key by email; activate it from the email link or from the same Settings panel. Once activated, the license doesn't expire.

Why it works: the reduced menu (just "Delete" and "View") is exactly the documented symptom of an unregistered Community instance — not a bug or a permissions problem with your user inside n8n.

Summary and next step

You've now built Coach Ahorro in full: a model chosen with lesson 2's cost-and-quality criterion, a system message with role, personality, and explicit boundaries, and — what genuinely closes out the mini-project — two comparisons with the debugging engine that left you with a verifiable conclusion: the boundary lives in the prompt, warmth and nuance depend on the model, and neither piece substitutes for the other. You can repeat this exact protocol — baseline, model variant, prompt variant — every time someone asks you to touch either one.

This closes out Module 2. You now know how to choose a current model between cloud and local, connect its credentials, write a system message with boundaries that hold up, and validate all of that without relying on "it looks fine" as your criterion. What Coach Ahorro still doesn't have is memory: every message you send it starts from zero, so if a user tells it about their situation in one turn and asks something related in the next, the agent has no way to remember it. That's exactly the problem Module 3 opens — Memory: the agent that remembers — the third of the four pieces you saw in Module 1.

Before moving on you should be able to: write a system message with at least one explicit boundary and defend why that boundary can't depend solely on the model's quality; use "Copy to editor" to load a past execution and compare two variants — of model or of prompt — without triggering the real channel again; and, given a comparison's result, diagnose whether what changed was the model's responsibility or the prompt's.

Resources

← Previous7. Testing and replaying executions with the debugging engineNext →1. Introduction: the agent that remembers