6 Months of Building AI Agents in 43 Minutes (without the hype)

Everyone is talking about AI agents right now, and we are living in such a cool time because with zero coding background, you can get in there and leverage these tools and build some really cool AI systems. If you guys don't know me, my name's Nate. I have zero programming background, and around 6 months ago, I started experimenting with implementing AI into automations. And today, I'm running an AI automation agency where we help clients scale their business without increasing headcount. And we do this all using no-code tools like N8N. I also run a community that's focused on helping others learn how to build these AI agents, again, with zero coding background. So if this kind of stuff sounds interesting to you, make sure to watch this video all the way to the end and definitely check out my community. The link for that will be down in the description. But anyways, let's get right into this one. Because everyone's talking about this kind of stuff, there's a lot of hype and there's a lot of noise to cut through. So the first thing I want to do is talk about the hard truths about AI agents, and then I'll get into the 7 lessons that I've learned over the past 6 months building these things. So the first one is that most AI agent demos online are just that, they're demos. So the kind of stuff that you're going to see on LinkedIn, blog posts, YouTube, admittedly my own videos as well, these are not going to be production-ready builds or production-ready templates that you could immediately start to plug into your own business or try to sell to other businesses. You'll see all sorts of cool use cases like web researchers, salespeople, travel agents. Just for some context, these are screenshots of some of the videos I've made on YouTube. This one is like a content creator. This one is a human-in-loop calendar agent. We've got a technical analyst. We have a personal assistant with all its agents over here, stuff like that. But the reality is that all of these pretty much are just gonna be, you know, proof of concepts. They're meant to open everyone's eyes to what this kind of stuff looks like visually, how you can spin this kind of stuff up, the fundamentals that go into building these workflows. And at least me personally, my biggest motivation in making these videos is to show you guys how you can actually start to build some really cool stuff. With zero programming background. And so why do I give all those templates away for free? It's because I want you guys to download them, hit run, see the data flow through, and understand what's going on within each node rather than being able to sell that or use it directly in your business. Because everyone has different integrations, everyone's gonna have different system prompting, and different little tweaks that they need for an automation to be actually high value for them. Besides that, a lot of this is meant to be within a testing environment, but if you push it into production and you expose it to all the different edge cases and tons of different users, things are going to come through differently and the automation is going to break. And what you need to think about is even these massive companies in the space like Apple, Google, Amazon, they're also having issues with AI reliability, like what we saw with Apple Intelligence having to be delayed. So if a company like this with a massive amount of resources is struggling with some of these production-ready deployments, then it's kind of unrealistic to think that a beginner or a non-programmer in these tools can spin up something in a few days that would be fully production ready. And by that, I just mean like the stuff you see online. You could easily get into NN, build something, test it, and get it really robust in order to sell it. That's not what I'm saying at all. Just kind of the stuff you see online isn't there yet. Now the second thing is being able to understand the difference between AI agents and AI workflows. And it's one of those buzzwords that everyone's kind of calling everything an agent when in reality, that's not the truth. So a lot of times people are calling things AI agents even if they're just sort of like an AI-powered workflow. Now, what's an AI-powered workflow? Well, as you can see right down here, this is one that I had built out, and this is an AI-powered workflow because it's very sequential. As you can see, the data moves from here to here to here to here to here to here, and it goes down that process every time, even though there are some elements in here using AI, like this basic chain and this email writing agent. Now, this has a fixed amount of steps and it flows in this path every single time, whereas something over here like an AI agent, it has different tools that it's able to call, and based on the input, we're not sure if it's gonna call each one once, or it's gonna call this one 4 times, or if it's gonna call this one and then this one. So that's more of a non-deterministic workflow, and that's when you need to use something like an AI agent. The difference here is that it's choosing its own steps. The process is not predefined, meaning every time we throw an input, we're not sure what's gonna happen and what we're gonna get back. And then the agent also loops, calls its tools, it observes what happens, and then it reloops and thinks about it again until it realizes, okay, Based on the input, I've done my job, now I'm going to spit something out. And so here's just a different visualization of, you know, an AI agent with an input, the agent has decision, and then there's an output. Or this AI workflow where we have an input, tool 1, LLM call, tool 2, tool 3, output. Where it's going to happen in that process every single time. And the truth is that most problems don't require true AI agents. They can simply be solved with building a workflow that is enhanced with AI. And a common mistake, and I think it's just because of all the hype around AI agents, is that people are opting straight away to set up an agent. Like, in this example right here, let's say the input is a form trigger, where we're getting a form response. We're using this tool to clean up the data. We're using this LLM call, so it's an AI-enhanced workflow, to actually write a personalized email. We're using this to update the CRM, and then we're using this to send the email, and then we get the output back as the human. We can also set this up as an AI agent, where we're getting the form response, We're sending this agent the information and it can choose, okay, first I'm going to clean the data and then I'm gonna come back here and think about it and then I'm going to update the CRM and then I'm gonna create an email and then I'm gonna send the email and then I'm gonna output and respond to the human and tell it that, you know, we, we did that job for you. But because this process is pretty linear, it's going to be a lot more consistent if we do a workflow. It's gonna be easier to debug, whereas over here the agent may mess up some tool calls and do things in the wrong order. So it's better to just structure it out like that. And so if we start approaching using these no-code tools to build AI workflows first, then we can start to scale up to agents once we need more dynamic decision-making and tool calling. Okay, but that's enough of the harsh truths. Let's get into the 7 most important lessons I've learned over the 6 months of building AI agents as a non-programmer. So the first one is to build workflows first. And notice I don't even say AI workflows here. I say workflows. So over the past 6 months of building out these systems and hopping on discovery calls with clients where I'm trying to help them implement AI into their business processes, we always start by, you know, having them explain to me some of their pain points. And we talk through processes that are repetitive and processes that are a big time suck. And a lot of times they'll come in, you know, thinking they need an AI agent or two. And when we really start to break down this process, I realize this doesn't need to be an agent. This could be an AI workflow. And then we break down the process even more. And I'm like, we don't even need AI here. We just need rule-based automation. And we're going to send data from A to B. And just do some manipulation in the middle. So let's look at this flowchart, for example. Here we have a form submission. We're gonna store data. We're gonna route it based on if it's sales, support, or general. We'll have that ticket or notification, send an automated acknowledgement, and then we'll end the process. So this could be a case where we don't even need AI. If we're having the forms come through and there's already predefined these 3 types, which are either sales, support, or general, that's a really easy rules-based automation. Meaning does inquiry type equal sales? If yes, we'll go this way and so on and so forth. Now maybe there's AI we need over here to actually send that auto acknowledgement, or it could be as simple as an automated message that we're able to define based on the inquiry type. Now, if this, the form submission is just a block of text and we need an AI to read it, understand it, and decide if it's sales, support, or general, then we would need AI right here. And that's where we would have to assess what the data looks like coming in, and then what we need to do with the data. So it's always important to think about, do we even need AI here? Because a lot of times when we're trying to cut off some of that low-hanging fruit, when we realize that we're doing some of this stuff too manually, we don't even need AI yet. We're just gonna create a few workflow automations, and then we can start getting more advanced with adding AI in certain steps. So hopefully this graphic adds a little more color here. On the left, we're looking at a rule-based sort of filter, and on the right, we're looking at an AI-powered filter. So let's take a look at the left one first. We have incoming data. So let's just say we're routing data off based on if someone's budget is greater than 10 or less than 10. Hopefully it's greater than 10. Um, so the filter here is, is X greater than 10? If yes, we'll send it up towards Tool 1. If no, we're going to send it down towards Tool 2. And those are the only two options because those are the only two buckets that a number can fit into. Unless I guess it's exactly equal to 10. I probably should have made this sign a greater than or equal to, but anyways, you guys get the point. Now over here, if we're looking at an AI-powered sort of filter right here, we're using a large language model to evaluate the incoming data, answer some sort of question, and then route it off based on criteria. So incoming data, we have to look at, or sorry, not we, the AI is looking at what type of email this is. Because this uses some element of reasoning or logic or decision-making, something that actually needs to be able to read the context and understand the meaning of what's coming through, in order to make that decision. This is where before AI, we would have to have a human in the loop. We'd have to have a human look at this data and analyze which way it's gonna go rather than being able to write some sort of code or filter to do so because it's more than just like what words exist. It's actually like how, when these words come together in sentences and paragraphs, what does it mean? So AI is able to read that and understand it. And now it can decide if it's a complaint, if it's billing, or if it's promotion. And then based on what type it is, we'll send it off to a different tool to take the next action. So the big takeaway here is to find the simplest approach first. You may not even need an agent at all, so why would you add more complexity if you don't have to? And also, if you start to learn the fundamentals of workflow automation, data flow, logic, creative problem solving, all that kind of stuff, it's going to make it so much easier when you decide to scale up and start building out these multi-agentic systems as far as, you know, sending data between workflows and understanding routing, your life's gonna be a lot easier. So only use AI where it actually is gonna provide value. And also using AI and hitting an LLM isn't free typically. And I mean, if you're self-hosting, but anyways, it's not free. So why would you want to spend that extra money in your workflow if you don't have to? You can scale up when you need the system to decide the steps on its own, when you need it to handle more complex multi-step reasoning, and when you need it to control usage dynamically. And I highlighted those 3 words because that's very like human sounding, right? Decide, reason, dynamic. Okay, moving on to lesson number 2. This is to wireframe before you actually get in there and start building. One of the biggest mistakes that I made early on, and that I see a ton of people making early on, is jumping straight into their builder, whatever it is, and trying to get the idea in their head onto a canvas without mapping it out at all. And this causes a lot of problems. So the 3 main ones here are you, you start to create these messy, overcomplicated workflows because you haven't thought out the whole process yet. You're gonna get confused over where you actually need AI and where you don't, and you may end up spending hours and hours debugging, trying to revise, um, all this kind of stuff because you didn't consider either a certain integration upfront or a certain functionality upfront, or you didn't realize that this could be broken down into different workflows and it would make the whole thing more efficient. I can't tell you how many times when I started off building these kind of things that I got almost near the end and I realized I could have done this with like 20 less nodes, or I could have done this in 2 workflows and made it a lot simpler. So I end up just deleting everything and restarting. So what we're looking at right here are different Excalidraw wireframes that I had done. As you can see, I kind of do them differently each time. There's not really a, you know, defined way that you need to do this correctly, or correct color coding or shapes. The idea here is just to get your thoughts from your head onto a paper or onto a screen and map it out before you get into your Workflow Builder. Because then in the process of mapping things out, you're going to understand, okay, there may be some complexities here, or I need all of this functionality here that I didn't think of before. And this isn't really to say that there's one correct way to wireframe. As you can see, sometimes I do it differently. There's not like a designated schema or color type or shape type that you should be using. Whatever makes sense to you, really. But the idea here is even if you don't want to wireframe and visually map stuff out, it's just about planning before you actually start building. So how can you break this whole project? You know, a lot of people ask me, I have an input and I know what that looks like and I know what I want to get over here, but in between I have no idea what that looks like. So how can we break this whole project into workflows? And each workflow is going to have like individual tasks within that workflow. So breaking it down to as many small tasks as possible makes it a lot more easy to handle, makes it a lot less overwhelming than looking at the entire thing at once and thinking How do I get from A to Z? And so what that looks like to either wireframe or to just write down the steps is you want to think about what triggers this workflow. How does this process start? And what does the data look like coming in that triggers it? From there, how does the data move? Where does it go? Am I able to send it down one path? Do I have to send it off different ways based on some conditional logic? Do I need some aspect of AI to take decisions based on the different types of data coming through? You know, what actions have to be taken? Where do we need RAG or API calls involved? Where do we need to go out somewhere to get more external data to enrich the context going through to the next LLM? What integrations are involved? So if you ask yourself these kinds of questions while you're writing down the steps or while you're wireframing out the skeleton of the build, you are going to answer so many more questions, especially if it comes to, you know, you're trying to work with a client and you're trying to understand the scope of work and understand what the solution is going to look like. If you wireframe it out, you're going to have questions for them that they might not have thought of either, rather than you guys agree on a scope of work and you start building this thing out, and then all of a sudden there's all these complexities. Maybe you priced way too low, maybe you don't know the functionality. And the idea here is just to completely align on what you're trying to build and what the client wants, or what you're trying to build and what you're actually going to do in your canvas. So there's multiple use cases, but the idea here is that it's just going to be so, so helpful. And because you're able to break down every single step and every task involved, you'll have a super clear idea on if it's going to be an agent or if it's going to be a workflow, because you'll see if the stuff happens in the same order or if there's an aspect of decision-making involved. So when I'm approaching a client build or an internal automation that I'm trying to build for myself, there is no way that more than half my time is spent in the builder. Pretty much upfront, I'm doing all of the wireframing and understanding what this is going to look like. Because the goal here is that we're basically creating a step-by-step instruction manual of how to put the pieces together. You should think of it as if you're putting together a Lego set. So you would never grab all the pieces from your bag of Legos, rip it open, and just start putting them together and trying to figure out where— what goes where. You're always gonna have right next to you that manual where you're looking at like basically the step-by-step instructions and flipping through. So that's what I do with my two monitors. On the left I have my wireframe, on the right I have my N8N, and I'm just looking back and forth and connecting the pieces where I know the integrations are supposed to be. You need a clear plan, otherwise you're not gonna know how everything fits together. It's like you were trying to, you know, build a 500-piece puzzle, but you're not allowed to look at the actual picture of a completed puzzle, and you're kind of blindly trying to put them together. You can do it, it can work, but it's gonna take a lot longer. Moving on to number 3, we have context is everything. The AI is only going to be as good as the information that you provide it. It is really cool. The tech has come so far. These AI models are super, super intelligent, but they're pre-trained, so they can't just figure things out, especially if they're operating within a specific domain where there's, you know, industry jargon or your specific business processes. It needs your subject matter expertise in order to actually be effective. It doesn't think like we do. It doesn't have past experiences or intuition, at least right away. We can give it stuff like that. It only works with the data it's given. So garbage in equals garbage out. So what happens if you don't provide high-quality context? Hallucination, the AI is going to start to make up stuff. Tool misuse, it's not going to use the tools correctly and it's going to fail to achieve your tasks that you need it to do. And then vague responses, if it doesn't have clear direction and a clear sight of like, what is the goal? What am I trying to do here? It is just not going to be useful. It's going to be generic and it's going to sound very obviously like it came from a ChatGPT. So a perfect example here is the salesperson analogy. Let's say you hire a superstar salesman who is amazing, great sales technique, he understands how to build rapport, closing techniques, communication skills, just like maybe you're taking a GPT-4.0 model out of the box and you're plugging it into your agent. Now, no matter how good that model is or the salesperson is, there are going to be no closed sales without the subject matter expertise, the business process knowledge, you know, understanding the pricing, the features, the examples, all that kind of stuff. So the question becomes, how do you actually provide your AI agents with better context? And there are 3 main ways here. The first one is within your agent, you have a system prompt. So this is kind of like the fine-tuning of the model where we're training it on, this is your role, this is how you should behave, this is what you're supposed to do. Then we have the sort of memory of the agent, which is more of the short-term memory we're referring to right here, where it can understand like the past 10 interactions it had with the user based on the input, stuff like that. And then the final aspect, which is very, very powerful, is the RAG aspect, where it's able to go retrieve information that it doesn't currently have, but it's able to understand what do I need to go get and where can I go get it. So it can either hit different APIs to get real-time data, or it can hit its knowledge base that hopefully is syncing dynamically and is updated. So either way, it's reaching outside of its system prompt to get more information from these external sources. So anyways, preloaded knowledge. This is basically where you tell the agent its job, its description, its role, as if on day 1 of a summer internship you told the intern, okay, this is what you're going to do all summer. You define its job responsibilities, you would give key facts about your business, and you would give it rules and guidelines to follow. And then we move on to the user-specific context, which is just sort of its memory based on the person it's interacting with. So this reminds the AI what the customer's already asked, what previous troubleshooting steps that have been taken, maybe information about the customer. And without this user-context-specific memory, the AI is going to ask the same questions over and over. It's going to forget what's already been conversated about, and it'll probably just annoy the end user with repetitive information and not very tailored information. So we're able to store these past interactions so that the AI can see it before it responds and before it takes action, so that it's actually more seamless like a human conversation it's more natural and efficient. And then we have the aspect of the real-time context. This is because there's some information that's just too dynamically changing or too large to fit within the actual system prompt of the agent. So instead of relying on this predefined knowledge, we can retrieve this context dynamically. So maybe it's as simple as we're asking the agent what the weather is. So it hits that weather API in order to go access real-time current information about the weather, it pulls it back, and then it responds to us. Or it could be, you know, we're asking about product information within a database. So it could go hit that knowledge base that has all of our product information, and it will search through it, look for what it needs, and then pull it back and then respond to us with it. So that's the aspect of RAG, and it's super, super powerful. Okay, and this is a great segue from RAG. Now we're talking about vector databases and when not to use a vector database. So I think something similar happened here with vector databases as the same way it happened with AI agents, is that it was just some cool magic buzzword. And it sounded like almost too good to be true. So everyone just started overusing them and overusing the term. And that's definitely something that I have to admit that I fell victim to because when I first started building this stuff, I was taking all types of data no matter what it was, and I was just chucking it into a vector database and chatting with it. And because, you know, 70% of the time I was getting the right answers, I was like, this is so cool because it's that, you know, as you can see based on this illustration, it is sort of like that multidimensional data representation. It's a multi-dimensional space where the data points that you were storing are stored as these little vectors, these little dots everywhere. And they're not just placed in there, they're placed in there intelligently because the actual context of the chunk that you're putting into the vector database, it's placed based on its meaning. So it's embedded based on all these numerical representations of data. As you can see, like right up here, this is what the sort of embedding dimensions look like. And each point has meaning. And so it's placed somewhere where other things are placed that are similar, they're placed near them. So over here we have like, you know, animals, cat, dog, wolf, those are placed similarly. We have like fruits over here, but also like tech stuff because Google's here and Apple, which isn't the fruit, but it's also the tech brand. So, you know, it also kind of shifts as you embed more vectors in there. So it's just like multi-changing, it's very intelligent, and the agent's able to scan everything and grab back all the chunks that are relevant really quickly. And like I said, it's just kind of one of those buzzwords that's super cool. However, even though it sounds cool, after building these systems for a while, I learned that vector databases are not always necessary for most business automation needs. If your data is structured and it needs exact retrieval, which a lot of times company data is very structured and you do need exact retrieval, a relational database is going to be much better for that use case. And, you know, just because It's a buzzword. That's exactly what it is, a buzzword. So that doesn't always mean it's the best tool for the job. So because in college I studied business analytics, I've had a little bit of a background with like databases, relational databases, and analytics. But if you don't really understand the difference between structured and unstructured data and what a relational database is, we'll go over it real quick. Structured data is basically anything that can fit into rows and columns because it has an organized sort of predictable schema. So in this example, we're looking at customer data and we have two different tables. And this is relational data because over here we have a customer ID column. So customer ID 101 is Alice and we have Alice's email right here. Customer ID 102 is Bob, we have Bob's email. And then we have a different table that is able to relate back to this customer lookup table because we match on the fields customer ID. Anyways, this is an order table, it looks like. So we have order 1 by customer ID 101 and the product was a laptop. And we may think, okay, well, we're looking at order 1, who was that? We can relate it back to this table based on the customer ID, and then we can look up who that user was. So there's a lot of use cases out there. When I said, you know, a lot of business data is going to be structured, like user profiles, sales records, you know, invoice details, all this kind of stuff, you know, even if it's not a relational aspect of linking two tables together, if it's structured data, which is going to be, you know, a lot of chart stuff, number stuff, Excel sheets, Google Sheets, all that kind of stuff, right? And if it's structured data, it's going to be a lot more efficient to query it using SQL rather than trying to vectorize it and put it into a vector database for semantic search. So we said as a non-programmer, if you're, you know, I'm sure you've been hearing SQL querying and maybe you don't understand exactly what it is. This is what it is, right? So we're almost kind of using natural language to extract information, but we could have you know, half a million records in a table. And so it's just a quicker way to actually filter through that stuff to get what we need. So in this case, let's say the SQL query we're doing is based on the user question of, can you check the status of my order for a wireless mouse placed on January 10th? On the left, we have an orders table, and this is the information we need. These are the fields, but there may be 500,000 records, so we have to filter through it really quickly. And how we would do this is we would say, okay, First, we're gonna do a SELECT statement, which just means, okay, we just want to see order ID, order date, order status, because those are the only columns we care about. We want to grab it from the orders table, so this table, and then now we set up our filters. So we're just looking for only rows where product name equals wireless mouse, because that's the product she bought, and then, and the order date is January 10th, 2024. So we're just saying whenever these two conditions are met, That's when we want to grab those records and actually look at them. So that's an example of like what a SQL query is doing. And then on the other side of things, we have unstructured data, which is usually the best use case for unstructured data going into a vector database based on my experience is just vectorizing a ton of text. So big walls of text, chunking them up, throwing them into a vector database, and they're placed, you know, based on the meaning of those chunks and then can be grabbed back semantically, intelligently by the agent. But anyways, this is a quick visualization that I made right over here. Let's say we have tons of PDFs and they're just basically policy information. We take that text, we chunk it up, so we're just splitting it based on the characters within the actual content, and then each chunk becomes a vector, which is just one of these dots in this 3-dimensional space, and they're placed in different areas, like I said, based on the actual meaning of these chunks. So super cool stuff, right? So then when the agent wants to, you know, look in the vector database to pull some stuff back, it basically makes a query and vectorizes that query because it will be placed near other things that are related, and then it will grab like everything that's near it. And that's how it pulls back if we're doing like a nearest neighbor search. But don't want to get too technical here. I wanted to show an example of like why that's beneficial. So on the left, we have product information about blankets, and on the right, we also have product information about blankets. And we just decided on the right, it's a vector database. On the left, It's a relational database. And so let's say we hooked this up to, you know, a customer chatbot on a website. And the customer asked, I'm looking for blankets that are fuzzy. Now, if it was a relational database, the agent would be looking through and querying for, you know, where the description contains the word fuzzy, or maybe material contains the word fuzzy. And because there's no instances of the word fuzzy right here, we may get nothing back. But on the other side of things, when we have the vector database, because each of these vectors are placed based on the meaning of their description and their material, the agent will be able to figure out, okay, if I go over here and I pull back these vectors, these are probably fuzzy because I understand that it's cozy fleece or it's, you know, hand-woven cotton. So that's like why there's some extra benefits there because maybe it's not a word-for-word match, but the agent can still intelligently pull back stuff that's similar based on the actual context of the chunks and the meaning. Okay, moving on to number 5, why prompting is critical for AI agents. We already talked about it a little bit, I guess, in the context is everything section, because prompting is giving it more context. But this should be a whole lesson in itself because it is truly an art, and you have to find that fine line between you don't want to over-prompt it and you want to minimize your token usage, but you also want to give it enough information But, um, when people think of prompting, they think of ChatGPT, as you can see right here, where you have the luxury of talking to chat. It's going to send you something back. You can tell it, hey, make that shorter, or hey, make it more professional. It'll send it back and you can keep going back and forth and making adjustments until you're happy with it. And then you can finally accept the output. But when we're dealing with AI agents and we're trying to make these systems autonomous, we only have one shot at it. So we're going to put in a system prompt right here that the agent will be able to look at every time there's like an input. and we have to trust that the output and the actions taken before the output are going to be high quality. And so like I said, this is a super interesting topic, and if you want to see a video where I did more of a deep dive on it, you can check it out. I'll tag it right here, um, where I talked about like this lesson. But the biggest thing I learned building these agents over the past 6 months was reactive prompting is way better than proactive prompting. Admittedly, when I started prompting, I did it all wrong. I was lazy. And I would just like grab a custom GPT that I saw someone use on YouTube for, you know, a prompt generator that generates the most optimized prompts for your AI agents. I think that that's honestly a bunch of garbage. I even have created my own AI agent system prompt architect, and I posted it in my community, and people are using it, but I wouldn't recommend to use it, to be honest. Um, nowadays I think that the best practice is to write all of your prompts from scratch by hand from the beginning, and start with nothing. So that's what I meant by saying reactive prompting. Because if you're grabbing a whole, you know, let's say you have 200 lines of prompts and you throw it in here into your system prompts, and then you just start testing your agent, you don't know what's going on and why the agent's behaving as it is. You could have an issue pop up and you add a different line in the system prompt and the issue that you originally were having is fixed, but now a new issue's popped up and you're just going to be banging your head against the wall trying to debug this thing by taking out lines, testing, adding lines, testing. It's just going to be such a painful process when in reality what you should do is reactive prompt. So start with nothing in the system prompt, give your agent a tool, and then test it. Throw in a couple queries and see if you're liking what's coming back. You're going to observe that behavior, and then you have the ability to correct the system prompts reactively. So based on what you saw, you can add in a line and say, hey, don't do that, or, you know, this worked, let's add another tool and add another prompt now, or another line in the prompt. Because what we know right now is that it's working based on what we have. That way, if we do add a line and then we test and then we observe the behavior and we see that it broke, we know exactly what broke this automation and we can pinpoint it rather than if we threw in a whole pre-generated system prompt. So that's the main reason why I don't do that anymore. And then it's just that loop of test, re-prompt, test again, re-prompt. And what's super cool about this is because you can basically hard prompt your agent with things in the system prompts because you're able to show it examples of, you know, hey, I just asked you this and you took these steps. That was wrong. Don't do that again. This is what you should have done. And basically, if you give it that example within the system prompt, you're training this thing to not behave like that and you're only improving the consistency of your agent's performance. So the key elements of a strong AI agent prompt and This isn't like every single time, these are the 5 things you should have, because every agent's different. For example, if you're creating a context creation agent, you wouldn't need a tool section really if it's not— if it doesn't have any tools. You'd just be prompting it about its output and about its role. But anyways, the first one that we're talking about is role. This is sort of just like telling the AI who it is. So this could be as simple as like, you're a legal assistant specializing in corporate law. Your job is to summarize contracts in simple terms and flag risky clauses, something like that. It gives the AI clear purpose and it helps the model understand the tone and the scope of its job. Without this, the AI is not going to know how to frame responses and you're going to get either very random outputs or you're going to get very vague outputs that are very clearly generated by AI. And of course you have the context, which is going to help the agent understand, you know, what is actually coming in every time, because essentially you're going to have different inputs every time, even though the system prompt is the same. So saying like, this is what you're going to receive. This is what you're gonna do with it. This is your end goal. So that helps tailor the whole process and make it more seamless as well. That's one common mistake I actually see with people's prompting when they start is they forget to define what are you going to be getting every time? Because the agents either gonna be getting a ton of different emails or maybe a ton of different articles, but it needs to know, okay, this information that you're throwing at me, what is it? Why am I getting it? Then of course the tool instructions. So when you're building a tools agent, this is the most important thing in my mind. Yes, it's good to add rules and show like when you use each thing, but having an actual section for your tools is going to increase the consistency a lot. At least that's what I found, because this tells the AI exactly what tools are available, when to use them, how they work. Um, and this is really going to ensure correct tool usage rather than the AI trying to go off of like these sort of guidelines because it's a non-deterministic workflow and, um, trying to guess of which one will do what. And, um, yeah, have a tools section and define your tools. Then you've got your rules and constraints, and this is going to help prevent hallucination. It's going to help the agent stick to sort of like a standard operating procedure. Now you just have to be careful here because you don't want to say something like, do all of these in this order every time, because then it's like, why are you even using an agent? You should just be using a workflow, right? But anyways, just setting some foundational, like, if X, do Y, if Z, do A, like that sort of thing. And then finally, examples, which I think are super, super important, but I would never just put these in here blind. I would only use examples to directly counter and directly correct something that's happened. So what I alluded to earlier with the hard prompting. So let's say you give the agent an input, it calls tool 1, and then it gives you an output that's just incorrect, completely incorrect. You'd want to give it in the example, you could show, okay, here's the input I just gave you. Now here's what you should have done. Call tool 2 and then call tool 3 and then give me the output. And then it knows like, okay, that's what I did. This is what I should have done. So if I ever get an input similar to this, I can just call these 2 tools because I know that's an example of like how it should behave. So hard prompting is really, really going to come in handy and not just in the examples, but also just with the rest of your system prompts. All right, moving on to number 6, we have scaling agents. Can be a nightmare. And this is all part of like one of the hard truths I talked about earlier, where a lot of the stuff you see online is a great proof of concept, a great MVP. But if you were to try to push this into production in your own business, you're going to notice it's not there yet. Because when you first build out these AI agents, everything can seem to work fine. It's a demo. It's cool. It really opens your eyes to, you know, the capabilities, but it hasn't usually gone under that rigorous testing and evaluation and setting up these guardrails. and all of that, you know, continuous monitoring that you need to do to evaluate its performance before you can push it out to all, you know, 100 users that you want to eventually push it out to. You know, on a single user level, if you have a few hallucinations every once in a while, it's not a huge deal. But as you scale the use case, you're just going to be scaling hallucinations and scaling problems and scaling all these failures. So that's where it gets tricky. You can start to get retrieval issues. As your database grows, it's going to be harder for your agent to cut through the noise and grab what it needs. So you're going to get more inaccuracies, you're going to have some different performance bottlenecks, and the agent's latency is going to increase. You're going to start to get inconsistent outputs, and you're going to experience all those edge cases that you hadn't thought of when you were the only one testing, because there's just an infinite amount of scenarios that an agent could be exposed to. So a good little lesson learned here would be to scale vertically before you start to try to scale horizontally, which we'll break that down, and I made this little visualization so we can see what that means. So let's say we want to help this business with their customer support, sales, inventory, and HR management. Rather than building out little building blocks of tools within each of these processes, let's try to perfect one area first vertically, and then we'll start to move across the organization and look at doing other things and scaling to more users. So because we can focus on this one area, we can set up a knowledge base and set up like the data sources and build that automated pipeline. We can set up how this kind of stuff gets organized with our sub-workflows. We can set up, you know, an actual agent that's going to have different tool calls. And within this process, what we have over here are evaluations, monitoring performance, and then setting up those guardrails because we're testing throughout this, you know, ecosystem vertically and getting exposure to all these different edge cases before we try to move into other, you know, areas where we need to basically start this whole process again. We want to have done the end-to-end system first, understand, you know, the problems that may arise, how to make it robust, and how to evaluate and, you know, iterate over it before we start making more automations. And so like I alluded to earlier, if you try to start scaling horizontally too quick before you've done all these testing, you are going to notice that hallucinations are going to increase. Your retrieval quality is going to drop as more users come in. The agent's handling more memory, it's handling more more knowledge in its database to try to cut through. Your response times are going to slow, and then you're just going to get more inconsistent results. And so you can do things like, you know, setting strict retrieval rules and guardrails. You could do stuff like segmenting your data into different vector databases based on the context, or different namespaces, or different, you know, relational databases. You could use stuff like asynchronous processing or caching in order to improve that response time. And then you could also look at doing stuff like only, you know, having an agent evaluate and making sure that the confidence on these responses are above a certain threshold. Otherwise, we'll, you know, request human help and not actually respond ourselves, or the agent wouldn't respond itself. So the seventh one is that no-code tools like N8N have their limits. They're super great. They're really empowering non-developers to get in here and spin up some really cool automations. And it's really like the barrier to entry is so low. You can learn how to build this stuff really quickly. Which is why I think it's awesome. And you know, it's the main tool that I use personally and also within my agency. But when you start to get into what we just talked about with lesson number 6, scaling and making these things really robust and production ready, you may notice some limits with no-code tools like N8N. Now, the reason I got into building stuff like this is because, you know, obviously non-programmer, and it has a really nice drag-and-drop interface where you can build these workflows very visually without writing scripts. So N8N is, you know, basically open source because you can self-host it. The code is accessible. Um, and it's built on top of LangChain, which is just like a, basically a language that helps connect to different things and create these like agents. Um, and because of that, it's just wrapped up really pretty for us in a graphical user interface where we can interact with it in that drag and drop way without having to get in there and hands on keyboard, write code. And it has a ton of prebuilt integrations, as you can see right here, connect anything to everything. I think there's like 1,000 integrations right here, and all of these different integrations are API calls. They're just wrapped up once again in a pretty way for us in a user interface. And like I talked about earlier, when I started, I didn't even know what an API was, so the barrier to entry was super low. I was able to configure this stuff easily. And besides these built-in integrations, they have these really simple tool calls, so development is really fast with building workflows compared to traditional coding. The modularity aspect, because you can basically build out a workflow, you can save that as a tool, and then you can call that tool from any other workflow you want. So once you build out a function once, you've basically got it there forever and it can be reused, which is really cool. And then my favorite aspect about N8N and the visual interface is the visual debugging, because rather than having 300 lines of code and, you know, you're getting errors in line 12 and line 45, you're going to see it's going to be red or it's going to be green. And you know, if it's green, you're good. And if you see red, there's an error. So you know exactly, usually you know exactly where the problem is coming from, and you're able to get in there, look at the execution data, and get to the bottom of it pretty quick. But overall, these no-code platforms are great. They allow us to connect APIs. We can connect to pretty much anything because we have an HTTP request within an add-in. They're going to be really, really good for rule-based decision making, like super solid. If we're creating workflows that's just going to do some data manipulation and transferring data around, you know, your typical ETL based on the structured logic, super robust. You can make some really, really awesome basic AI-powered workflows where you're integrating different LLMs. You've got all the different chat models basically that you can connect to, um, for, you know, different classification or content generation or outreach, anything like that. Um, your multi-agentic workflows, because like I said earlier, you have the aspect of creating different tools, um, as workflows, as well as creating agents as workflows that you can call on from multiple agents. So you can really get into some cool multi-agentic inception thing going on with, with agents calling agents calling agents, um, and passing data between different workflows. And then just the orchestration of AI services, coordinating multiple AI tools within a single process. So that's the kind of stuff that NNN is going to be super, super good at. And now the hidden limitations of these no-code AI workflow slash agent builders. Let's get into it. Now, in my opinion, this stuff really just comes down to when we're trying to get into like enterprise solutions at scale with a ton of users and a ton of authentication and a ton of data. Because if you're building out your own internal automations, you're going to be solid. Like, there's not going to be limitations. If you're building out, you know, proof of concepts and MVPs, YouTube videos, creating content, like, you can do it all, I would say. But when you need to start processing, you know, massive data sets that are going to scale to thousands or millions of users, your performance can slow down or even fail. And that's maybe where you'd want to rely on some custom code backend to actually spin up these more robust functionalities. In these agentic systems, tool calling is really, really critical. The agent needs to be able to decide which one to use and do it efficiently. And like I talked about, NNN is built on top of LangChain. It provides a structured way to call AI models and APIs, but it lacks some of that flexibility of writing that really custom code within there for complex decision making. And then when it comes to authentication at scale, it can struggle with like secure large-scale authentication and data access control. Obviously you can hook up to external systems to help with some of that processing, but when it comes to maybe like handling OAuth tokens and all these encrypted credentials and session management, not that it's not doable with N8N, um, it just seems like getting in there with some custom code, it could be quicker and more robust. And also that's coming from someone who doesn't actually do that myself. Um, just some stuff I've heard and, you know, with what's going on within the agency. Now, ultimately it seems like if you are delivering this stuff at scale for some big clients, um, the best approach is gonna be a mix, a hybrid of no-code and custom code, because you can use N8N to spin up stuff really quick. You've got that modularity. You can orchestrate, automate, you know, connect to anything you need. but then working in every once in a while some custom Python script for some of that complex, you know, large-scale processing and data handling. And when you combine these two together, you're gonna be able to spin some stuff up a lot quicker, and that's gonna be pretty robust and powerful. Now, if you really are serious about building out these AI automations and you're coming from a background of, you know, not a programmer, so it seems a little intimidating, I would definitely encourage you to check out my paid community. I have a full course in there about building AI agents. we also have deep dive topics on things like RAG, vector databases, APIs, and HTTP requests. I'm also doing a lot of step-by-step and live builds in the community, which I think are the best way to actually learn, you know, data flow, live troubleshooting, like the, the, the mindset and the creative problem solving that goes into building out these automations. And, you know, on top of that, we've got 5 live calls per week. Make sure you're never getting stuck. You can get in there, get your questions answered, and it's a growing fast community. So we have a ton of people in there. Everyone's kind of filtering in to learn about building AI automations. Um, we've got beginners, we've got people that are pretty advanced, we've got some people that are pretty techie. So all the kind of questions you may have with troubleshooting or setting up your environments or even navigating if you're running an agency and you want to hear more about like how other people are pricing or approaching discovery calls and actually deploying stuff on a client server, whatever it is, um, a great place to just be surrounded by like-minded people that are trying to do similar things and Ultimately, you know, the space is so new, it's moving so fast. It's a very collaborative space right now, which I love. So just surrounding yourself with people that are trying to do the same things as you and winning altogether as a community. So would love to see you guys in that community. But otherwise, you know, my channel is pretty much all about making this kind of stuff accessible to all types of people from all types of backgrounds. My focus obviously is how can we build this stuff really easily simplify all of it down and also give you guys all my templates that I make in my YouTube videos for free in my free school community. So that way you can get in there, download them, plug them in, and just like understand what's going on and how the data flows. So I hope to see, you know, you in some other videos. I do a lot of stuff on the channel, so check out, you know, other tutorials I've made and definitely let me know what else you want to see and also what you thought of this, you know, sort of style of content. So Really appreciate you guys making it to the end of this one. As always, if you appreciate this video, if it helps you, if you learned something new, definitely give it a like. It helps me out a ton, and I will see you guys in the next one. Thanks everyone.