n8n Full Course – Architect Scalable AI Automations from Scratch

Read the Portuguese translation →

Author: freeCodeCamp.org · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: n8n Full Course – Architect Scalable AI Automations from Scratch · Channel: freeCodeCamp.org · 42:35 · Watch on YouTube

Topics: AI agents, Task and workflow automation, Software engineering with AI, AI developer tools

Summary

The course presents n8n as an automation infrastructure for building scalable, AI-powered business workflows, rather than merely a simple integration tool. Through practical examples, it demonstrates core workflow patterns such as webhooks, API requests, AI agents, Google Sheets as a knowledge source, and short- and long-term memory. Later sections focus on production practices, including event-driven automation, human approval, error handling, monitoring, and token-usage tracking. The overall emphasis is on creating reliable systems that can be deployed and maintained beyond a demo.

Key points

• n8n workflows are built from triggers, connected nodes, data transformations, logic, and actions.
• Webhooks, app triggers, and database updates can start event-driven workflows without constant polling.
• The HTTP Request node connects n8n to REST APIs, with credentials stored securely rather than hard-coded into workflows.
• AI workflows can turn unstructured information into structured data, make decisions, and trigger real-world actions.
• AI agents can select tools to retrieve information, while ordinary workflow nodes handle predictable steps such as sending email.
• Google Sheets can serve as a lightweight database or knowledge base for agents, as well as a store for persistent conversation history.
• Multi-agent workflows can divide research, analysis, writing, and publishing into specialized stages.
• Human-in-the-loop approval helps prevent AI-generated content from being sent without review.
• Production workflows should retry failures, provide fallback responses, and notify their owners when errors occur.
• Monitoring execution time, failure rate, and AI token usage helps maintain workflow reliability and track costs.

Chapters

Start	Chapter	Summary
00:00	Course overview and n8n fundamentals	The course introduces n8n as an automation and orchestration platform and explains its workflow builder, deployment options, triggers, integrations, and execution monitoring.
04:40	Webhook-to-email workflow	A form submission flows through data cleanup, a company check, AI-generated personalization, and a Gmail message.
07:49	AI sales CRM chatbot	A chat workflow uses an AI agent, Google Sheets tools, conversation memory, and logging to answer sales questions using CRM data.
10:24	HTTP requests and API data	The HTTP Request node calls a search API, transforms its results into clean records, and appends them to Google Sheets.
13:02	Structured AI document processing	A document-processing workflow extracts fields from a shipping document, checks for missing information, and emails a human when review is needed.
15:40	AI agents and tool use	The video distinguishes an agent from a text-generating LLM and demonstrates an agent that searches the web before its result is emailed.
18:46	Google Sheets as an agent knowledge base	A Telegram chatbot uses an AI agent to look up company policies in Google Sheets and reply with information from matching rows.
21:53	Short-term and long-term AI memory	The workflow combines session memory with conversation history stored in Google Sheets so an assistant can recall prior interactions.
24:29	Multi-agent content pipeline	Four specialized agents research, outline, write, and package an article for publishing.
27:37	Event-driven lead qualification	A form webhook triggers AI lead analysis, CRM logging, and a Slack alert only for leads that meet the hot-lead threshold.
32:16	Human approval in the loop	An AI-generated sales email is sent to Slack for approval, and Gmail sends it only if a reviewer approves it.
34:50	Error handling for a persistent chatbot	The chatbot workflow adds retries, a fallback message for users, and a Telegram error alert for its owner.
37:56	Workflow monitoring and observability	The final section tracks execution time, failure rate, and AI token usage with Google Sheets logs and Telegram alerts.

Quotes

NAT is an automation infrastructure and orchestration engine, a backend for intelligent workflows. — 01:02

An agent is a decision system. It can choose tools and retrieve real data instead of just replying with a paragraph. — 15:40

Production systems don’t poll, they react. — 27:37

AI does the work. A human gives the okay, then the action happens. — 32:16

A workflow running in production with zero visibility is a workflow you’re flying blind on. — 39:28

Concepts and entities

n8n, Rahul Jooshi, TechDome, Google Sheets, Telegram, OpenAI, SERP API, Zapier, AWS

Full transcript (original language)

00:00 Learn AI automation with NAN. This course from Rahul Jooshi will take you from NAN fundamentals to building real AI powered automation workflows like agents, integrations, and self-hosting. This course is aimed at developers and no code builders who want productionready skills. >> Imagine if your entire business could run on autopilot. Lead generation, content creation, customer support, everything automated. That’s exactly what tools like NAT make possible. But

00:31 here’s the thing. NAT is not just another automation tool like Zapier. It’s much bigger. Hi everyone, this is Rahul, co-founder and CEO of TechDome and also the number one creator on NAN. I’ve helped transform over 1200 plus businesses using automation frameworks and intelligent workflows. In this video, I’ll take you through the complete journey what NAT actually is, how it works, and how you can build real world automation systems from scratch. Most people think NAT is just another automation tool, but that’s the wrong way to look at it. NAT is an automation

01:02 infrastructure and orchestration engine, a backend for intelligent workflows. Zapier is just a small subset of what NAT can actually do. With NAT, you can automate entire business systems like lead generation pipelines, AI powered research workflows, fully automated customer support, data pipelines, internal operations. This isn’t just automation. This is building automation architecture. By the end of this video, you’ll understand advanced workflow design, API orchestration, AI agents inside NAT, vector databases,

01:34 event-driven systems, production deployment, self-hosting setup, and most importantly, how to design scalable systems. Now, let me walk you through how NAT actually looks outside the workflow builder. This is the NAT creator page where you’ll find readymade templates that you can use to get started quickly. If you’re just starting, you can download N8 directly from GitHub, run it locally, and test your workflows. There’s also a pricing version available. If you’re expecting around 2,00 to 2500 workflow executions,

02:05 you can start with the starter plan. But the real power of NAT comes with self-hosting. You can deploy it on your own infrastructure, whether that’s your company’s internal systems or your own cloud setup. You can use platforms like AWS, Azure, or any custom cloud environment. In this video, we’ll go ahead with a self-hosted setup using CBO cloud and I’ll show you how that works end to end. Now, let’s understand how NAN actually looks and works. So, once your setup is ready, this is how your N8 environment looks. You have your personal workspace and if you’re working

02:36 in a team, you can manage multiple users. You also have access controls, GitHub integration, and full visibility into your workflows. This is your canvas where all the automation happens. You can create workflows, connect nodes, and design systems visually. You can also track executions, see which workflows succeeded, which failed, and analyze performance over time. Every workflow in NA10 starts with a trigger. This is what initiates the automation. You can trigger workflows in multiple ways. Manually based on app events, on a

03:08 schedule, using web hooks, or even through chat interactions. For example, when a user submits a form, that can trigger an entire workflow automatically. Once the workflow starts, this is where the real power comes in. You can connect APs, transform data, and build complex logic. You can create loops, run parallel processes, and even introduce approval systems. For example, you can build a content creation system where content is generated, images and videos are created, the system waits for approval, and then publishes automatically. This is not just

03:39 automation, this is system design. N8 also allows you to integrate AI directly into your workflows. You can connect tools like OpenAI, Gemini or any LLM. This allows you to build AI agents, automate decision-m and create intelligent systems that can think and act based on data. One of the biggest advantages of NA10 is flexibility. You can run it locally, self-hosted, deploy it on any cloud infrastructure. This gives you complete control over your data, your workflows, and your system architecture. NATN also provides full

04:10 visibility into your automation. You can monitor workflow executions, success and failure rates, performance over time. This helps you optimize and scale your systems reliably. So, NAT is not just an automation tool. It’s a complete system to build scalable, intelligent business operations. If you’re serious about automation, AI, and building systems, this is something you need to master. In the next video, we’ll build a real world workflow step by step. Subscribe for more deep dives on automation, AI systems, and real world workflows. And

04:40 if you want access to ready-made workflows, drop a comment below. Have you ever wondered how a simple form submission can automatically trigger AI, make decisions, and send a personalized email, all without any human intervention? Hello, I’m Rahu Jooshi. This workflow demonstrates a core NA10 architecture. Data comes in via a web hook, gets cleaned, goes through a logic check, gets sent to AI, and finally delivers a personalized email. Let’s walk through each node. Step one, web hook trigger. This is where everything

05:11 starts. The web hook is set to a post method listening on the path architecture- demo. The moment an external source, a form, an app, or an API call sends data to this URL, the workflow fires. We have pinned test data on this node, a JSON object with three fields. This is what we use to test without needing a live external call. Hit test workflow and this data flows forward automatically. Step two, set map fields processing. This is a set node. It takes the row incoming JSON and maps

05:42 it into clean structured fields. It extracts name, email, and company directly from the incoming payload using enan expressions. It also adds a hard-coded field which isn’t in the incoming data but gets stamped on every record here. Open this node and you’ll see the input JSON on the left and the clean output on the right side by side. Step three, if has company logic or branching. This is the decision point. The if node checks one condition. Is the company field not empty? If yes, true

06:14 branch. Execution continues forward to the AI node. If no, false branch. Nothing happens downstream on that path. In our test data, company is acme, so it’ll always go true. But in a real scenario, you might route the false branch to a different email template, a Slack alert, or a CRM update for incomplete leads. Step four, open AI. Generate email AI node. This is where AI comes in. The node calls GPT4 mini with a dynamic prompt. Create a polite

06:45 follow-up for the person dollar.name. The name is pulled live from the previous node’s output. So, every execution gets a personalized prompt. The key thing to show here is the prompt field. Notice how the N8N expression injects live data directly into the AI call. The response comes back as message.content inside the JS which the next node picks up. Step five, Gmail send email output. Final step, the Gmail node sends the AI generated email. The body pulls directly from the open AI

07:17 nodes output. Open the execution log after a run and you’ll see the full JSON trail from web hook. all the way through to what Gmail actually sent. And that’s the full loop. Web hook in, data cleaned, logic checked, AI processed, personalized email out. This architecture is the backbone of most automation pipelines you’ll build in NAN. If you found this useful, subscribe. I break down more NAN builds every week. Drop a comment if you want me to cover a specific workflow next. See you in the next one. Imagine a sales CRM chatbot that actually thinks it

07:49 remembers conversations, pulls live data from Google Sheets, and never makes things up. Hey everyone, I’m Rahul Jooshi, and in this video, I’ll show you how to build a powerful AI powered sales CRM chatbot using GPT40 Mini, N8N, Google Sheets, and Memory, a system that can answer real sales questions in real time. Step one, when chat message received, chat [music] trigger. This node starts the workflow whenever a user sends a message in the N8N chat interface. It captures the user’s query along with the session ID enabling

08:21 real-time interaction. Step two, open AI chat model LLM. This node provides the core conversational intelligence. It powers reasoning, intent understanding, and response generation for the chatbot. Step three, AI [music] sales CRM router lang chain agent. This is the brain of the workflow. It understands the user’s question and decides whether to query Google Sheets for lead, outreach, or opportunity data. It never guesses and always looks up data first. Step four, outreach sheet. Google Sheets tool. This

08:52 node allows the AI to search the outreach automation sheet. It’s used for checking lead status, outreach progress, and proposal links when requested by the user. Step five, opportunity sheet, Google Sheets tool. This node lets the AI fetch opportunity and CRM deal details. It’s used for company level or pipeline related questions coming from the chat. Step six, conversation memory buffer. Memory window. This note stores the last few conversation turns. It enables multi-turn conversations so the

09:23 bot remembers recent context within the same session. Step seven, validate AI output payload if node. This node checks whether the AI produced a valid response. If output exists, the workflow continues. If not, the interaction is logged for debugging. Step eight, log invalid chat records to Google Sheets. Google Sheets. This node captures failed or malformed AI responses. It helps identify tool call or data issues without breaking the chatbot. Step nine, write chat memory to Google Sheets,

09:54 Google Sheets. [music] This node logs each conversation turn. It stores timestamp, session ID, user message, and AI response for tracking and analysis. Step 10, send chat response, chat response node. This node sends the final AI generated reply back to the user. It completes the chat loop with an instant response. If you found this workflow useful, hit like, subscribe for more AI automation tutorials, and I’ll see you in the next one. Welcome back. I Rahul Jooshi. In

10:24 this video, we are diving deep into the HTTP request node. The single most powerful node in NAT. Whether you want to connect to a CRM, a payment platform, an AI tool, or literally any SAS product with an API, this node is your gateway. By the end, you’ll have a live workflow that pulls company data from the web and saves it straight into Google Sheets. Let’s go. Step one. What is the HTTP request node? The HTTP request node lets you talk to any REST API. Get to fetch, post to send, put to update, delete to

10:55 remove. Authentication API key in the header or query param. Bearer token in the authorization header or two for Google or Salesforce. Basic O for username password APIs. For SER API, we’re using a query parameter. API key goes directly in the URL through an NAN credential. Never hardcode keys on the canvas. URL is serapi.com/arch. Query parameters engine equals Google. Q equals our search query. Num equals 10. API key pulls from the stored

11:26 credential. Hit execute. Raw JSON appears in the output panel. Most APIs pagenate. SER API returns a next underscore page token when there’s more. Check if it exists. Loop back. Fire another request. Repeat until it’s gone. Step two, data transformation. APIs return messy data. SER API gives us a huge JSON object with organic results, ads, knowledge panels. We only want the clean stuff. That’s what this code node does. We grab the organic underscore results array and map over it. Pulling out company name from title, website

11:58 from displayed underscore link, description from snippet, and source URL from link. We also stamp a scraped underscore at timestamp on every record. The output is a clean flat array, exactly what Google Sheets expects. Step three, saving to Google Sheets. Last stop, Google Sheets. The node is set to append mode, so it adds new rows every run without overwriting anything. Our column mappings connect each field from the code node straight to the right column. Hit execute and watch your sheet fill up live. And this node is totally

12:29 swappable. Air table, notion, a CRM, web hook, an email, whatever your stack looks like, just plug it in here instead. And that’s the HTTP request node from raw API call to clean structured data in Google Sheets in under 5 minutes. Grab the workflow JSON from the link in the description. Import it into your NAT. Drop in your SER API key and you’re live. If this was useful, I’ll drop one free workflow like this every week inside my school community. JSON file included, setup guide included, completely free. Over 130

13:02 people are already using these. Link in the description. Come join us. This is where automation becomes intelligent. Hi, I’m Rahul Jooshi. Today I want to show you how AI systems actually work inside NA10 using a real example. An AI that reads a shipping document and decides on its own whether it’s ready to process or needs a human to step in. Every AI workflow, no matter how complex it looks, breaks down into four steps. Input, AI analysis, decision, action. Once you can see this pattern, you’ll

13:33 recognize it in almost every AI automation out there, including this one. Step one, input. The input here is a bill of leading, a shipping document. In a real setup, this text would come from an OCR step or a document upload. Here, I’ve pinned a sample document directly onto this web hook node, so the workflow runs instantly for the demo. Step two, prompt engineering. Here’s a part that separates a working AI system from a broken one. Prompt engineering. If you just say, “Read this document,” you’ll get back a paragraph. And paragraphs don’t automate. Instead, we

14:05 tell the model exactly which fields to pull out. B number, shipper, consigne, vessel, ports, and we force the response into JSON. Step three, AI structured output. That’s what gives a structured output, a clean object with every field the AI found instead of a block of text a human has to reread. This code node takes that structured response and turns it into a predictable set of fields the rest of the workflow can actually use. Step four, decision. Now the workflow makes a decision. It checks whether the

14:35 required fields B number, shipper, consigne actually came back filled in. If any of them are missing, that’s a compliance risk. And the document needs a human to look at it. If everything’s present, it just gets logged and moves on. Step five, action. When something’s missing, the workflow doesn’t just fail quietly. It sends an email immediately, flagging exactly which document and which field needs attention. That’s the payoff. the AI’s decision actually triggers something in the real world instead of sitting in a log nobody reads. So to recap, input, AI analysis,

15:07 decision, action. That’s the shape behind every AI system in NAT. We used a bill of leading here because compliance is a great example of the AI needs to actually decide something. But this exact pattern works for invoices, support tickets, contracts, anything with structured information buried in unstructured text. If you want to keep building AI systems like this one, come join the free school community links below. I share free NAT and automations, step-by-step setup guides, and the actual JSON file for every workflow I

15:40 post a video on, including this one. So, if you want to just import this and start customizing it yourself, it’s already waiting for you there. Agents are the next step up from a normal AI workflow. Instead of just analyzing something and stopping, an agent can decide what to do, pick a tool, and go get a real answer on its own. Hi, I’m Rahul Jooshi. Today, I’ll show you a simple one. An agent that searches the web and emails you what it found. LLM versus agent. Quick distinction first. An LLM is just a text generator. You

16:10 give it words, it gives you words back. An agent is a decision system. It can choose tools and retrieve real data instead of just replying with a paragraph. In this workflow, the agent is this node here and the LLM is plugged into it, not the other way around. Agent architecture, the shape is always the same. User request, agent, select a tool, execute the action, return a result. Here, the request comes in through a chat trigger. The agent decides to search the web, and once it’s done, the result flows out to an email. Step one, the trigger. We start with a

16:42 chat trigger. That’s the user request step. A sample message here. Find highv value leads that closed this quarter with deal sizes over $50,000. So you can hit execute and watch it run without typing anything. Step two, the agent plus LLM. This is the agent. It needs a language model to actually reason. That’s this OpenAI chat model connected underneath it. The system message tells it exactly what its job is. Search for relevant information and summarize it clearly because that summary is about to get emailed out automatically. Step

17:12 three, the tool Google search via SER API. The only tool this agent has is a Google search through SER API. When it decides it needs current information, it calls this, gets real search results back, and folds them into its answer. One tool, one clear job. That’s often better than giving an agent five tools it barely uses. Step four, after the agent, send email. Now, here’s an important distinction. This send email node is not a tool the agent calls. It’s just the next step in the workflow. Once

17:43 the agent finishes and produces its final answer, that answer flows straight into this node and gets emailed out. The agent doesn’t decide to send an email. The workflow does that automatically every time. Let’s run it. The chat trigger fires with our pin request. The agent reads it, decides to search, pulls back results from SER API, writes a summary, and that summary lands straight in an email. So, user request, agent, one tool, a result, and then a plain old automation step to email it out. That

18:14 last part is worth remembering. Not everything after the agent needs to be another tool. Sometimes it’s just the next node in the chain. If you want to keep building AI systems like this one, come join the free school community. Links below. I share free NAT automations, step-by-step setup guides, and the actual JSON file for every workflow I post a video on, including this. See you in the next one. Hi, I’m Rahul Jooshi. In this video, I’ll show you how to use Google Sheets as a simple database for an AI agent inside NAT.

18:46 This is useful when you don’t need a full vector database setup, but still want your AI agent to answer from real company data like refund policies, shipping rules, cancellation terms, FAQs, or internal knowledge. By the end of this workflow, you’ll have a Telegram chatbot that receives a user question, searches the right row inside Google Sheets, sends that information to an OpenAI model, and replies back with an accurate answer. Step one, Telegram trigger. The workflow starts with the Telegram trigger node. This node listens for incoming Telegram

19:17 messages. When a user sends a question like, “What is our refund policy?” The workflow captures the message text and passes it into the AI agent. So, Telegram becomes the front-end chat interface for the user. Step two, AI agent. Next, the message goes into the AI agent node. This is the main brain of the workflow. The agent receives the user’s question from Telegram and decides how to answer it. Instead of guessing from the model’s memory, the agent is instructed to use the connected Google Sheets tool whenever the user asks about company

19:49 policies, refunds, shipping, cancellations, warranty, or company information. This is what makes Google Sheets work like a lightweight knowledge base. Step three, open AAI chat model. The OpenAI chat model is connected to the AI agent as the language model. This model helps the agent understand the user’s question, decide when to use the sheet, read the return data, and generate a clean natural language answer. In this workflow, the model is used for reasoning and response generation, while

20:20 the actual company knowledge comes from Google Sheets. Step four, knowledgebased sheet. The knowledgebased sheet node is connected to the AI agent as a tool. This node searches the Google sheet and returns matching rows based on the user’s question. For example, if the user asks about the refund policy, the tool looks for the matching row in the sheet and returns fields like question, answer, and category. This is the key idea of the workflow. The sheet acts as the database and the AI agent uses it only

20:50 when needed. Step five, telegram send answer. After the AI agent creates the final response, the workflow sends it back through the Telegram send answer node. The user receives a clear answer directly inside Telegram based on the matching row from Google Sheets. For example, if the sheet contains the refund policy, the bot can reply with the exact refund window, processing time, and payment method details. That’s the complete Google Sheets as a database workflow in NAT. It takes a user question from Telegram,

21:21 sends it to an AI agent, uses Open AI for reasoning, searches Google Sheets as the knowledge base, and replies back to the user with an accurate answer. This is a simple no vector DB br alternative for small and medium knowledge bases, FAQs, policy boards, internal support agents, MVPs, demos, and client projects. You don’t need Pine Cone, Superbase, VV8, or embeddings for every use case. Sometimes a clean Google sheet is enough. If you want to keep building AI systems like this one, come join the free school community links below. I

21:53 share free innate and automations, step-by-step setup guides, and the actual JSON file for every workflow I post a video on, including this. See you in the next one. Hi, I’m Rahul Jooshi. In this video, I’ll show you how AI memory systems work inside NA10. Memory is what separates a real AI assistant from a chatbot that forgets you the second you close the chat. Today, I’m breaking down the two types of AI memory. short-term and long-term and building a persistent AI assistant that actually remembers your past conversations even after N8N restarts.

22:24 There are two types of memory you need to know. Short-term memory is your conversation memory. It holds context only for the current session. In N8, that’s this node simple memory buffer window. Great for follow-up questions, but the moment the session ends, it’s gone. Long-term memory is different. It’s persistent. It’s stored in an actual database. So the AI can recall things from days, weeks, even months ago across restarts and different sessions. To build long-term memory, we store every conversation turn in a database. I’m using a Google sheet to keep this simple and visual. The schema is just

22:55 four columns. User ID, message, response, and time stamp. You can see it right here in the node. Every time the user sends a message and the AI replies, we log that turn as a new row. Over time, this becomes the AI’s memory bank. Here’s the full workflow. Telegram trigger brings in the user’s message. Before the AI agent even runs, we hit get conversation history. This pulls every past row from the sheet that matches this user ID. You can see the retrieved rows right here in the output. A code node formats that into a clean

23:26 text block which gets injected straight into the agent system message. So, the model literally reads the user’s history before it ever responds. The agent also has the OpenAI chat model as its brain plus simple memory for short-term insession context. After it replies, we log this new turn back into the sheet, then send the answer back on Telegram. That’s the loop. Retrieve history, respond, save history. Let’s test it. I’ve already got a past conversation logged for my test user. I asked to order a red t-shirt in size M, and the

23:58 AI confirmed it. Now, in a brand new session, I’ll ask something that only makes sense if the AI remembers that. It pulls my history, finds the red t-shirt order, and answers correctly. Even though this is a completely fresh chat session, that’s long-term memory working. This pattern is huge for support BS, personal assistants, or any use case where users come back days later expecting the AI to remember them. And because it’s just a sheet behind the scenes, you can inspect, edit, or even manually correct the AI’s memory anytime. Grab the full workflow. to JSON

24:29 from the link below. And if you want to go deeper on building AI agents like this, join the AI automation club link in the description. See you in the next one. Most people build one AI agent and stop there. But real automation systems, the ones companies actually run on, don’t use one agent. They use a team of agents. Hi, I’m Rahul Jooshi. Today I’m going to show you how to build a multi-agent content system in NAT. Four AI agents, each with one job, working together to take a single topic and turn it into a fully published article

25:01 automatically. Here’s a problem with a single AI agent doing everything. The prompt gets bloated, the model gets confused about what it’s supposed to be doing right now, and quality drops. The fix is simple. Split the job. Think of it like a small team. One person researches, one plans, one writes, one publishes. Each person is only good at one thing, but together they produce something none of them could do alone. That’s exactly what we are building. Here’s the pipeline. A research agent, an analysis agent, a writing agent, and a publishing agent. The output of one

25:33 becomes the input of the next. The research agent only researches. It’s not allowed to write anything. The analysis agent only turns that research into a structured outline. The writing agent only writes the article from that outline. and the publishing agent only packages the final piece. SEO title, meta description, tags, and marks it ready to go. Let’s build it. First, a web hook trigger. This is what kicks off the whole system when a topic comes in. I’m pinning some test data here so I can run the whole workflow instantly without

26:03 waiting on a real web hook call. Next, the research agent. Notice the system prompt. I’m explicitly telling it, “Your only job is research. Hand off clean notes. Don’t write the article.” Then the analysis agent picks up those notes and turns them into a JSON outline, title, hook, and section headings. I’m forcing structured JSON here. So the next agent has something clean to work with. The writing agent takes that outline and writes the full article in markdown. Intro, each section, a conclusion with a call to action. Finally, the publishing agent. This one

26:35 packages everything. SEO title, meta description, tags, and marks the status as published. I added one small code node after that parse publish package just to safely parse that JSON in case the model wraps it in markdown fences. Let’s run it live. I’ll hit execute and watch. Research agent kicks in first. Now analysis is structuring the outline. Writing agent is drafting the full piece. And there it is. Publishing agent packaged it and marked it published. One topic in, one finished article out

27:06 completely handsoff. That’s a real multi-agent system, not just a fancy name. an actual pipeline where each agent has a specialized role. If you want the ready to import JSON for this exact workflow, comment agents and I’ll send it your way. And if you’re building automations like this regularly, join the school community links in the description. See you in the next one. Hi, I’m Rahul Jooshi. In this video, I’ll show you how to build an AI agent for lead qualification in NA10. Most people building automation start with a

27:37 chron job. Every 15 minutes, check if something changed. every hour pull the API and it works until you’re running it 96 times a day just to catch the one moment something actually happened. Production systems don’t poll, they react. Something happens, a form gets submitted, a payment clears, a row gets updated, and the automation fires the instant it happens, not on the next schedule check. That’s the whole idea behind event-driven systems, and it’s what we’re building in this section. An event source is anything that can tell your automation something just happened.

28:09 There are three you’ll use constantly. One, web hooks. The most universal event source there is. Any tool that can send an HTTP request, which is basically every modern tool, can ping your workflow the second something happens. Website forms, payment processors, chat platforms. If it has a web hook option, you don’t need to poll it ever. Two, app triggers. These are the pre-built appspecific version of a web hook. Instead of you configuring a raw web hook URL, the app node itself listens for you. A new type form submission, a

28:40 new calendarly booking, a new stripe charge. Same underlying idea, less setup. Three, database updates. When the event isn’t someone submitted a form, but a row changed, a status flipped, a new record got inserted, you listen at the database layer. Air Table, Postgres, Google Sheets all have trigger nodes that watch for rowle changes and fire the moment they happen. Here’s the thing I want you to take away. All three of these are interchangeable at the front of your pipeline. Whatever fires the event, everything downstream, the

29:10 processing, the logic, the alerts stays exactly the same. You’re not rebuilding your automation for every new event source. You’re just plugging a different trigger into the same pipe. Let’s make this concrete with the pipeline we are building today. Website form to web hook to AI analysis to CRM entry to Slack alert. Walk through it with me. Someone fills out a form on your website. That submission fires a web hook, the event source. AI analyzes the message, scores the lead, detects intent and urgency, then logs everything into your CRM. And

29:42 only if the lead is hot, your team gets alerted. No spreadsheet checking, no polling every 10 minutes. One form submission triggers the whole pipeline in seconds. And notice the filtering at the end. Not every event deserves a notification. Every lead gets logged. Only the hot ones interrupt a human. That distinction is what separates a genuinely useful automation from one that just adds noise. Let’s build this live. I’ve already got the JSON ready to import. You’ll have it too. So, let’s walk through what’s actually happening node by node. The web hook. This is our

30:12 event source web hook- website lead form. It’s listening on a post endpoint. Copy this production URL. And that’s what you’d point your actual website form at. The moment a submission lands here, the workflow wakes up. For this demo, I’ve pinned two sample submissions on this node, a hot lead and a cold one, so we can see both outcomes without waiting on a real form. AI analyze lead takes the name, email, company, and message, and returns a structured judgment, a lead score out of 10, the intent behind the message, urgency, and

30:44 a oneline summary a salesperson can skim in 2 seconds. That raw AI output gets cleaned up in code- parse lead analysis which pulls the original form fields back in and normalizes everything into one flat object. Timestamp, name, email, company, message, lead score, intent, urgency, summary. I’ll trigger a test run now and show you the actual output live. CRM entry. Every single lead, hot or not, gets logged to Google Sheets in Sheets. Add CRM entry. This is our

31:14 system of record. Nothing gets lost. Even the leads that don’t go anywhere. The filter if hot lead checks is this lead score seven or higher. If yes, it goes to Slack. Hot lead alert. Realtime ping to the all NA10 automations channel with the lead’s name, company, and that AI written summary. If no, nothing happens. No Slack message, no interruption. It’s already sitting safely in the CRM sheet for whenever someone gets to it. One thing worth pointing out in the Slack node, instead of pulling name, company, summary, and

31:45 urgency off the sheets output, it reaches back and reads them straight from code parse lead analysis. That’s a handy pattern. Anytime a downstream node’s output doesn’t carry every field you need forward, you’re not stuck with whatever the last node returned, you can always reach back to an earlier node by name. That’s event- driven automation. one event source, a clean pipeline, and a filter at the end. So only what matters actually reaches a human. If you want to keep building AI systems like this one, come join the free school community links below. I share free NAT

32:16 automations, step-by-step setup guides, and the actual JSON file for every workflow I post a video on, including this. See you in the next one. Hi, I’m Rahul Jooshi. So far, we’ve been building fully automatic AI workflows. No humans involved. But here’s the truth. Not everything should run on autopilot. Some things need a real person to say yes, send it before it goes out. This is called human in the loop. And today I’ll show you how to build one in NA10. Here’s the idea in one line. AI does the work. A human gives the okay, then the action happens.

32:48 Why does this matter? Because AI can write something that’s slightly wrong, off-brand, or just weird. And if that goes straight to a real customer, that’s a problem. So instead of sending automatically, we pause the workflow and ask a human first. Here’s our example. The AI writes a sales email for a new lead. Instead of sending it right away, we send that draft to Slack with two buttons, approve and reject. The workflow literally pauses and waits. Nothing happens until a human clicks one of those buttons. If they click approve, the email goes out for real. If they

33:19 click reject, nothing is sent at all. Let’s build it step by step. First, a web hook trigger. This is what starts the workflow when a new lead comes in. I have pinned some sample lead data here so we can test this instantly without waiting on a real request. Next, the sales email writer. This is just an AI agent with one job. Look at the lead’s name and context and write a short, friendly sales email. Nothing fancy, just a good first draft. Now, here’s the important part, the Slack node. I’ve set this to send and wait for response, which means it posts the draft into

33:49 Slack with approve and reject buttons, and the workflow literally stops right there. It won’t move forward until someone clicks something. After that, an if node checks was it approved? If yes, we go one way. If no, we go another. On the reject path, nothing happens. I just added a simple no operation node. So, the workflow ends cleanly. On the approved path, a Gmail node actually sends the email to the lead. Now, let’s see the workflow in action. The AI creates the sales email draft first, then sends it to Slack for approval.

34:19 Once the human reviewer clicks approve, the workflow continues and sends the email for real. If the reviewer clicks reject, the workflow stops cleanly and nothing gets sent. That’s human in the loop. A simple but powerful pattern. Anytime AI is doing something that a mistake would actually cost you. If you want this exact workflow, comment approve and I’ll send you the JSON. And if you’re building automations like this, come join the school community links below. See you in the next one. Hi, I’m Rahu Jooshi. In an earlier video, we built a persistent AI chat

34:50 assistant in NA10. It used telegram, Google Sheets, AI agent and memory to remember past conversations even after the workflow restarted. But there’s one problem. If the Google Sheets call fails or the AI agent times out or the conversation log does not save, the workflow can fail silently. The user sends a message and gets nothing back. So in this video, we’ll fix that by adding proper error handling to the same workflow. We’ll add retries, fallback responses for the user, and a separate Telegram alert for the workflow owner. Before we add error handling, here’s

35:21 what the original workflow does. A message comes in from Telegram. Then we pull the user’s past conversation history from Google Sheets. After that, we format the history and send it into the AI agent. The AI agent uses the previous history along with memory to generate the reply. Then we log the new conversation turned back into Google Sheets. Finally, the response is sent back to the user on Telegram. The important thing is this. Three parts of this workflow depend on outside services. Google Sheets, the AI agent and Google Sheets again and any one of them can fail. Step one, Telegram

35:53 trigger. We start with Telegram trigger. This node listens for new Telegram messages. Whenever a user sends a message, this workflow starts. Step two, get conversation history. Next, click get conversation history. This node reads the user’s past chat history from Google Sheets. Since it depends on an external service, this is one of the places where failure can happen. Step three, format history. Next, click format history. This prepares the previous messages in the right format for the AI agent. We are not changing this node because it is an internal

36:24 formatting step. Step four, AI agent. Now click AI agent. This node generates the chatbots reply because AI calls can time out or fail. We need error handling here too. Step five, open AI chat model. Under the AI agent, we have open AI chat model. This is the model provider connected to the AI agent. We are not changing it directly in this video. Step six, simple memory. Next is simple memory. This gives the AI agent short-term memory during the conversation. This node also stays the

36:54 same. Step seven, lock conversation turn. Now click lock conversation turn. This saves the latest user message and AI response back into Google Sheets. Since this is another external service call, it also needs error handling. Step eight, Telegram send answer. Next is Telegram send answer. This is the normal success path. If everything works, the AI response goes back to the user here. Step nine, notify error to user. Now add notify error to user. Connect the error paths from get conversation history AI

37:26 agent and log conversation turn into this node. If anything fails, this sends the user a simple fallback telegram message. That’s the difference between a demo workflow and a production ready workflow. The chatbot still uses the same Telegram trigger, Google Sheets history, AI agent, memory, and response flow, but now it fails gracefully. If an external service fails, the workflow retries first. If it still fails, the user receives a fallback message. And if the workflow itself breaks, the owner gets a telegram alert with the error

37:56 details. So instead of silent failure, you get visibility, reliability, and a much better user experience. Comment errors and I’ll send you this updated workflow. And if you’re building automations that need to work in the real world, come join the school community. Link is below. See you in the next one. Hi, I’m Rahul Jooshi. In this video, I will show how to monitor N8 workflows automatically before they fail. Quick question. If one of your automations started failing right now, would you know? Not eventually when a customer messages you asking why they

38:27 never got their email or why the bot went quiet. Right now, today, for most people building with N8, the honest answer is no. And that’s actually completely normal because when you’re first learning automation, you’re focused on just getting the workflow to work at all. Nobody teaches you what happens after that. But here’s the thing, building the workflow is actually the easy part. Keeping it healthy once it’s live, that’s a completely different skill. And it’s the one skill that separates someone who builds automations as a hobby from someone who can actually

38:57 run them for real clients or for their own business without constantly babysitting them. So today I want to walk you through something a lot of tutorials skip completely. Monitoring and observability. It sounds like a big technical DevOps kind of term, but honestly what we’re building today is simple. No fancy tools, no expensive software. Just three things you track using tools you probably already have sitting right there in your NAT setup. Google Sheets and Telegram. By the end of this video, you’ll have a working system that tells you the moment something goes wrong instead of you

39:28 finding out the hard way. Here’s the mindset. A workflow running in production with zero visibility is a workflow you’re flying blind on. You don’t need anything fancy. You just need to track three things. Execution time, how long each run takes, because a sudden spike usually means something slow or stuck. Failure rate, what percentage of runs are erroring out, because one failure is normal, but a rising trend isn’t. And AI token usage, how many tokens each AI call is burning, because that’s directly tied to your bill. To track that, you need three

40:00 tools working together. Logs, a record of what happened and when, alerts, a ping the moment something crosses a line you care about, and a metrics dashboard, a place to see trends over time, not just one number in isolation. We’re building all three today using tools you already have, Google Sheets and Telegram. Let’s build the first piece, the metrics logger. It starts with a schedule trigger set to run every hour that calls get recent executions which hits NA10’s own API to pull your recent execution history. I’ve pinned sample data here so we can test it instantly.

40:32 That data goes into calculate metrics, a small code node that does the math, total executions, how many failed, the failure rate as a percentage, and the average execution time in seconds. Those numbers get logged as a new row in a Google sheet. That’s our logs and our dashboard in one place. Since a sheet full of hourly rows already shows you trends over time, then an if note checks, is the failure rate 10% or higher? If yes, a telegram message fires immediately telling you exactly what’s going on. If everything’s fine, nothing

41:03 happens. No noise, just silence when things are actually okay. Now, the second piece, completely separate token usage tracking. Anytime you use an AI agent node, its response actually includes a token usage object. Prompt tokens, completion tokens, total tokens. Most people never look at this. Here I’ve got a sample AI response pin. So you can see the shape of it feeding into extract token usage. A tiny code node that just pulls those numbers out and then it logs straight into its own sheet tab. The point of this block isn’t that

41:34 you run it on its own. It’s that you copy this exact pattern into any AI agent node you already have and suddenly every AI call you make is tracked for cost. Let’s run both metrics logger first. Execute and there it is. Total runs, failure rate, average time all logged. And since one of our sample executions failed, watch the alert fires on Telegram immediately. Now the token tracker execute and you can see the prompt completion and total tokens

42:04 logged cleanly. ready to add up over time. And that’s really it. That’s the whole system. No expensive monitoring platform, no complicated setup, just a schedule check, a sheet acting as your logs and your dashboard, and a telegram alert as your early warning system. It’s genuinely one of those things that takes 20 minutes to set up once and then quietly saves you from a disaster down the line. The kind where a workflow’s been silently failing for 2 days and you only find out because a client asks where their automation went. If you’re serious about running automations that

42:35 actually hold up long-term, not just demo quality workflows, but ones you can trust in production, this monitoring layer is non-negotiable. Set it up once on your most important workflows and just forget about it until it actually pings you. Comment monitor below and I’ll send you this exact workflow sheet template included so you can plug it in today. And if you want more builds like this, the kind that make your automations production ready, not just demo ready, come join the school community. Links right below this video. See you in the next one.