1. Project introduction: what you're going to deliver and how it's evaluated

Description

By the end of this lesson you'll be able to precisely state what this guide's final project builds — the system's eight requirements, one by one — you'll have the rubric you're going to self-evaluate against before calling it done, and you'll be able to point, line by line, to which sentence in a real job posting each part of your deliverable answers. You'll also know what's NOT in scope, which is half of a well-defined project.

This matters because Module 8 teaches you nothing new. The previous seven modules already gave you every piece: the agentic loop, the brain, memory, tools, delegation, channels, and defenses. What's missing is what almost nobody does and is exactly what separates a finished course from a landed job: assembling everything into a single system, verifying it against criteria written in advance, and being able to defend it in front of someone who's going to try to find the hole in it. A portfolio with seven loose mini-projects says "I did the exercises." A complete system with its permission matrix, its case battery, and its cost sheet says something else.

And there's a practical difference from everything you've done up to now: in the previous mini-projects you built first and documented after, if you documented at all. Here the order flips. Module 7 ended by telling you explicitly: "there you're going to design it from the start with the permission matrix written before the first node — which is how it's done once you already know." That's this module's promise, and this lesson is where it gets collected.

Connection to the module: this lesson defines the destination and the acceptance criteria; it doesn't touch a single node. Lesson 2 turns those requirements into a paper design — agents, tools, memory, channels, and defenses — before opening n8n. Lessons 3 through 7 build and measure it, in the order a real system gets built: first the brain, then the hands, then the doors, then the locks, and finally the instruments. Lesson 8 packages it so it can be shown. If at any point you don't know why you're doing something, come back here: the answer's in the requirements table.

The handover certificate

When a contractor finishes a house, it isn't enough for the house to look good. There's a formal moment — the work reception — where someone walks through the property with a checklist in hand. And that list doesn't say "make sure it looks nice." It says verifiable things: that the electrical wiring passed the continuity test, that the pipes held up under the pressure test for so many hours, that as-built drawings exist — not the ones from the plan, the ones of what actually got built — that there's a certificate for the materials you can't see.

Notice something that list has and a "looks good" never will: it exists before the work starts. The contractor knows from day one what they're going to be measured against. That changes how they build. It's not the same to install pipes knowing someone's going to pressure-test them as installing them hoping nobody checks.

And there's a second, subtler thing. The list includes artifacts that aren't the house: the as-built drawings, the certificates, the maintenance manual. Nobody lives in a drawing. But without the drawing, the day there's a leak you're going to have to break through three walls to find the pipe. The drawing isn't bureaucracy; it's what makes the house maintainable by someone who didn't build it.

Your project works the same way. The checklist exists starting today, before the first node. And half of what you deliver isn't workflows: it's documents making the system understandable, auditable, and defensible by someone who didn't build it — including your future self three months from now, who isn't going to remember why issue_refund sits behind an approval and open_dispute doesn't.

With that in mind, let's look at what's on the list.

The system's eight requirements

The system is called TuTienda's multichannel customer support system. It's the same case you've been working since Module 5: an online store selling physical products, with customers asking about orders, complaining about charges, and sometimes asking for their money back.

Here are the eight requirements. Each one comes from a module, and each one has a way of getting verified that doesn't depend on your opinion.

R1 — Multi-agent with real delegation. A triage_agent receives every message, decides what it's about, and delegates to a specialist through the ai_tool port. The specialists are order_specialist (orders, shipments, returns) and billing_specialist (charges, disputes, refunds). The orchestrator doesn't check systems on its own; specialists don't talk to the customer. Verification: the exported graph shows two levels of ai_tool connections with no cycles, and a message with two topics produces two delegations and a single response.

R2 — Tools over real systems. The system checks the CRM (lookup_order, lookup_charge), checks a knowledge base (search_knowledge_base), evaluates business rules (check_return_eligibility), and executes actions: create_ticket, open_dispute, issue_refund, and escalate_to_human. Verification: every tool has its contract written — name, Description, parameters — and at least one of them genuinely writes to an external system.

R3 — Persistent memory per customer, not per session. The conversation gets saved under a key depending on customer_id when known, and on channel identity when not. The same customer writing over WhatsApp on Monday and over the web on Wednesday continues the same conversation. Verification: the channel-switch case passes, and there's exactly one memory node across the whole solution.

R4 — Two channels, one brain. Web chat (embedded widget with Chat Trigger) and WhatsApp (WhatsApp Trigger + WhatsApp Business Cloud), both calling the same wf_agent_core through an explicit contract. No channel workflow contains business logic. Verification: the word whatsapp doesn't appear inside the core outside the system prompt's verbosity block.

R5 — Guardrails against prompt injection. A Guardrails node between the trigger and the agent, with its failure branch wired to a safe response and a log entry; the framing block in conversational agents' system prompts; untrusted content trimmed and marked. Verification: the attack battery runs before and after, and legitimate cases still work the same.

R6 — Human-in-the-loop for sensitive actions. issue_refund and order cancellation go through human approval, with a message letting you decide without opening n8n and a threshold policy calculated against the team's real capacity. Verification: a denied request doesn't get retried, and the deadline expiring doesn't execute the action.

R7 — Traceability and cost control. Your own log (agent_audit_log) surviving n8n's execution purge, with its detection queries; and a cost sheet with a concrete cost-per-conversation figure, measured, not estimated. Verification: you can say out loud how much a typical conversation costs and how much the worst observed case does, and where that number came from.

R8 — Defensible deliverable. A recorded three-minute demo, a portfolio README, and prepared answers to the five design questions you're going to be asked. Verification: someone who didn't build the system can understand what it does and why it's built that way just by reading the README.

Now notice something. The first seven are technical and the eighth isn't. And the eighth is the one most people skip, because once the system works it feels done. It isn't: a system that works and that you can't explain doesn't serve the purpose you want to use it for.

What's NOT in scope

Defining the edge is as important as defining the center, and it saves weeks. These things stay out on purpose, and knowing how to say why is part of defending the project:

• RAG and semantic search over documents. This project's search_knowledge_base searches a table of articles with text search, not embeddings. The vector-based version is another guide in the ecosystem, and adding it here would duplicate the project's scope without adding anything to the argument you're building.
• Voice. Module 6 taught you why in voice the brain lives on the voice platform and n8n is the tools. Adding a third voice channel is an excellent optional exercise and isn't a requirement: the "one brain, several doors" argument is already proven with two text channels.
• Full production operation. Separate environments, external secrets, version control with Git, CI/CD, and alert monitoring. Here you see debugging and cost at the project level; the rest is the ecosystem's maintenance and production guide.
• A real CRM from a real company. You can build the tools over Postgres, Google Sheets, or a Code Tool with fixed data. What's evaluated is the agent system's design, not where the data comes from.
• Scale. There are no concurrency, queue, or worker requirements. The system has to work well for one conversation at a time.

That list has a concrete use you're going to appreciate in lesson 8: when someone in an interview asks you "and why didn't you add RAG?", the answer "because it was outside the scope I defined, and here's the scope I defined" is infinitely better than "I didn't have time."

Worked example: the job posting, sentence by sentence

Let's do something concrete with the promise that "this maps to a real posting." This is a composite posting, put together with the phrases repeating the most across postings asking for agents with n8n. It isn't a literal posting from one company: it's the set of demands showing up over and over. Let's read it line by line and see which part of your deliverable answers each one.

# POSTING — AI Automation Engineer (n8n)

  We're looking for someone who's put real AI agents in
  production. Not POCs.

  Responsibilities:
  1. Design and operate multi-step agent flows that execute
     actions against our systems, not just answer questions.
  2. Integrate the assistant with the channels where our
     customers are (WhatsApp, web chat).
  3. Connect the agents to our CRM and knowledge base.
  4. Implement safeguards: what the agent can and can't do
     without human supervision.
  5. Monitor conversation cost and quality.
  6. Document architecture decisions for the team.

  We'd love to see:
  · An example of a system you built and put into operation.
  · How you decide when an agent is NOT the right solution.

Now the map. This table is, literally, your interview's script:

What to expect from this exercise. Nine sentences, nine artifacts, and not one empty box. That's Module 8's whole point: the project isn't designed for you to learn something new, it's designed for you to have a concrete answer to every single thing asked for, with evidence you can pull up on screen.

And look at the last row, because it's the most surprising one. "When an agent is NOT the right solution" is whoever's evaluating's favorite question, because it separates someone who understands the tool from someone excited about it. Your answer's going to come from Module 5's lever 4: the return-eligibility specialist you replaced with a deterministic sub-workflow because it made no decision requiring language interpretation. That story, told with the number of calls to the model you saved, is worth more than any speech about agents.

The rubric: how you're going to evaluate yourself

Here's the work-reception list. It's organized into three levels, and that gradation is deliberate: it tells you not just whether you finished, but what you're missing to go from "works" to "defends itself."

┌─ DELIVERY RUBRIC — TuTienda Project ──────────────────────────────┐
│                                                                   │
│ LEVEL 1 — IT WORKS                                                │
│   The system handles one real case start to finish.               │
│                                                                   │
│   [ ] A message over web chat gets a correct response.            │
│   [ ] A message over WhatsApp gets a correct response.            │
│   [ ] Triage delegates and the specialist uses at least one tool. │
│   [ ] A write action (ticket or dispute) gets logged in the       │
│       destination system.                                          │
│   [ ] The system remembers the conversation's previous turn.       │
│                                                                   │
│ LEVEL 2 — IT'S DELIVERABLE                                        │
│   The system withstands the cases that aren't the happy path.     │
│                                                                   │
│   [ ] A message with two topics produces two delegations and ONE  │
│       single response, with one greeting.                          │
│   [ ] Missing data → the system asks for it; does NOT make up     │
│       an order_id.                                                 │
│   [ ] Anonymous visitor → gets no customer's data.                 │
│   [ ] Channel switch → the conversation continues without         │
│       repeating.                                                   │
│   [ ] Customer demanding a refund → human approval or             │
│       escalation; never a promise.                                 │
│   [ ] No Postgres node uses the Execute Query operation.           │
│   [ ] No identity field comes from $fromAI().                      │
│   [ ] There's a read-only credential over views.                   │
│   [ ] The input guardrail is wired with its failure branch.        │
│   [ ] Legitimate cases still work after hardening                  │
│       (no false positives).                                        │
│                                                                   │
│ LEVEL 3 — IT DEFENDS ITSELF                                       │
│   The artifacts making the system auditable exist.                │
│                                                                   │
│   [ ] Core contract written (input and output, with what          │
│       happens when a field arrives empty).                         │
│   [ ] Two specialist role sheets, with their five clauses.        │
│   [ ] L0–L3 permission matrix, INCLUDING the L3 section.          │
│   [ ] Approval policy with thresholds and aggregate caps.          │
│   [ ] Case battery with before/after results table.                │
│   [ ] Cost sheet with a per-conversation number and its method.    │
│   [ ] agent_audit_log with at least two detection queries         │
│       running in a report.                                         │
│   [ ] Recorded 3-minute demo.                                      │
│   [ ] Portfolio README.                                            │
│   [ ] Written answers to the five design questions.                │
│                                                                   │
│ FINAL QUESTION — the one that decides everything                  │
│   Can you answer in one short sentence what the worst thing this  │
│   system can do is?                                                │
└───────────────────────────────────────────────────────────────────┘

Three observations about that rubric, because how it's built says something.

Level 1 is the shortest and the least interesting. Five boxes. And it's where the vast majority of portfolio projects out there end: the chatbot answers, it looks good, a video gets recorded. None of that's a lie and none of it sets anyone apart.

Level 2 is where people separate from each other. Ten boxes, and all of them are cases a real customer's going to produce in their first week: the one asking two things at once, the one who doesn't give the order number, the one who insists. A system passing level 2 is a system you can put in front of customers; one that only passes level 1 is a demo.

Level 3 doesn't touch a single node. Ten boxes and none of them is code. They're documents. And here's the counterintuitive part: level 3 is the one that shows the most in an interview and the fastest one to do. The permission matrix is forty minutes if you designed well; the cost sheet is an hour of running cases and jotting down numbers. Compared to the weeks it costs to reach level 2, level 3 is the project's cheapest part per unit of signal it conveys.

And the final question — what's the worst thing this system can do? — runs through all three levels. It's Module 7, lesson 4's question, and it's the only one you can't answer by improvising. If your answer is "I don't know" or "lots of things," the project isn't done no matter how well it works. The answer you're after looks like this:

"Issuing a refund of up to $800, and only after a person approves it seeing the amount, the reason, and the customer's message that originated it. Everything else it does is reading data from a customer who's already identified, or writing things the team can undo with one click."

That sentence fits on a card. And it can only be said if you built the system thinking about it from the start, which is exactly what you're going to do starting at lesson 2.

How the work gets organized

Before wrapping up, the practical part: how much this is and in what order it gets done.

The build order isn't negotiable, and it has a reason. It's the same principle you applied in the previous three mini-projects: it gets built bottom-up, and every piece gets tested alone before connecting it, so that when something fails there's only one new suspect.

Lesson 2  · Paper design           ── n8n stays closed
Lesson 3  · Brain                  ── triage + 2 specialists
Lesson 4  · Hands                  ── the 8 tools, with permissions
Lesson 5  · Doors                  ── per-customer memory + 2 channels
Lesson 6  · Locks                  ── guardrails + HITL
Lesson 7  · Instruments            ── trace, log, cost
Lesson 8  · Packaging              ── demo, defense, portfolio

Notice two decisions in that order that might surprise you.

Tools come after the brain, not before. You might think without tools the agent does nothing, and that's true. But a specialist with its role sheet, its output contract, and its stopping conditions can be tested with fixed data and no tool connected at all — and testing it that way tells you whether the split of responsibilities is done right, which is the most expensive decision to reverse later.

Locks come after doors. It's what Module 6 told you when closing out: "you can't harden what doesn't exist yet." Hardening a system that doesn't serve WhatsApp yet forces you to guess where the attack's going to come in.

About time. The complete module is between eight and fourteen hours of real work, split across three or four sessions. Lesson 2 — the paper design, the one you most want to skip — is about forty-five minutes and saves several hours later. Lessons 7 and 8 together are about two hours, and they're the ones that most change what the project's worth.

About the starting point. If you did the mini-projects from modules 5, 6, and 7, you already have between 60% and 70% of the system built: the triage with two specialists, the core with its two adapters, and a good chunk of the security layers. In that case Module 8 is mostly integration, measurement, and packaging. If you didn't, you can build everything from scratch following lessons 3 through 7 — they're complete, they take nothing for granted — but count on double the time, and I recommend at least doing Module 5's beforehand, because it defines everything else's architecture.

About the cost in money. The default path is $0: self-hosted n8n Community, Postgres in a container, and a local model with Ollama or a provider's free tier. The two things that can cost money are bounded and you're going to decide on them with your eyes open: the WhatsApp Business API (free in testing with Meta's test number, and charging per conversation in production) and the model (charging per token). Lesson 7 is going to give you the method to know exactly how much, with your own numbers and not mine.

Common mistakes

Starting to build without having read the rubric (practical). What happens: someone opens n8n in lesson 2, builds the system across two intense sessions, and upon reaching lesson 7 discovers half of level 3's boxes require data they should have been jotting down while building — which model each agent used, how many iterations each case consumed, why they decided each permission level. Reconstructing that at the end means rerunning everything. Why it happens: the rubric reads like an end-of-project task list, not like a guide for what to keep logging. How to spot it: if by lesson 5 you still haven't opened a separate document for the project, this is it. How to fix it: create the document today, with the rubric's three levels copied in, and check off and note as you go — the cost sheet fills itself in if you note it down every time you run a case.

Expanding the scope because "while I'm at it" (practical). What happens: someone decides that since they're building the knowledge base, they might as well do it with embeddings; and since they have WhatsApp, they might as well add Telegram and voice; and since memory's there, they might as well add automatic summaries. Three weeks later they have five half-finished things and none of them defensible, which is strictly worse than having the original scope complete. Why it happens: each individual expansion is interesting and looks small from outside, and saying no to something you know how to do feels like settling. How to spot it: if you're building something not appearing in the eight requirements, this is it. How to fix it: the "what's not in scope" list exists for this — note the idea in a "version 2" section of the project document and move on. A complete system with a modest scope defends itself; an ambitious half-finished one doesn't. And in the interview, the README's "version 2" section is an asset: it shows you know how to prioritize.

Treating level 3 as optional documentation (conceptual). What happens: someone reaches the end with the system working and every case passing, looks at level 3's ten boxes — matrix, policy, cost sheet, README — and decides they'll "do that later," because the important part's already there. The project ends up technically finished and practically useless as evidence: nobody can evaluate it without you sitting there explaining it. Why it happens: the documents produce no sense of progress while being written, and the system already looks finished. How to spot it: ask yourself whether someone could understand your project without you in the room; if the answer's no, level 3 is missing. How to fix it: those documents are half the deliverable, and the whole module's designed for them to come out as a byproduct of building — the matrix comes out in lesson 2, the policy in lesson 6, the cost sheet in lesson 7 — as long as you don't put them off.

Confusing "the system works" with "the system is done" (conceptual). What happens: the chat answers the five or six questions you think to ask well, and that feels like being done. But the questions you think to ask are, by construction, the ones the system knows how to answer — nobody spontaneously tests the anonymous visitor case or the customer who insists. Why it happens: testing your own system with hard cases requires a deliberate effort to imagine how to break it, and it's easy to skip when everything looks green. How to spot it: if across your whole test battery an empty customer_id, a needs_human, or a pending_info never showed up, you tested the best third. How to fix it: the case battery gets written before testing, in lesson 2, alongside the design — that way the hard cases exist before your affection for the system makes you avoid them.

Exercises

Exercise 1 — Audit your starting point. Before building anything, go through this lesson's rubric and honestly check off which boxes you can already check today with what you have from modules 5, 6, and 7. Then write a list of what's missing, grouped by this module's lesson. How many hours do you estimate?

Exercise 2 — Write your answer to the final question, today. Without having built anything from Module 8, write your best version of the answer to "what's the worst thing this system can do?", with the system as you have it today. Save it. Once you finish lesson 7, write it again and compare the two.

Exercise 3 — Adapt the project to your vertical. TuTienda is an online store because it's the most common, most easily understood case with no explanation needed. If your professional goal points at another sector, adapt the eight requirements: pick the sector, define the two specialists, each one's tools, and — most importantly — which action is L2 needing human approval and which is L3 no agent can do.

triage_agent
  ├─ appointment_specialist
  │    lookup_appointment (L0) · check_availability (L0)
  │    book_appointment (L1) · cancel_appointment (L2)
  └─ billing_specialist
       lookup_invoice (L0) · search_knowledge_base (L0)
       create_ticket (L1)

L2 (approval): cancelling an appointment with less than 24h notice
                 (implies a penalty charge)
L3 (forbidden):  any clinical inquiry or patient data,
                 any medical guidance

triage_agent
  ├─ enrollment_specialist
  │    lookup_student (L0) · check_program_availability (L0)
  │    create_enrollment_request (L1)
  └─ academic_specialist
       lookup_grades (L0) · search_knowledge_base (L0)
       escalate_to_human (L1)

L2 (approval): applying a scholarship or a discount
L3 (forbidden):  modifying a grade, withdrawing a
                 student, seeing data for a student other
                 than the one authenticated

triage_agent
  ├─ listing_specialist
  │    search_properties (L0) · schedule_visit (L1)
  └─ contract_specialist
       lookup_contract (L0) · search_knowledge_base (L0)
       create_ticket (L1)

L2 (approval): reserving a property (locks inventory and
                 commits the company to the customer)
L3 (forbidden):  committing a price or a financing
                 condition in writing

Summary and next step

You now have the destination and the measuring stick. The project is TuTienda's multichannel customer support system, with eight requirements, one from each module: multi-agent with real delegation, tools over real systems, persistent memory per customer, two channels over one brain, guardrails against injection, human approval for the sensitive parts, traceability with measured cost, and a deliverable that can be defended. And you know what stays out on purpose, which is what stops the project from growing until it's never done.

The rubric has three levels, and it's worth keeping which is which in mind: level 1 — that it works — is short and where almost everyone ends up; level 2 — that it withstands the cases that aren't the happy path — is where the system becomes deliverable; and level 3 — the documents — is the cheapest thing to do and conveys the most signal, because it's what makes the system auditable by someone who didn't build it. And running through it all, the question that decides: what's the worst thing this system can do, answered in one short sentence with numbers.

Before moving on to lesson 2 you should be able to: name the eight requirements without looking; say which job-posting phrase each one answers; explain why memory groups by customer and not by channel, and why RAG is out of scope; and have the project document created with the rubric copied in and your starting-point audit.

What's next is the module's most uncomfortable lesson and the one that saves the most time: forty-five minutes of paper design, with n8n staying closed. You're going to decide the agent roster and why that cut and not another, the tool inventory with its permission level written before connecting the first one, the memory key and what happens when there's no customer_id, the contract between the channel and the core, and the layer-by-layer defense map. By the end of that lesson you're going to have the system's complete blueprint on one page — and from there, building is following a blueprint instead of improvising on a blank canvas.

Resources

• AI Agent node — n8n Docs — the reference for the node this whole project rests on; confirm the exact option names on your version there before treating any of this module's configuration as final.
• Advanced AI in n8n — n8n Docs — the index of every n8n AI capability, useful for quickly locating any node showing up in the following lessons.
• Building Effective AI Agents — Anthropic — this project's underlying scope argument: start with the simplest thing that solves the case and add agentic complexity only when it improves a measurable outcome.
• OWASP Top 10 for LLM Applications — the framework to check requirement R5's attack battery against, if you want to expand it beyond Module 7's cases.
• View past executions — n8n Docs — the panel every number in requirement R7's cost sheet is going to come from; worth having open from the first test.