Stop Vibe Coding: Context Engineering & RAG for AI Agents [# 12 Cole Medin]

There is way too much fluff in the AI space. Every single day, there's five new technologies that are released, and the biggest challenge is to figure out, like... What should I actually pay attention to? Cole Medin is one of the sharpest operators in applied AI today. The CTO of Automator, a founder, a builder, and a teacher with a gift for making advanced AI actually usable. Through his company, Dynamis, and his private AI mastery community, he's helped thousands level up their workflows. And with a YouTube channel topping 179,000 subscribers with over 8 million views, he's become the go-to voice for anyone serious about AI agents, rag systems, and scaling with automations. Whether he's architecting intelligent systems or teaching the next wave of builders, he's dedicated to one mission, helping people leverage AI with clarity, precision, and impact. How does that work for you? Like in the end, the bottom line is this is going to save you time or make you money. So like what should the station do for you to get to that point for you? There's this cursor, there's claw, there's whisper flow. What's your stack? You see the difference between a mid-level developer and a senior is that mids are really, really fast and they're really good, right? There might be a mid, but you learn these painful lessons as time goes on. that will then save you. so much time on the back end basically for every single piece of information or concept that we've turned into an numerical representation we can attach additional values that describe that information the problem was people didn't really treat their prompts with enough respect and the whole like context around their asia with enough respect you just give a couple of sentences because you're you know kind of acting lazy what makes me think about is almost like prompting and praying you just shut it off and pray that it works versus context engineering I just ask the questions of how are you going to actually use this agent? And sometimes they don't even know themselves. And that's when it gets trickier. How much time do you spend on this pre-planning phase of context engineering before you launch into the actual development of the project? Hey, Cole, it's awesome having you on the podcast. One thing I want to say is that people's time is really valuable. And so what is the value that people are going to get by listening to this podcast? Yeah, good question. So we're going to dive into context engineering. what it looks like to build our agents in a way that actually scales. Then we're going to get into RAG, which is something that I really specialize in. I've done a lot with RAG and N8N and Superbase. We'll get all into that. And then the last thing we're going to talk about is how we can take our workflows in N8N and really move it into a production environment. And so literally, no matter what you're doing with building agents, you're going to care about these things. And so we're going to hit on some high-level stuff that's going to apply no matter what you're working on. Fantastic. Looking at these three key areas, since you are the progenitor or the online inventor of context engineering, can you talk to me a little bit about the genesis of context engineering? So there's a problem that we had towards the start of the year that is definitely addressed at this point thanks to context engineering. But the problem was people didn't really treat their prompts with enough respect and the whole context around their agent with enough respect. It really deserves to be its own engineered resource, just like the rest of our system, like our N8N workflows or if you're working in code, your code base. and so like even going so far as to version control your prompts like you keep track of how your prompts have evolved over time you have different versions of your prompts so you can go back to another version if your new one just started making your agent go off the rails that kind of thing is really important And thinking about the context for your agent as a completely separate system from the workflow itself. So the tools that you have for your agent, the descriptions for those tools, which is also a part of the prompt to the LLM. And then, of course, your system prompt. And those really are like the core components when you think about context engineering for the agents that you're building in N8N. And can you explain the difference for anybody that's listening, the difference between vibe coding and context engineering? Yeah, 100%. So vibe coding, in essence, doesn't treat the context with respect, like I was saying. So when you vibe code, and you just tell your AI coding assistant to go and create this code base, or you tell the agent builder to make this agent and you Just give a couple of sentences because you're kind of acting lazy. That's what people do a lot, where they just expect the coding assistant to take a very simple request and do exactly what they want the assistant to do. But it's never that simple because they're going to make a lot of assumptions. Getting things wrong, not because the large language model is doing a bad job, but because you weren't specific enough. and so another big component of context engineering is how can we be a specific enough and if i were to say like the one primary goal of context engineering it is simply to reduce the number of assumptions that your ai agent or coding assistant is making and that is all about specificity and with vibe coding we don't have specificity it's all just sending in a prompt hoping for the best and going with the flow which i think is where the word vibe comes from so context engineering is before we even have our agent or coding assistant do anything we are going to sit down and really think through what are my requirements how am i going to translate that into a system prompt or the tools that i have for my agent whatever that might be what it makes me think about is almost like prompting and praying you just shove it off and pray that it works versus context engineering sounds like there's more of a methodology a system and an overall practice to make sure that you're giving it the right input so you get the right output because we both know that ai runs off of data so the more data the more details the better the output's going to be yeah that's exactly right yeah and the system is a key word there because you create your process like you have a template for your system prompt that you always use or you have tools the capabilities i want to give my agent and you have something that's more generic that you adapt to your specific use cases like having that kind of thing is a really good way to avoid vibe coding because then you always have that system in place like you said so that's good run me through if somebody wants to switch or level up from vibe coding to context engineering. What is the framework? What is the methodology? What is the practice? If I'm just looking at a blank canvas or a chat GPT window, what are the elements or components that I need to do, or even better, the SOPs, step-by-step processes in order to make a solid context engineering game plan? Yeah, that's a really good question. Honestly, I would say start simple and just think about context engineering as a mindset shift. more than it is like you have to fundamentally rethink your entire approach. Because you can go from vibe coding to context engineering by very simply just spending more time with your planning up front. And something that you can do very practically to step into that right away is ask your coding assistant or your agent, like whatever large language model you're working with, ask it to ask you questions so you can get on the same page. And so something that I do all the time. when I'm working with AI coding assistants is I give like a brain dump of here's what I want to build next I want to build this application and it's going to have these kinds of users I want people to be able to do this and this and then I'll specifically ask it ask me any clarifying questions for any gaps that you have in your knowledge let's make sure we get on the same page here and and that it will start to teach you like oh this is where i should be more specific like you see these patterns develop when you go through this process it keeps asking these questions where it's oh i'm never thinking about security so maybe i should start being specific about that just as a random example and so you build that muscle over time okay this is how i want to create this system of getting more specific and like practically what that actually looks like like what those different categories are that you want to list out to the assistant it's almost like meta-prompting meta-prompting was using ai to figure out what kind of prompt you should give it so you prompt it to ask the questions and then it helps you formulate the prompt that's necessary yes it sounds like a part of this though is you brain dump with some sort of meta prompt that says here's what i'm thinking about doing i want you to ask me as many clarifying questions as i need in order to come up with something that you have certainty with so that we can move forward with a solid game plan is there anything else inside of there where you do brain dump to meta-prompting is there any other elements inside that you think people should be aware of besides just ask me questions are there certain types of questions or i want you to create me a checklist yeah so a lot of these things i cover on my channel quite extensively just thinking about besides having the coding assistant help you come up with like areas that you need to include in context engineering i give suggestions myself about the different kinds of things to consider and so like very much like at a high level when you're building a new ai agent or a new application you want to think about the success criteria you want the coding assistant to understand if i check off these 10 boxes i built these 10 things or the agent can now do these 10 things then it is complete even something really high level like that people don't usually think about but it's really good too like if you're a project manager you've heard of this phrase all the time where you have like how is the end user actually going to use this agent or application so you define that clearly so it's not just like the what we're building but the why and the how and like having that defined as well and then also when you have a larger list of things that you have to knock out if you have clearly defined tasks so you can break up the problem that is also really useful i could go on and on about all these different core categories that i like to include in my plans and like what i'm giving as context but i think i'll leave it there for those are like the core three Sure. So let me move through some of these just to kind of recap and come back to an assessment so someone can walk away with practical tactical advice and tips. So step one, you can say, I'm going to brain dump everything that I have of what I think this thing would look like. I know that I'm going to have it ask me questions, but you also know, can I create a checklist or a step-by-step process of how you want this type of thing executed as well as what does success look like? And what does failure look like? And what is a user journey? You could say, what is my path from somebody being discovering the application to being onboarded to the habit loop patterns all the way to mastery of this application and figuring that out? And if you can have it say, these are the different areas I want to tackle. Let's first work on the overall questions you have. Then next thing is from that, let's work on user journeys. And then from that, let's work on success versus failure states. And then from that, we can say, OK, based on all of this information, can we make a order of operations SOP for the different categories that we want to tackle so that we can kind of line by line go down through a checklist and walk away with something that it doesn't involve context rot. and the overall issues where it has a tendency to forget the last thing you said from 200 000 tokens ago i'm doing a synopsis of your channel in about a paragraph statement is again just going to open up the chasm with fossils so we could clip out just that one section and go okay great i have a framework to lead me down through a series of prompts that could then ultimately get me closer to being a context engineer yeah that's good yeah you phrase it really well and i think like the one big takeaway for all of this is when you're engineering your context you also just want to be very specific about how you can break up something into many different granular implementations right like when you build an application or an ai agent you start with the basics you don't try to build everything at once and that's also part of context engineering is how we can be specific to the agent like we have our phases here phase one let's start with something very simple because coding assistance any kind of assistant that's going to help you build like an end workflow they always love to over engineer things they will always do more than you ask it to unless you're very specific about how focused you want to be i have two questions my first one i want to get to unless then we'll probably shift gears over to rag question one how much time do you spend on this pre-planning phase of context engineering before you launch in the actual development of the project i'm not counting the back and forth chatting with ai how much time planning makes sense yeah So it depends a lot on what I'm building. I would say a general rule of thumb is somewhere between a half hour and an hour. And so when I'm starting a brand new application or agent, whatever, I always start with the overarching document that I call a PRD, a product requirement document. You might've heard that before. It's really just outlining the scope of work for finishing our application, like that first version. And so creating that and putting my thoughts into the architecture and security and like the step-by-step process, that's what I'll put like a half hour or an hour into before I'm ever even like talking to the coding assistant or having it do something on my behalf. That's great. And it's good to have a timeframe because people don't always understand. Now you understand that this is the time window and these are the elements that I should ideally have. chunk down in that time window. I'm sure also with any skill or ability that you can get into, the better you get at it, the faster you can go through it, but there is still a methodology to follow. That's right. You talk about coding assistants. There's all these different versions that you could use, right? There's this cursor, there's Claude, there's Whisperflow. What's your stack? Yeah. So Claude Code is my favorite AI coding assistant right now. but also the entire process the system that i built for context engineering it is agnostic of the individual tool that i'm using and so if anthropic has an outage like they unfortunately have once in a while i'm able to immediately switch to another tool without a hiccup So I can go over to Codex, which is my second favorite. Also, Google just released Antigravity as a new agentic IDE, along with their release of Gemini 3. That's probably my third favorite right now. So there's a lot of fantastic tools out there. And there's not one that completely dominates the market like Cloud Code did even a few months ago. Yeah, I'd say don't focus on the individual tool. It's also just like a little golden nugget of advice that I want to share. But Cloud Code is the one that works the best for me generally right now. Inside NNN, for anybody that doesn't know this and people that are starting to build out with these projects, it is always good to have a fallback AI. Inside of NNN, we have a fallback AI feature that's inside the agents that if OpenAI has an outage or something else has an outage, it has a fallback to another AI. As someone who's ran an AI agency before, you have people calling you up because everything's broken. You don't know why it's broken. And then you realize it was just ChatGPT. having an outage, and then that was the issue. So fallbacks are super critical, whether you're doing it inside NNN or you're doing it inside of this coding environment. That's one piece of it. The other element I want to get into is not only about the time window and the technology stack on these pieces, but in terms of, if we look at this as an overall arching system, you have context engineering to create the game plan. You take that game plan and you put it into a production environment like a cursor or cloud code or any of these other ones out there. It's really going to move into that. And I know it's important and we're going to get into rag in a hot second. But one thing I also want to double down on you, we're talking about this, is that people, humans, we're creatures of habit. We do the same things over and over again. And so a lot of people, a majority of people still use ChatGPT to write code. That's me and you both know it's not the best coding platform. What are your activities to be able to stay at the cutting edge, to be able to say, okay, I was using clod, but now there's this. I was doing that. What is your process or what are your patterns that you have to stay up to date? Yeah, so the biggest thing to keep in mind is there is way too much fluff in the AI space. Every single day, there's five new technologies that are released, and the biggest challenge is figure out like... What should I actually pay attention to versus what should I scrap immediately? I'm not even going to look into this because I know that it's not going to be something that I'm going to evolve my stack into using. And so the biggest thing for me, whenever there's a new technology that is released, I'm going to do a lot of research on that and like all the other things that were released recently. And I'll use a tool like Perplexity or OpenAI's Deep Research to help me with that kind of as a starting point. Here are the five big things that I heard about this week. Tell me more about them. And based on my preferences, because you can set up projects and things that understands my development stack and what I'm building, it can suggest, is this something that I should actually care about? Not that I always trust its recommendations, but it's a good starting point. and then the other thing that i'll say is that having an ai community is the most important thing for being able to cut through the fluff and learn what people are leveraging that's new that you would actually want to take advantage of yourself i happen to be running an ai community myself so i get to learn from everyone in the community as much as they're learning from me because i'm seeing the things that they're playing around with and a lot of times these people they happen to have more time than me for a couple of days that something new came out and so for example when Google released anti-gravity. It's their agentic IDE that I mentioned earlier. I happened to be very busy during that couple of days working on some YouTube content, so I didn't get to try it. But there were like four dozen people that were able to use it within my Dynamis community, and so I got to hear all about it before I even tried it out. And from what they said, I knew, okay, this is definitely worth paying attention to. And like I shared earlier, I still think cloud code is better. but it's close. And like that kind of thing when, okay, this might become the best tool for me to include my stack very soon. I want to pay attention to that. Yeah. It's hard to separate the hype from the helpful, especially in this whole world of marketing buzz. And so when someone says, oh, this is the innate killer, this is this killer, and it's just, they're going clickbaity, ragebaity kind of stuff. And you don't know until you actually dive in and you really do an analysis of it because really the data tells all. And I completely agree when you're sourcing and you have a collective people, a community of people that are all deep researching in these categories, then it does surface things to the top as well as doing your own research. I think it's incredibly powerful. So moving from context engineering into RAG and N8N, let's talk about just getting started all the way up to the biggest RAG deployments, the ones that have to handle, cause you do, you RAG a seven page piece of paper, that is one thing, but if you have millions of documents, a different type of approach is needed. So talk to me about this process. Yeah, 100%. First of all, RAG with N8N is my introduction to N8N as a platform. And the first video that I ever put on YouTube that got like a significant amount of views, it's up to I think 150,000 right now, it was me using N8N to build a RAG agent with Supabase. so it's very cool like it has a special place in my heart this entire stack and building rag agents and like in that video i talk about building a very basic rag agent so there are a lot of strategies that we can get into if we have time i'll probably talk about a couple of them but in a very basic sense what you have with rag is you're giving your agent tools to search your knowledge base your documents because the problem we have with agents is you can never give all of your documents into the context of your llm unless you just have a very small number of documents and so what you have to do is you have to give your agent the ability to search through your documents but keyword search is usually not enough because a lot of times you want to connect concepts together instead of just keywords like for example If I am interested in, let's say, looking at some fast food restaurant options, and I have some agent that can help me because it understands all of the fast food options around me. If I search for, like, I want a hamburger, then I wanted to recommend maybe the Big Mac from McDonald's. Just trying to find a really universal example, where if you do a keyword search, you might not actually find that. If you search for burger, you might not find McDonald's and Big Mac because there's no exact keyword there. But if you use RAG and you can connect concepts together, then you have a special kind of model in RAG called an embedding model. And it's able to connect these words together or phrases together if they are conceptually related. Like a Big Mac is a burger. Therefore, there's actually a lot of similarity there. and so you do this kind of what's called semantic search where you're finding the similarity between phrases and keywords instead of just doing is this word equivalent to this word that's a very fundamental search and you can combine both together and even that is a specific rag strategy but essentially what you do with rag is you have your original data source this could be a bunch of pdf documents you have locally it could be a bunch of files that you have in google drive wherever that might be and you have some kind of process that takes the documents from there and it feeds it into what is called a vector database that is where you use the embedding model to create that kind of numerical representation of the data so it can be searchable by your agents and if i could show a diagram right here i'm not going to do that for the sake of time i could like really walk through what this looks like technically but just know that at a high level we're transforming our data into something that is searchable by our agents And Supabase is my favorite database to store this information for RAG. And so they have this extension called PG Vector that essentially turns Supabase, which is a Postgres SQL database, into what can be used as a vector database. And so now whenever we have a query that our agent produces, like I want to search for the best burgers near me, then it sends that into the vector database. It finds the concepts that are similar, like McDonald's and Big Mac, and it returns that as context to the agent. And so now it can use that extra information to enhance its answer. So RAG is short for retrieval augmented generation because we are augmenting the agent's ability to generate answers for us thanks to the information it can pull from its search in the vector database. And the vector databases, they pretty much scale to infinity. and i mean take that with a grain of salt it's not literally to infinity and there's a lot of considerations that go into that but when you have a million documents in your knowledge base versus 10 the actual search is not affected that much like the speed of the search is not affected that much and so you're able to pull from a very large corpus of documents exactly the information that you need to pull in as context for the llm And so that way you don't have to overwhelm the context for your large language model. You can't even fit a lot of documents into the context if you try, but you're still able to get like that bit of information that you need. So that's RAG at a high level. The kind of thing that I could explain for hours and really get into stuff, but I'll leave it there for now. You're right in terms of scaling. There's an equation that I try to make for people that might understand this that come from the design world or the photo world, right? You have a normal PNG photo. That whenever you scale up that photo and let's say it's a small, tiny headshot and you scale it up, it becomes very blurry. And so that's the image becomes blurry. If you turn it into a vector image, it turns that into math. And so you can scale a vector image up to infinity. It's not going to lose resolutions because it's mostly just doing math in order to have those ratios make sense. So that's why you can take a tiny headshot that's vector and turn it into a giant billboard more or less because you have the ability to turn it into math. we're doing with words is we turn that into math using vector vectorization and it allows them to be able to make it searchable for the ai hence why it becomes something that can be done at scale yes that's really good that's actually a great analogy i haven't heard that before but that makes a lot of sense yeah because basically what you do with reg is you take the query that either the user produces or the agent produces and you turn that into a mathematical representation as well as everything else that is already numerically represented in the vector database so you take that the numbers that represent this query and you drop it into the vector space and you just look at the other ideas or words that are close in that vector space they have a similar numerical representation and so you drop it in you pick out the things that are close and then that's what you send as context for the llm so it doesn't matter if there's five billion concepts that are somewhere else in the vector space we only care about what's close by so it's not like we have to scan through everything in order to find what's relevant that's why it scales so incredibly well and some ways to produce better results i'm gonna lean into one we can dial on that and then we can also talk about scaling these things up there is an ability to add metadata to be associated with any of the vectorized databases that then allows to do a re-ranking tool something that allows it to then get more accurate results can you speak more to that Yeah, so metadata filtering is very powerful. Basically, for every single piece of information or concept that we've turned into a numerical representation, we can attach additional values that describe that information. So one really good use case, people like to, they ask me all the time, could I use one vector database for multiple clients? Could I have all their information stored in one vector database? And there's a lot of reasons you don't want to just so that you have like, full isolation, but like theoretically, you can have a single vector database with all the information because you have a piece of metadata that says what client that information is for. This is also known as multi-tenancy. So if you have a SaaS application with all these different user storing information, it can just be a single database. And so then when the user wants to perform a search, you would figure out, okay, what's their user ID or what is their client ID? and then you do a filter i'm going to look in the vector database but i'm only going to search through the records where the metadata value of the client or user id is equivalent to the one for our search and so then we are only navigating through a subset of the information in the vector database so we're absolutely guaranteed to have isolation for what we're actually searching through and so that's a really powerful concept there's a lot of other good examples of metadata filtering like maybe you're operating in one business where you have different departments like you only want to search through the sales knowledge base or only want to search through the marketing knowledge base or you have different like there's an idea of a hierarchical reg where you have like different levels of categories and you want to be specific with like how deep you're going in your search versus you want to broaden to a higher set of information that you're searching through you can use metadata for that it gets quite extensive because it's a very flexible component to RAG because you can really store any information as far as like just metadata attached to each record. And then you can search through that in any way that you want. When you're talking about this, hierarchical is very interesting. I do want to double down on people that are listening to this that want to apply this into business. A lot of AI agencies and people that go, great, this makes sense. In terms of, is there an overall system strategy process operation methodology for installing this into a business that does have marketing, sales, operation, fulfillment, customer support. And they have all these different elements. Can you talk to me a little bit of strategy? Is it all in one vector database? Do you break them up into different vector stores that then give you access to know which one to go into? How would you approach stalling this into your business? So it depends on one really big thing as far as if I do one vector database or many. it depends on if i guess the way to explain this is do i want to only ever search in one department like i'm only looking at the sales knowledge or searching through the marketing knowledge or do you maybe have the ceo of the company that wants to be able to search through everything at once and if you want that flexibility then it has to be in one vector database or it's optimal to have in a one vector database and then you take advantage of metadata filtering and so if you have this internal dashboard where users sign in if they're on the sales team and they sign into the dashboard then there's a piece of metadata attached to their record their user record they are on the sales team so now when they talk to this agent that you have built into this internal dashboard the metadata filter is going to be set to only search for the records and the knowledge base from the sales team so you have this permission set up per user because then when the ceo logs into this dashboard They maybe won't have any kind of filter attached to their record. So when they do a search, it's going to search through all of the documents for all departments at the same time. And then, of course, probably give them the option to do a filter if they want to really hone in on something. And that's the idea of hierarchical reg. Like the CEO is able to search very broad, or maybe there's going to be some kind of dropdown where he's, oh, let me ask this question, but only under the context of the sales documents or the sales data. Yeah, this is where the user journey, user stories make a ton of sense. because for example the ceo of the company might want to generate sales reports but they also might want to see customer tickets they might want to look at the entire system of what's going on and so it's going to vary on what are their day-to-day operations in order to understand their patterns of behavior their user journey and then being able to design a system for that so when you're doing this are you when you go to say make this data metadata like what's your process for understanding a company's operational style to know that i do need to install this dashboard for the ceo needs to have these five filters or the sales director needs to have these three filters do you have a process for bringing people through to understanding what kind of metadata structure you want to set for this vectorized database so the most important thing when you're talking to a client or just some company where you're going to set this up for them You want to not focus on the technicalities of things. I'm never going to explain metadata filtering. The CEO of a company, unless they ask about it, they'll get into it if they want to connect with the engineering team, whatever. I've done that before where like, I'll really get into the weeds on things, but at a high level, it's more like, let me ask them about their process. And in the back of my mind, I know how that translates to the technicalities of things. Oh, they just told me that they want complete isolation. And they're never going to want to search across different departments. Like that tells me like, okay, it's probably good. I could just create multiple smaller vector databases for this company. Or they tell me the CEOs, yes, this agent is going to be great for my team, but I also want to use it to connect ideas together or see how all my teams are doing. Cause maybe there's like real-time documents that are being adjusted into this pipeline. But in that case, that tells me like, okay, it should be one vector database. And so, like I said, don't focus on the technicalities. I just ask the questions of how are you going to actually use this agent in the end? and sometimes they don't even know themselves and that's when it gets trickier but it's more like at that point you just guide them through okay here's my ideas for how you could use the agent like how does that work for you like in the end the bottom line is this going to save you time or make you money so like what should this agent do for you to get to that point for you it's that clarity of thought it's one of the things almost feels like pulling teeth when you work with a business that they said i want ai to do everything then you have to say okay it depends on how you want to use it and if they come up with one two or three examples of how they use it but then once you get it fully built later on they tell you they want to use it actually 15 different ways and it wasn't built for that it's so important to have this foundational elements of a clear mapping of how the data flows yeah and then we want to call them sops or user behavior journeys of what is the step-by-step process that you want to have done that i wake up in the morning i'm in a panic because i think my company's running out of money so i go on as a ceo and i look it all up to see where's my money going what are those patterns of behavior and how do we extract them out and that's one of the i think talents of a really high level ai agency is the ability to be able to extract that knowledge in the beginning it's almost like context engineering but you have to do it as team developed context engineering so you can get that data yeah yeah it's context engineering for the business you're working with so that you're making sure you're asking the right questions so that you know what they want and so you can set the right expectations like you said dylan you don't want to build it for three use cases and then it's they expect 15 a month later you establish what those use cases are and then you set that as a clear expectation like in the contract this is what the agent is going to be able to do if you want more then you'll pay me more to extend the agent or build out more systems. Is there anything else do you want to mention in the category of RAG and doing these for large-scale deployments? Is there anything else that people should be considering? For example, I need to extract all this information out of the team. We need to go back and forth, be able to pull out this data so I can understand all the use cases. In terms of the technical implementation, is there anything that people should consider if they are doing this for a giant company? Yeah. So the biggest thing is you might be working with ugly data. So we talked like very high level, like you have your data source and then you feed that into your vector database. Now what that feeding into looks like, sometimes it can be really simple. Like in N8N, you might have a Google Drive trigger where you're watching for new files and you're just working with Google Docs. And so you just have to extract text from text file node. And then that goes into the insert into Supabase vector database node. In an ideal scenario, it's basically that simple there's a couple of other nodes to make sure you don't like duplicate records and things like that but technicalities aside it can be that simple or you could be working with really messy data where they have proprietary data formats or pdfs from scanned physical paper copies of things that just like you need to apply a really powerful ocr model on top of you could be extracting information from these like really ugly database schemas that you just have to figure out, like, how do I even navigate this database? There's so many possibilities when you get into the weeds with a company, especially with proprietary data formats, it's going to be something you've never seen before. And you just have to do that problem solving before you even get to the point where you have the data to build the agent on top of. And so really the very first thing when you're building a RAG agent for a business is to understand their data and establish like, what does it look like to actually build what's called the RAG pipeline? to take information from their data sources and put that into the place, the vector database, where the agent is actually going to be doing the search. 100%. Yeah, messy data, unclean data. Some databases can handle it. You're talking about this ELT or ETL, right? You want to be able to extract the data, transform the data, load the data where it needs to go, or if that's transforming ahead of time so you can put it in cleanly in a database. And then some other databases are a little bit more forgiving, so you can extract the data. load the data and then be able to transform the data afterwards you're right in terms of understanding the data that's coming in and then ultimately what you want to do with it comes down to how dirty is the data and how forgiving is the pipeline that you can put it into yeah the end goal to get something into a vector database is to have the raw text So like using an image model, like an OCR model to pull text out of a PDF, for example, you just want to have that string in your N8N workflow so that you can just put that right into the Supabase Spectre store or whatever that might be. Yeah, I was working with a client a long time ago and they were working with their clients and they were having to chat, but upload the data. And all of a sudden became all of these variables because first it was text. Okay, no problem. Then PNGs. Okay, OCR. Then it was PDF, right? And then there was one that was a... I forget the name of the file format, but it was like an email, like an MTL, ETL. I can't remember the file format. It's like an email downloadable format. All of a sudden, there's this custom format that just came out of the blue and then broke the system. So it's like, how can you make sure that you're accounting for all of these different types of data formats that are going to go in that could inherently break your system? And we want to compensate for that. Very good point on why we want to know step-by-step user behavior. Are they going to be only uploading text? Are they going to upload images? What are they going to be doing that's going to affect the pipeline? Yep, exactly. Right. And one really important thing, if you never really know, and you can never really know what file formats people are going to try to upload, it's good to have a fallback. And like we were talking about earlier with LLM fallbacks, where if you don't have a file format that you recognize, then you maybe try to extract the text in the most standard way possible. If that fails, then... you should have some kind of way to report the failure either back to the user back in the system where you have your monitoring set up or both you have to handle that gracefully you can't just have the application crash and so a lot of times what i'll have either just like in some json file that i have is like config in my code base locally or in a database somewhere i'll have stored a list of the file extensions that are actually supported by the reg pipeline and then as i evolve the system i'll add on to that list or change things and then that way i'm always comparing against that list so when a file comes in i extract the extension i see if it's something that i support and then if not that's when i go down like the fallback route that i was talking about yeah yeah look at the extensions actually a really good tip if you look at the extension go is this a file type that we support if so continue if not alert that's right yeah So then moving on from this, we've talked about context engineering. We've talked about RAG pipelines to a good degree. I'm sure we can go much deeper, but shifting over to the categories of you've built out this awesome in it in workflow experience. And this is something that you do. Some people take in it in and they bring it to scale. There's a lot of enterprise companies that do use this at scale for certain uses. And there's other people that want to bring it into a different environment for whatever reasons. They want to turn this into a different type of production ready environment. Talk to me about the process of converting. an n8n workflow into a code base into some sort of other production ready environment so that you can then bring it to scale in another yeah and this is something i do all the time where i will use n8n like you said dylan it can definitely be something that you scale to production but a lot of times what i like to do especially because i come from a very technical software engineering background myself is i'll build an n8n workflow as a proof of concept for something because it really is the fastest way to build things But then when I want to really scale to production, I want to work in a code base. I go through a process of translating that workflow into code. Typically, Python code can be TypeScript as well. Those are the two programming languages that I prefer using. And going back to context engineering, we actually do get to go a little full circle here because I will take the NAN workflow. I will literally just download the JSON of the NAN workflow and include that as some of the context for the AI coding assistant. and so again going back full circle the primary goal of context engineering is to reduce the number of assumptions that the llm has to make when it's building something on our behalf and the beauty of an nan workflow is it's really specific because when you download the json file you have all the different nodes that outline the workflow for the agent or the rag pipeline whatever it is you have all the parameters that you set you have the system prompt that you added into the ai agent node you have all these different things and so that reduces a lot of the assumptions the llm is making it can read that json file and by the way large language models are very good at understanding json it's very structured for them to pull out here the keys here the nodes and their attributes like it understands all that right out of the box and so it can take that to understand what you want to build and then you just have to describe generally how you want to translate to code as much as you can and then maybe anything else that you want to add on to it typically i'll start really simple where it's okay let's just replicate exactly what we have in n8n then start adding on those other things that we want to do to evolve it more into that production version of the code one of my favorite things with n8n is being able to copy the visual format and then paste it somewhere else and you can absolutely see all of the code right there there's not a lot of abstraction layers there are some other automation platforms that shall not be named that you can't really do that with which makes it a lack of clarity and those are great for working with people that are less technical and it's also good for maybe not breaking the system but if you really want to get into weeds and be able to evolve this and have to be a very flexible system being allowed to access converting visual code into this written format like json that in it does incredibly powerful so if you take this in it in code which is json put into some sort of coding assistant where you have all the context inside of there do you then feed you said context engineering do you feed it a meta prompt around that say here's all this information do you also give the use cases do you previously grab the sops from before or the user journeys and feed it in there as well how much additional context do you need beyond just the scope of the code itself in order to convert start into python right yeah so typically what i do is i treat the end workflow as the additional context instead of the other way around so what you were getting at is okay start with the workflow is the main thing now what other things that we talked about do you include like the user story the task list and things like that i will actually start with all of that and then just as one of those things i wanted to reference i'll give it the end workflow now i will say that this is like the primary context for your reference because it is very specific what we're building out here but i still do want to like have the checklist of the tasks and have the success criteria, even if the success criteria is molded around like you have implemented these things from the NAN workflow, but I still do have pretty much the exact same process. makes sense so when you're doing you're grabbing the context initially and then one step in your sop process is to when i say sop frankly that doesn't know it means standard operating procedure just means a step-by-step process for moving through a thing and when you grab this context and then you have your own sops of grab context bring into the system and then a line item in that sop process is the ability to say here is now the workflow or one of several workflows that i want you to convert over into python so let's just say you do bring that over into python it's inside your coding environment how do you get this deployed let's talk about this is this something that you then you do cloud code to github github self-hosting what is this now you have python code what's next the way that a deploying application does depend on the type of app so for front-end applications if it's like a next js app i'll just deploy it to versell If it's like a React application, which if you've ever built with like Lovable or Bolt, like they're always React applications. A platform I'm really using is called Render. So you can host what are called static applications. That's what a React app is completely for free on Render. Now for back-end applications, there's a couple of different platforms that I like. If you've ever self-hosted NAN, you're probably familiar with these. If you were to go to DigitalOcean, Hetzner, Hostinger, being able to deploy applications in a machine that you basically pay monthly for in the cloud there is a really good way to host your agents and your API endpoints. You can use Render for that as well. Or if you're like going really enterprise level, sometimes clients will have a certain requirement around compliance or SLAs. And then you, at that point, we don't want to go like really enterprise, which the big three cloud platforms for that is Google Cloud or GCP, AWS and Microsoft Azure. And GCP is the one that is usually like the easiest for me. So that's like the enterprise cloud option that I'll go to. They have containerized serverless environments for your agents and being able to host static apps and things there as well. Yeah. it's so funny navigating those ones and i've built applications ai agent applications that host on those ones aws is one of the hardest to navigate you ever try to give permissions to somebody inside of there it's not as simple as make admin or give for you have to go through all of these processes and one of the things that i've done before i don't think they make it available right now and i think they took it away i hope please google if you're listening they had inside the whole google workshop area the google ai area they had the ability to screen share and i could screen share my screen and I could talk to the AI as I was doing it. And I was actually really now authentications. I was like, okay, I'm inside AWS. How do I give this user these permissions? Where do I go? What do I do? And just being able to navigate that environment was just like, oh, come on, man. Why is this so hard? But also incredibly stable. It's what the big boys use, AWS and all this GCP, it's all this one. So I just want anybody that's interested in getting those ones, just know it was a bit of a learning curve. when you get out of there fantastic so now we've talked about how do you do front end how do you do back and it's so funny because full circle we're talking about context engineering you want to have the details in the front end you want to get really clear on that we talked about deploying that inside of in it in coding environments what that looks like how do you use context engineering for that and then ultimately transitioning that into from workflows into this type of python straight code based environments putting that into there and then ultimately deploying versus front end or back end, depending on the service as required. Is there anything else that you think is really topical or noteworthy that you should mention in this process in the stack? Yeah. So you mentioned GitHub for a sec and I didn't focus on that, but GitHub is the glue for everything because not only do I use Git to create save states as I'm building all my application, but it's also where I host all of my code bases that I'm deploying to the cloud. so it doesn't matter if i'm using digital ocean hostinger render gcp whatever like it's always going to be pulling from a github repository which is also how i can manage my different environments like dev test and production i can roll back versions of things if i want to deploy an old version because something new i created broke which unfortunately happens all the time no matter how good of a developer you are And so Git and GitHub is like a core part of my development workflow. And it has been for like every engineer since, I don't know, 1970. And maybe it wasn't GitHub, but just some kind of version control system. It was really important. So I use that a lot. I have a lot of security and testing built in, like whenever I make a commit to a GitHub repository. So like that kind of like CI, CD part of the GitHub workflows is really important as well. For those of you who don't know what that is like. continuous integration, continuous delivery is all about like, whenever I make a change in my code, I automatically want to run my security checks and my unit tests and my integration tests, like doing all these validation checks. Every single time I create one of those safe states in my code and even deploying things automatically as well is also really powerful. I haven't done a manual deployment in years now because we have that built into these platforms. Like they're able to leverage GitHub to watch for changes to the code base. And then if it's on a certain branch, like our main branch, then it's going to automatically deploy things new to production. Yeah, hooking up, especially if you, I won't say vibe coding, but let's say you're using a cursor or a clod or any of these ones, be able to connect that up to a GitHub account so that you can have multiple save states and be able to iterate on that process. Because part of the things is you can do your best at having the context engineering and follow a step-by-step process inside of there. But if you're able to upload the GitHub, you can have so many save states inside of there. And you can see the thing, one of the things I had a video I did on the YouTube channel. of how to actually have your n8n workflows and how to upload them as these folders and these products that have been being tagged that have been saved up in there because there's been times i was using a hosting service for n8n won't name which one but i was using it and then i uploaded a code node that wasn't really verified and it crapped the whole system out the whole thing and so my entire it was done it was bricked and but because i had all of my backups that were daily saved up on github and workflows okay simply extra yeah good he only knows because as someone who also develops this type of stuff we get there we have only needs one time so if anybody's please learn from the pains and lessons that we've had you have these stage dates you have these backups there's proper methodologies for this because sometimes it's so easy they say that's the difference between a mid level developer and a senior is that mids are really fast and they're really good Right. Seniors usually do things right. They think about the process. They go deep in the thoughts. Right. And so we can get up moving really quickly and they feel like a mid. Right. Or there might be a mid. But you learn these painful lessons as time goes on that will then save you so much time on the back end, along with the context engineering and quick to deployment and all that fun stuff. Fantastic. This has been incredible. Cole, it's been amazing having you on the podcast. Any final words before you tell people how they can find you and get a hold of you? Yeah, I would just say that like. a lot of these things if they're not really concrete in your mind right now what's my process for context engineering or how do i build a reg pipeline just start really simple and you build that muscle over time like you start to to realize oh these are the things that i should be laying out in my context my coding assistant right away and so you'll learn like you start really simple and you build the system for yourself and so there's a lot of guidance that i have like on my youtube channel for example to get you started but i always say like the best system is the one that is optimized for what you are working on specifically and so that applies to anything you're building and any process that you have for building as well everything with context engineering the last thing that i want to say is that everything that we're talking about here if it's a little vague in your mind like how do i set up my reg pipeline or what is my strategy for context engineering i'll say just start really simple and you build that muscle over time you start to learn okay here are the things that i want to be really specific about to my coding assistant or here's the different file formats that i want to work with in reg and like you just build that muscle over time so don't be intimidated just start really simple And I will say that as you start simple and evolve things, you're also getting to customize your system to what works for you. And that's what I always tell people is the most powerful system is the one that you've customized to. specifically what you're working on. And as a starting point, I teach a lot on my YouTube channel about RAG and context engineering and AI coding. And so if you just go and search my name on YouTube, Cole Medin, then you'll find it. And yeah, I'm doing content every single week on building AI agents and leveraging AI coding assistance in ways that actually scale. Fantastic. Cole, it's been an honor and pleasure, my friend. Much love. I'll see you on the other side. Thank you, Dylan.

In this episode, we sit down with Cole Medin, CTO of Automator and expert in applied AI, to dive deep into context engineering, RAG (Retrieval Augmented Generation), and building scalable AI workflows. Cole shares practical strategies for cutting through the noise in the AI space, designing effective prompts, and moving from prototypes to production-ready systems. Whether you’re an AI builder, developer, or just curious about the latest in automation, this conversation is packed with actionable insights and real-world advice. 

00:00 – Introduction: The challenge of too much “fluff” in the AI space and how to focus on what matters. 
00:22 – Meet Cole Meine: Background, expertise, and his mission in applied AI. 
01:59 – What listeners will learn: Context engineering, RAG, and moving workflows to production. 
02:40 – The origin of context engineering: Why treating prompts and context as engineered resources matters. 
03:49 – Vibe coding vs. context engineering: The importance of specificity and reducing assumptions. 
06:18 – Practical steps for context engineering: Mindset shift, planning, and using AI to ask clarifying questions. 
08:47 – Success criteria and user journeys: How to define what “done” looks like for AI projects. 
12:36 – How much time to spend on planning: Product requirement docs and upfront investment. 
13:54 – Favorite AI coding tools: Cloud Code, Codex, and Google’s Anti-Gravity. 
15:23 – Staying up to date in AI: Research strategies and the value of community. 
18:09 – Introduction to RAG (Retrieval Augmented Generation): What it is and why it matters. 
20:41 – How RAG works: Embedding models, vector databases, and semantic search. 
24:45 – Metadata filtering in RAG: Multi-tenancy, hierarchical search, and business use cases. 
28:46 – Handling messy data: ETL/ELT pipelines and preparing data for AI agents. 
32:06 – Scaling workflows: Moving from n8n prototypes to production code (Python/TypeScript). 
34:38 – Deployment strategies: Frontend, backend, and cloud hosting options. 
37:13 – The importance of version control: Using GitHub for safe states and CI/CD.
40:05 – Final advice: Start simple, build your process, and customize your system. 
41:15 – Where to find more: Cole Meine’s YouTube channel for more on RAG and context engineering.

#n8nMasterclassPodcast n8n Masterclass Podcast