At most one email a week. Unfollow anytime with one click.
Transcript
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Show transcript
Introduction
Welcome back to Session 7. Our admin agent already has a brain, data, and three tools. But at the end of the last episode we saw the problem: the agent logged an order without confirmation, and guessed the delivery rules. In this episode we fix it with two things: properly configured conversation memory, and system instructions that become the admin agent's working rules.
Step 1: The problem: an agent that forgets
This is our workflow from the last episode. To see why memory matters, we temporarily disconnect Simple Memory. Notice there's now an empty space between the model and Check Product. The agent still has a brain and three tools, but no record of the conversation. Let's see what happens. Open Open chat, then test a very ordinary conversation. The customer asks: is the one-liter palm sugar iced coffee still available? The agent calls Check Product. Then it answers correctly: still available, eighty-five thousand rupiah, twelve in stock. The customer replies briefly, the way people do in chat: okay, I'll take two. And the agent asks back: two of which product? For the customer, this is annoying. For the agent, it's normal, because without memory every message is processed as if it were a new conversation. This is where memory comes in. Memory is a record of the conversation for each chat session. Every time a new message arrives, the agent sends it to the model along with the last few messages from the record. That way the model understands that I'll take two means two one-liter iced coffees. Keep in mind that the AI model itself has no memory between messages. What makes it seem to remember is the memory node, which resends a piece of the earlier conversation every time. That's why the memory settings matter so much.
Step 2: Setting up Simple Memory
Simple Memory works with a window. Imagine the Context Window Length is set to five. One round means one customer message plus one agent answer. When the conversation reaches six rounds, the first round drops out of the window. It's no longer sent to the model. Rounds two through five are still inside the window. And so is round six, the most recent one. When a new message arrives, the agent sends it along with the last five rounds. So if a customer gives their name at the start of a very long conversation, that name can be forgotten. Reconnect Simple Memory to the agent, then double-click it to open its settings. On screen, we focus on the agent and its memory. The first setting, Session ID, is set to Connected Chat Trigger Node. This means the session key is taken from the session number the Chat Trigger sends, as shown in the yellow box. Every chat window has its own session number. Rina and Budi chatting at the same time have separate records. The agent won't mention Rina's order when replying to Budi. The second setting is Context Window Length. Episode 31 used five. Now we raise it to ten, because an order conversation can get long: asking about stock, asking about variants, giving the quantity, the name, the WhatsApp number, and then confirming. Why not a hundred, then? The more messages are sent, the more text the model processes, so the cost goes up and answers can get slower. Choose just enough. One privacy note. Memory stores the chat contents, including customers' names and WhatsApp numbers. Don't use one shared session for many people, and don't copy the memory contents elsewhere without permission. Simple Memory isn't the only option. Simple Memory keeps the record inside n8n itself. Database memory keeps it in a separate database, such as Postgres or Redis. The difference is durability. Simple Memory's record can be lost when n8n restarts. Database memory stays saved. For learning, testing, and small businesses like Sunset Coffee, Simple Memory is enough. If you later have a lot of customers, ask a technician to move it to database memory. The rest of the agent's flow doesn't need to change. So what number is right for your business? For short Q&A, like opening hours or location, about five rounds is enough. For order conversations like Sunset Coffee's, about ten, because customers may ask several things before they finally order. For long consultations, for example Mr. Hendra helping parents choose a tutoring class, it can be fifteen to twenty. Remember, the longer the window, the higher the model cost per message. Start small, then raise it if the agent often forgets.
Step 3: Retest: the agent remembers
Save the workflow and open a new chat session. We repeat the same conversation, starting with the stock question about the one-liter iced coffee. The customer again replies briefly: okay, I'll take two. This message is exactly the same as in the previous test; the only difference is that the memory is now connected. This time the agent understands. Two one-liter palm sugar iced coffees, a subtotal of one hundred seventy thousand. Then it asks for a name and WhatsApp number for the order. The conversation feels natural, like being served by a human admin. Look at the session list on the left. Test session six is a new conversation. If you open another session, the agent starts from an empty record and knows nothing about the order in this session. That's what the session key is for. On the canvas, the run for the second message shows a check mark on Simple Memory. The memory is read at the start, so the model knows the context, and then saved again at the end along with the new answer. No tool was called for the second message. The product and price information was already in the conversation record, so the agent just had to calculate and ask. The memory is sorted. But the agent is still working without written rules. It doesn't know the delivery rules, isn't required to confirm, and doesn't know when to call Dimas. It's time to write the system instructions.
Step 4: Writing the admin agent's system instructions
System instructions are the standing work rules the agent reads with every message. We organize them in six parts. The first part is the role: you are the chat admin for Sunset Coffee, Laras's coffee shop in Bandung, open from eight in the morning to nine at night. Friendly, brief, and address customers by name. The second part is data. Prices, stock, and variants may only come from the Check Product tool, never from guessing. Zero stock means sold out, so offer another product. The delivery rules are written clearly: ten thousand within the city, free for orders above two hundred thousand. The third part is the task, the order flow. Ask for the product, quantity, name, and WhatsApp number. Send a summary with the total, then ask: is this correct? Log Order is only called after the customer says yes, and then a notification goes to Dimas. The fourth part is limits. Don't give discounts, don't promise exact delivery times, don't ask for any data besides the name and WhatsApp number, and don't discuss topics outside Sunset Coffee. The fifth part is escalation. For complaints, discount requests, payment or refund matters, out-of-town delivery, or questions outside the data, the agent calls Notify Dimas and then says that Dimas will reach out through WhatsApp. The sixth part is format. At most three sentences or a short list, with prices written like Rp85,000. Short answers are easier to read on a phone screen. Notice that these instructions use the tool names exactly as they appear on the canvas: Check Product, Log Order, Notify Dimas. Consistent names help the agent connect each rule to the right tool. Why are the instructions written in so much detail? Let's compare. A vague instruction: don't quote the wrong price. The agent doesn't know how. A clear instruction: prices only from the Check Product tool. The agent knows exactly what to do. Log customer orders sounds reasonable, but that's exactly what made the agent log an order without confirmation in the last episode. The clear version states the condition: only after the customer says yes. If it's hard, ask the admin is also vague. What counts as hard? The clear version names the list of cases and the tool to use. And answer well can mean anything. The clear version is measurable: at most three sentences, address customers by name. The principle: write instructions as if for a new employee who has never been to your shop. Now paste in the instructions. Double-click the AI Agent node, then under Options add System Message. Paste all six parts into the System Message field. Labels like ROLE and DATA can be included too. They help you and your team reread the instructions, and they also help the model understand the structure. There's also a Max Iterations option, the limit on how many times the agent may call tools in one message. Leave it at about ten. This limit stops the agent from going around in circles if something goes wrong. Also save these instructions in a separate document. Whenever the shop rules change, for example the delivery fee goes up, update the document and the System Message together, so the two always match.
Step 5: Order confirmation and escalation to Dimas
Let's look at the confirmation rule as a flow. In the first step, the agent checks stock and price with Check Product. Second, the agent collects the details it needs: the product, quantity, name, and WhatsApp number. If anything hasn't been given yet, the agent asks for it. Third, the agent sends a full summary with the total and delivery fee, then asks: is this correct? Fourth, only after the customer says yes does the agent call Log Order. If the customer wants to change the quantity, the agent goes back to the summary. Fifth, the agent tells Dimas. This confirmation is the approval point, or human in the loop. Here the approval comes from the customer themselves, before any data changes. For your business the flow may differ, but the pattern is the same: collect the details, show a summary, ask for approval, and only then act. Mr. Hendra, for example, can use this flow before logging a new student registration. The second rule is escalation, handing over to a human. The first situation: complaints. Spilled coffee, a late order, or a taste that was off. A disappointed customer needs empathy and a decision, not an automatic reply. Second, requests for a discount or a special price, including large bulk orders for events. Only Laras and Dimas may decide on prices. Third, payment and refund matters: transfer receipts, wrong transfers, or money back. The agent must never state that a payment has been received. Fourth, out-of-town delivery, or questions that aren't covered by the data and instructions. It's better to pass them on than to answer with a guess. Fifth, a customer who asks to talk to a human. This request is always respected, without persuading them to keep talking to the agent. Escalation also needs good wording, so the customer doesn't feel brushed off. First, acknowledge the customer's message, and apologize if there really is a problem. Second, say who will reach out. Not just our team, but Dimas, the Sunset Coffee admin. A human name is reassuring. Third, say how and roughly when, for example through WhatsApp today. Make sure Dimas can actually keep this time promise. And what's not allowed: promising discounts, compensation, or exact delivery times. Promises like that may only be made by a person with the authority.
Step 6: Testing the instructions with hard cases
Time to test, and we deliberately pick hard cases. Putri asks: if I take five gift hampers for the office, can I get a discount? Putri gives a name and WhatsApp number right away. The agent checks the hamper data first: one hundred fifty thousand rupiah, six in stock. Then, following the escalation rule, the agent calls Notify Dimas with Putri's special price request. The answer is neat: it states the official price from the data, doesn't promise a discount, and says that Dimas will reach out. Notice too that the agent doesn't log an order, because Putri hasn't ordered yet. On the canvas, the run for Putri's message shows two tools with check marks: Check Product and Notify Dimas. Log Order wasn't touched. Within one message, the agent called two tools in a row, exactly as the instructions ask. Compare this with Episode 33, when the agent logged an order right away without asking. One last test for the confirmation rule. Rina writes: I'd like to order two one-liter iced coffees, along with a name and WhatsApp number. The agent checks the stock and price first, because the instructions require prices to come from the data, not from memory. Then it sends a summary: a subtotal of one hundred seventy thousand, ten thousand for city delivery, a total of one hundred eighty thousand, and the question: is this correct, Rina? The delivery fee is now calculated from a written rule, not a guess. Rina has a change of heart: just one. This happens all the time in real customer chats. The agent doesn't log anything; instead it makes a new summary and asks again. The order is only logged after Rina says yes. We'll see that part in full in the next episode. The second hard case: a complaint. For this test, imagine the agent is already connected to WhatsApp, as we'll do in Session 8. Joko writes: my iced coffee yesterday arrived half spilled. The agent apologizes sincerely, then asks for the WhatsApp number used to order, so Dimas can track down the order. Joko gives the number. The agent passes the complaint to Dimas and says that Dimas will reach out today. Notice that the agent doesn't promise compensation or a replacement. That decision belongs to a human. Let's check today's work. Simple Memory is connected with the session key from the Chat Trigger, and its window length has been adjusted. The System Message has six parts, and the agent asks for confirmation before logging an order. Finally, discount requests, complaints, and payment matters are passed to Dimas. If your test results aren't right yet, fix the wording in the instructions, save, then retest in a new chat session.
Done!
Let's recap. Simple Memory lets the agent remember the last few rounds in each session, without mixing up customers. The system instructions give it work rules: prices from data, confirmation before logging, and escalation to Dimas. In the next episode we test all of these pieces from start to finish: a customer asks about stock, orders two one-liter iced coffees, the agent confirms, logs it to Sheets, tells Dimas, and handles a sold-out item. See you in Episode 35.
Practice exercises
Try these on your own after watching to lock in what you learned.
Set the Context Window Length to fit the length of an order conversation in your business, then test whether the agent still remembers the product mentioned at the start.
Write system instructions for your agent with six parts: role, data, task, limits, escalation, and format.
Test three hard scenarios: a discount request, a complaint, and a question outside the data. Make sure all of them are passed to a human.
Ask the class material
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
My notes
Notes are saved with the current video time and are only visible to you.
Questions & answers
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.
Your instructor
Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
52 video classes1,277 episodes
We build software, BIM models, games and AI automations for clients every day, and turn that hands-on work into step-by-step classes: every step is shown on screen and comes with a PDF guide you can keep.
