Picked from the software, topic, and level of “Agentic AI Without Coding Class #35: Practice: An Admin Agent That Answers Stock and Price Questions and Logs Orders”.
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 to the last episode of Session 7. Over four episodes we built the Sunset Coffee admin agent piece by piece. Today we test it all together, from start to finish. The scenario is real: a customer asks about stock, orders two one-liter iced coffees, the agent confirms, logs it to Google Sheets, and notifies Dimas. Then we test the hard cases, like a sold-out item.
Step 1: The full setup and test preparation
Let's look at the full setup one more time. On the left is the Chat Trigger, the entrance for every customer message. Then the AI Agent node, which now carries the admin instructions from Episode 34: the role, price rules, confirmation, and escalation. Below it, the Chat Model as the brain, with a low temperature so the answers stay consistent. Simple Memory, which remembers the last ten rounds in each session, with the session key from the Chat Trigger. Check Product, a tool that only reads the Products tab, so it's safe to use at any time. Log Order, a tool that adds a row to the Orders tab, only after the customer agrees. And Notify Dimas, which sends an email to the admin. Seven nodes, without a single line of code. Now let's prove they all work together. Before testing, set up the conditions. First, check the Products tab. The one-liter iced coffee has a stock of twelve, and the cold brew is deliberately at zero to test a sold-out item. Second, make sure the Orders tab is clear of test rows from earlier episodes, so today's results are easy to spot. Third, make sure the System Message is saved. Open the AI Agent node for a moment and check that all six parts of the instructions are there. Fourth, start every scenario in a new chat session. That way the memory doesn't carry leftovers from the previous test. Today there are three main scenarios. First, a customer asks about stock. Rina wants to know whether the one-liter iced coffee is available. Second, Rina orders two one-liter iced coffees. Here we test confirmation, logging, and notification. Third, Sari orders cold brew, which is sold out. This scenario tests whether the agent is willing to say no, even when the customer is ready to buy. After that, a few edge cases. For every scenario, we check three places: the chat answer, the tools called on the canvas, and the data in Google Sheets. All three must match.
Step 2: Scenario 1: a customer asks about stock
The first scenario. Open Open chat in a new session. Rina writes: hi there, is the one-liter palm sugar iced coffee ready? Do you have it less sugar? A gray line appears: Check Product reads four rows from the Products tab. The agent doesn't guess, because its instructions require prices and stock to come from this tool. The question about variants is also answered from the Variants column in the same row. The answer is friendly and brief: ready, eighty-five thousand rupiah, twelve in stock, regular and less sugar variants. The agent also closes with a question: how many would you like? Just like a good admin. Let's match it against the source. In the Products tab, the one-liter palm sugar iced coffee row shows a price of eighty-five thousand, a stock of twelve, and regular and less sugar variants. Every number in the agent's answer comes from this row. If Dimas changes the stock to eight tomorrow, the agent's answer changes too, without resetting anything in n8n. The third place is the canvas. The run for Rina's first message shows a check mark on Check Product only. Log Order and Notify Dimas weren't touched, because Rina was only asking. The chat answer, the tool on the canvas, and the data in Sheets all match. The first scenario passes.
Step 3: Scenario 2: ordering two 1-liter coffees
The second scenario continues the same conversation. Rina replies: I'll take two regular ones, name is Rina, along with a WhatsApp number. The agent doesn't log it right away. It sends a summary: two one-liter iced coffees, regular, one hundred seventy thousand, plus ten thousand for city delivery, a total of one hundred eighty thousand. Then it asks: is this correct? Notice that the agent doesn't call Check Product again. The price and stock are already in the conversation memory from the previous message. That's what Simple Memory is for. Rina answers: yes, that's right. This is the approval point we've been waiting for. Without this answer, the Log Order tool would never be called. Only now does the agent call Log Order. One new row is added to the Orders tab. Then, following the order in the instructions, the agent calls Notify Dimas with a new order subject. Finally, the agent closes with a clear answer: the order is logged, and Dimas will reach out through WhatsApp about the address and payment. The agent doesn't claim to have received the payment, because that simply isn't its call. On the canvas, the run for the message yes, that's right shows green check marks on Log Order and Notify Dimas. Check Product wasn't used in this message. Within one message, the agent made a chain of decisions: read the memory, concluded the customer had agreed, logged the order, then sent the notification. We never drew any of that order as arrows on the canvas. The agent decided. If the order in your log is different, for example Notify Dimas is called before Log Order, make the order explicit in the task part of the system instructions, then test again.
Step 4: Checking results: a new row and a notification
Now open Google Sheets, the Orders tab. The two older rows for Budi and Sari are still intact at the top. The Log Order tool only adds rows; it never overwrites existing data. Below them is a new green row: October twenty-eighth at five past ten, Rina, the WhatsApp number, one-liter palm sugar iced coffee, regular, quantity two, total one hundred eighty thousand. The status is New, matching the value we locked. The time comes from the system clock, and the product name is the official name from the Products tab, not the shorthand from the chat. Compare this with Episode 32, when orders had to be copied by hand by Dimas. Now orders come in neat, complete, and consistent, even after hours. Switch to Dimas's inbox. The top email has the Orders label, sent by the agent at five past ten. Below it is the escalation email from the Putri test in the last episode, and a message from Laras. The content is complete: the name, WhatsApp number, product, total, status, and the action requested. Dimas just needs to contact Rina, confirm the address and payment, then change the status in Sheets to Processing. The final decision stays in human hands. Now the human part. Six minutes later, Dimas contacts Rina on WhatsApp, makes an introduction, and asks for the full address. Rina replies that the order goes to the office, and shares a location. The agent deliberately didn't ask for the full address, because its instructions limit the data collected to just the name and WhatsApp number. Dimas states the same total the agent logged, one hundred eighty thousand, along with the payment method and an estimated delivery time. The delivery time promise is made by Dimas, not the agent. Rina transfers the money. The agent handles the repetitive part, and Dimas handles the part that needs trust and decisions. This kind of division of work is our goal. Once the payment arrives, Dimas opens the Orders tab and changes Rina's status from New to Processing. This status change stays manual on purpose, following the division of roles from Episode 32.
Step 5: Scenario 3: out of stock and edge cases
The third scenario, in a new session. Sari writes: I'd like to order three bottles of cold brew for tomorrow. It sounds like an ordinary order, but the cold brew stock is zero. The agent calls Check Product and reads a stock of zero. This is where the data in Sheets is put to the test: if Dimas forgot to enter zero, the agent would accept an order that can't be filled. The answer is polite and honest: the cold brew is sold out right now. Then the agent offers an alternative that's in stock, and gives a second option: asking Dimas to let the customer know when cold brew is available again. The agent doesn't push. Sari chooses to be notified, and gives a name and WhatsApp number. The agent calls Notify Dimas, saying Sari is waiting for three bottles of cold brew. Notice that Log Order isn't called at all. There's no order for a product that isn't there. The agent closes with certainty: Dimas will reach out through WhatsApp. A tricky question, handled correctly without any help from us. Sari still feels looked after, even though the product is out of stock. The log for Sari's session on the canvas confirms the same thing. Check Product and Notify Dimas have check marks. Log Order is empty, and the Orders tab didn't grow. This is what we mean by an agent making decisions. From a message that sounds like an order, the agent decided not to log it, because the stock data said otherwise. We test the first edge case right away. Andi wants to order fifteen one-liter iced coffees for a gathering on Saturday. The agent checks the data: twelve in stock. The agent doesn't flatly refuse, and doesn't promise fifteen either. It states the available stock, then gives two options: order twelve for now, or pass it to Dimas to check on extra production. Andi chooses to have it passed to Dimas, and gives a name and WhatsApp number. The agent calls Notify Dimas, and once again logs nothing. Whether the kitchen can make three extra liters before Saturday is a decision for Laras and Dimas, not the agent. Let's sum up the edge cases you must test. First, a quantity above stock, like the one we just saw: state the available stock, offer twelve, or pass it to Dimas. Second, a product that isn't on the menu, such as iced tea. The agent just says it's not available and names the products that are, without making anything up. Third, a customer who won't give a WhatsApp number. The agent explains that Dimas uses the number for confirmation, and doesn't log an order without one. Fourth, messages outside opening hours, for example at eleven at night. The agent may still log the order, but says that Dimas will process it after eight in the morning. Fifth, a customer who changes the quantity after the summary. The agent makes a new summary and asks again, like the Rina test in the last episode. If any case fails, fix the instructions, then test again. Save this list of cases as a test sheet. Every time you change the instructions, tools, or data, run all the cases again. This simple habit stops a small fix from breaking something else.
Step 6: Session 7 output: an agent that decides and acts
Congratulations. You've completed the Session 7 output: an AI agent that can make decisions and take action. Not just a chatbot that answers, and not a rigid automation. Today we saw four real decisions. The agent chose its own tools. The agent refused to log an order when something was sold out. The agent asked for approval before changing data. And the agent knew when to call Dimas. All those decisions were made within the limits we set: limited tools, data from a single source, clear instructions, and a human who still holds the important decisions. An agent that's free without limits is actually dangerous for a business. Our admin agent turns out to be simple. Just seven nodes on the canvas. Just three tools, each with limited access: one reads, one adds a row, and one sends email to a locked address. There's one approval point that can't be skipped: the customer's confirmation before logging. And zero lines of code. Small, limited, and easy to check. That's exactly why this agent is safe to use in a real business. Compare that with what many people imagine AI agents to be: complicated and expensive. For a small business, a good agent starts from one clear task, tidy data, and just enough tools. Let's look back at the Session 7 journey. In Episode 31 we set up the AI Agent node with a model, memory, and a first tool. The agent started choosing tools on its own. In Episode 32, Google Sheets with Products and Orders became the source of truth. The agent stopped making up prices. In Episode 33, three tools let the agent read, log, and notify. In Episode 34, memory and system instructions kept the agent on track and in line. And today, a start-to-finish test proved the agent is ready to connect to real customers. This agent pattern can be moved to many kinds of work. Mr. Hendra can build a tutoring registration agent: check the remaining class seats, confirm, log the new student, then notify Mr. Hendra. Dewi can build an office supplies request agent for Maju Bersama Co.'s customers: check warehouse stock, confirm, log the request, then notify the warehouse team. Nadia can build a leads agent: explain the service packages from the data, collect what the prospect needs, log it, then notify Nadia. The pattern is always four steps: read the data, ask for confirmation, log, notify a human. Try writing down right now what those four steps would look like for your own business or work. Before real customers use the agent, run this checklist. First, the agent passes a test of ten real questions from your customers, including edge cases. Second, a monthly API usage limit is set in the model provider's dashboard, so costs stay under control. Third, the test rows in Sheets and the test emails are cleaned up, so Dimas doesn't process fake orders. Fourth, Dimas understands the status flow: New, Processing, Shipped, Done, and knows that emails labeled Escalation must be answered first. Fifth, the system instructions are also saved in a separate document, so they're easy to update when the shop rules change. If everything is checked, your agent is ready for the next stage.
Done!
Let's recap. The Sunset Coffee admin agent answers stock questions from Sheets, confirms orders, logs a new row only after the customer agrees, notifies Dimas, and handles sold-out items honestly. That's an AI agent that makes decisions and takes action. Right now the agent is still tested through the chat window in the editor. In Session 8 we connect it to where your customers are. Episode 36 covers the integration options: the WhatsApp Business API, third-party services, Instagram, and Telegram. See you in Episode 36.
Practice exercises
Try these on your own after watching to lock in what you learned.
Test your agent with ten real customer questions, including at least two edge cases (sold out, quantity above stock).
Note every answer that isn't quite right, then fix the tool description or System Message, and retest in a new session.
Challenge: add a fourth, read-only tool, for example Check Order Status by WhatsApp number, with a clear description.
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,276 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.
