Graph Engineering Clearly Explained

I came on here to talk about a term I keep seeing going viral on Twitter it's graph engineering you've seen it I've seen it too and I'll be honest the first time I saw it my reaction was okay is this a real thing or did we just invent another phrase to make everyone feel behind because yeah I has this funny habit where every few weeks there's this new term that goes viral prop engineering context engineering agent engineering vibe coding loop engineering and now graph engineering some of these phrases are hype some of them are actually useful and graph engineering is one of the useful ones because it gives you a much better way to think about how AI actually gets done so in this episode I'm going to explain graph engineering in plain English by the end of this episode I want you to be able to take one AI workflow you're ready run like customer research support triage content production or startup idea validation and turn it into a simple map of steps checks handoffs loops and human approvals so we're gonna talk about all that and how you can do it it's going to be clearly explained so let's get into it the simplest way to think about graph engineering is like this prompt engineering is how you ask the AI for a better question and context engineering is how you give AI better information but graph engineering is how you design the work around the AI so the whole thing stops living inside inside one messy giant AI chat I'll give you an example imagine you're researching a new startup idea the normal way most people use AI is they open up a chat and they say should I build this idea the model will give you a confident answer it probably sounds pretty smart it might give you the market size a few competitors maybe a go to market plan and you feel like you did the research but if you actually slow down you realize something a little uncomfortable happened one model in one past decided what mattered research the market interpreted the evidence wrote the recommendation and graded it in its own confidence that's a lot of trust to put into one blob of text in some cases you might spend years your life based on this one question that you asked and you might be working on the wrong thing the graph version looks a lot different so a planner first breaks the question into angles one research one researcher looks at the customer another looks at competitors another looks at distribution another looks at pricing another looks at risks then a skeptic will try to kill the weak findings then a merger turns their surviving evidence into a one page of recommendation and then you approve the decision before you act on it the output might still be this written report but the work behind it is just designed so much better and that at its core is graph engineering you're taking a messy AI task and turning it into a workflow that you can actually manage now let's define the basic vocabulary without making this feel like a computer science lecture by the way I remember learning about one of my first classes in university was graph theory and so it's a real throwback for me I'll explain it to you in the clearest way possible when people say graph they basically mean jobs connected by arrows each job is a step in the workflow the arrows show what happens next and the shared notes moving through the workflow are the state which is just a fancy way of saying what does the system know so far so that sounds technical for about five seconds and then you realize that's actually how work gets done in the real world in in in reality you know think about customer support when a customer writes in the work is rarely just answer the ticket first you need to understand what kind of issue it is then you need to check the customers account history maybe you need to search for the docs for the right policy then you draft a response then you decide whether this is risky enough that a human should review it before going out when you draw those steps out and connect them in an order they actually depend on each other and that is a graph take content for example if I'm making a YouTube episode the work isn't just write a script a good episode might start with research a thesis examples a hook maybe script then title ideas then thumbnail directions then I you know an escala draw and then a final pass where I ask this is sound like a human being or does this sound like someone trapped inside a sass on boarding flow some of those steps have to happen in order some of those steps have have to happen in order you probably want the thesis before the script you probably want the script before the escala draw but other pieces can happen at the same time one Richard one researcher can look for examples while another looks for counter arguments one could study the audience angle while another looks for practical workflows then those outputs merge back into the script and that's where the graph starts paying because most people use AI in a straight line because chat makes everything kind of feels sequential you ask for research then you ask for summary then you ask for a draft and then you ask for edits then you ask for titles that works for really simple things but when the work has multiple pieces the straight line chat starts to get slow and fuzzy and actually hard to trust what's cool about a graph is it lets you design the work more like a small team one part plans a few work in parallel another checks the work another merges it and then the human approves the final step and once that clicks in your head it just gets a lot less mysterious because there's two different things people mean when they say graph in AI and this is actually where a lot of the confusion comes from the first is what's called a knowledge graph a knowledge graph helps AI reason over relationships over things for example this customer works at this company this company uses this product this product connects to this tool this support issue relates to this feature and this feature is owned by this team knowledge graphs help because AI reason across relationships and messy data this matters because normal rag often retrieved chunks of text that looks similar to the question but it can struggle when the answer actually requires connecting different people across companies and topics and claims and events you know there's tools like you might have heard of Microsoft graph rag because sometimes you just need AI to understand relationships inside a body of knowledge not just to retrieve the nearest paragraph that is one version of graph engineering the second version is what's called an agent graph an agent graph is about how work moves so a planner hands work to researchers the researchers work in parallel a skeptic checks the findings a synthesizer might merge the parts and a human will you know prove the final answer this episode is mostly about agent graphs actually because that is the version you can start using today as a founder as a creator as an operator as a small team so I figured I'd do an episode focusing on that the easiest way to remember the difference though is is kind of like this knowledge graphs help AI understand how information connects whereas agent graphs help AI understand how work should move and eventually the truth is the best systems use both the AI will understand relationships inside your business and it will also know how to move through the right steps but how can we make this tactical when should you use graph engineering well use it when the work has multiple steps multiple sources maybe multiple paths checks risk or approvals honestly if you're asking AI to brainstorm 10 names for a new project you probably don't need a graph if you're asking AI to summarize a short email you probably don't need a graph but if you're using AI to do deep research create a go to market plan triage support tickets review code prepare for sales calls synthesize customer feedback or produce recurring content workflow that's when graph thinking actually starts to matter a lot and the rule is pretty simple use a graph when the work has multiple steps some steps can happen at the same time and the final output needs checking before it matters a diamond starts with one question splits into multiple parallel paths checks the work and then merges everything in back in to one answer. So here's the startup idea version. Let's say the question is, should I launch an AI bookkeeping product for Shopify merchants? The messy chat version is one big question and one big answer. The graph version starts with a planner. So the planner would say something like, to answer this well, we need to understand the customer pain, the competitive landscape, the go-to-market wedge, the pricing pressure, and the risk. And then the work splits. You have one researcher who studies Shopify merchants and tries to understand the bookkeeping pain. Are they using QuickBooks? Are they using spreadsheets? Are they hiring bookkeepers? Are they annoyed at tax time? Are they looking for automation or do they just want someone to clean up the mess once a month? You have another researcher who's studying competitors. Are there ready Shopify bookkeeping tools? Are there accounting firms building this manually? Are App Store products solving this at all? Are freelancers on Upwork or Fiverr doing the work in a way that software could partially replace? Maybe you have another researcher who's studying the distribution? Where does Shopify merchants actually hang out? What newsletters do they read? What agencies already have trust with them? What Shopify app categories do they search? What search terms reveal buying intent? Those three jobs can happen at the same time because they don't depend on each other. Then comes the skeptic. The skeptic asks what claims are actually supported? Which evidence is stale because you're going to have data that is just old? Which competitors being ignored? Where are we confusing pain with willingness to pay? Where did the AI sound confident without proving anything? And this step matters more than people think. A lot of AI research fails because the same model that writes the answer also grades the answer. That is like asking someone to write their own performance review and then being shocked when they describe themselves as a visionary. Come on. In a good graph, checking is its own job. Then comes the merge. The merge step takes the surviving evidence and turns it into a recommendation. Should we pursue this? Should we pause it? Should we kill it? What is the wedge? Who's the first customer? What should we test this week? And what evidence would actually change our mind? And finally, you have the human gate. That's where you decide what to do next. You might decide to record a landing page tear down of a Shopify merchants. You might decide to interview 10 Shopify agency owners. You might decide to build a tiny calculator that estimates bookkeeping cleanup costs. Or hey, you might decide the idea is way too crowded and you just want to move on. But that is the point. Graph engineering does not magically make the decision for you. It gives you a better way to produce the evidence you use to make the decision. Now this is where I think people get too fancy too quickly. I would start way simpler than you see on Twitter people using land graph. You see people using auto-gen or some custom agent framework on day one. For your first graph, you can actually run it manually behind the scenes. I don't know why more people don't do this. I could show you exactly how to do it, but that just might be boring. The important thing is the structure. Give each job its own lane. One lane does customer research. Another lane does competitor research. Another lane does distribution research. Then the checker lane attacks the evidence. Then the merge lane turns a surviving evidence into a recommendation. That is a ready graph engineering. It's like level one of graph engineering. Yes, it's slower than a fully automated system, but it's way easier to understand. And if the manual version doesn't produce way better work, automating it honestly will just produce mediocre work way faster. The first rep is to draw the graph before you automate the graph. For me, I would do this with a blank Excalibur or TLDRAB board. I would write the final outcome at the top. Then I would draw the jobs, planner, customer researcher, competitor researcher, distribution researcher, skeptic, merge, human approval. Then I would draw the arrows. The planner feeds the three researchers. The researchers feed the skeptic. The skeptic feeds the merge. The merge feeds the human decision. And that's enough. Now, once that works three times manually, then I would think about all the tools. The beginner version is a manual run with separate lanes. But the intermediate version is Claude code codex or a repo where each step writes files. The planner writes plan.md, the researcher writes customer.md, competitors.md, and distribution.md, and the skeptic writes review.md. The merge step writes recommendation.md. What's cool about that is it leaves a paper trail and that's that's really nice. You can see what happened. You can compare versions and you can actually reuse the structure next week or a few weeks later. Now, the advanced version is when you do use something like Lang graph, auto-gen graph flow, n8n, make.com, or your own small scripts to actually orchestrate the graph. Lang graph is actually really useful when you want state checkpoints, persistence, human in the loop approvals, and more reliable control over how an agent workflow runs. Then you have something like auto-gen graph flow and that's useful when you want directed workflow with sequential steps, parallel steps, conditional branches and loops. Tools like n8n, make.com are useful when the graph touches everyday business systems like Slack, email, air table, or your CRM. Again, the tool is not the point. The tools are coming after the workflow. If you automate a workflow, you do not understand you get a mess. If you understand the workflow first, automation then becomes super obvious. I can do a graph engineering, advance tutorial if people are interested using things like Lang graph or Claude code. For the purpose of this episode, I think we just want to get to level one and level two. Hopefully, understand what graph engineering is at a high level. But how can you actually integrate this into your startup, into your business to start making more money or creating better products or just generating a lot of value? The one that comes to mind first is customer support. A simple support graph might start by classifying the issue. Is it billing, is it product-confusing? Maybe it's a bug or cancellation risk or maybe it's something else. Then the graph checks account context. Is it a new customer? Are they high value? Have they written in before? Are they frustrated? Then it searches the docs or internal policies. You might have like a whole wiki for your company, maybe a notion board. Maybe it goes and explores that. Then it drafts a reply. Then a checker reviews the reply for accuracy, tone, and risk. Then a human approves anything involving refunds, account changes, angry customers, legal risk, or promises that a company just might regret later. And that's the graph. And it's better than saying AI answer the support ticket because the support ticket is not the real workflow. The real workflows understanding and researching and drafting and checking and approving. It's probably starting to click now. Content creation is just another example that comes top of mind. A content graph might start with research, then it creates a thesis, then it finds examples, then it writes a hook, then it drafts a script, then a checker asks whether the examples are specific, whether the pacing works, whether the hook earns intention based on what's formats that are working, and whether the writing sounds like a person, something like the person actually would say. Then the graph can branch into title ideas, thumbnail concepts, captions, B-roll, things like that. And that's also closer to how a content lead, a real content lead that you would hire to help you create content would actually do. Another great example is coding. A coding graph might start with a plan, then one agent edits the code, another reviews the diff, another runs tests, another checks the UI in a browser, another looks for edge cases, and then you have a human being actually approving the final pull request. And that's basically where all these AI coding tools are going. The model writing the code is only one part of the workflow, and there's leverage in all the planning and testing and reviews. viewing and inspecting and deciding what is actually safe to ship. And that's actually an important point. Like a big reason why graph engineering matters is it makes quality less dependent on someone remembering a perfect prompt to ask their LLM. It makes reviews way more consistent. It makes delegation in general way cleaner. It makes approval way more explicit. It gives you a place to add tools and memory and checks and permissions over time. And it turns AI work from just like chat into this operating system and that really does feel like you're living in the future once you get to that place. Now there is one mistake that I want to warn against which is more agents don't automatically mean better output. Sometimes actually more agents mean more noise. Sometimes it means five AI workers confidently repeating the same wrong idea. Sometimes it means the system spends more time coordinating than thinking. So the goal is not to make the biggest graph possible. I've seen people on X go viral with these big, big graphs, but that's not the goal. The goal is actually to make the smallest graph that improves the quality of work. And that's a really important distinction because a good graph should remove fake waiting. And it should separate workers from checkers. And really it should put human approval where mistakes are expensive. And it should stop when the answer is good enough. It shouldn't need to continue. And it should leave behind the useful state, the meaning notes, the evidence, the drafts, the sources, and the decision so that you can use it later. And by the way, the last point is underrated because the real compounding value of graph engineering isn't just that one task gets better. It's that your work starts producing memory. What do I mean by that? I mean that every customer research graph creates better customer notes. Every content graph creates better examples and audience insights. Every support graph creates better product feedback. And that's where the context becomes the moat because the graph produces the work, but it also produces the memory that makes the next graph smarter. So it becomes this asset for you. So if you want to get into graph engineering and you're like, how do I start? Here's a way to think about it. I would pick one workflow I already run with AI every week. Maybe it's researching ideas or preparing podcast episodes, reviewing landing pages, analyzing customer feedback. Then I would write the final output in one sentence. For example, I want a one page recommendation on whether this startup idea is worth testing. And then I would list the jobs a great human would do. They would clarify the question. They would research the customers. They would research competitors. They would look for distribution. They would look for risks. They would check the evidence. They would make the recommendation. And then I would draw arrows where the work actually depends on another step. So what do I mean by that? Customer research and competitor research could happen at the same time. The skeptic needs the research before it can check it. And the final recommendation needs the skeptic pass before it can merge the evidence. Then I would add one human gate before the expensive decision. If the output is a private memo, maybe the human gate is light. If the output is a customer email, a public post, code deploys, a refund, or anything touching production data, you got to have a human gate that's stricter. Then I would run it manually once. This is the whole first rep that we want to get good at. You don't have to create this giant automation project. Just create the jobs and the arrows, and after you do this once, you start seeing AI work differently. Because you're not thinking about like, OK, I need to do the most perfect prompt ever. What is the perfect prompt for this task I'm trying to do? You start thinking about, OK, what's the most perfect workflow for this? And then you start designing a path that produces that answer. And that's why I think graph engineering in general is a concept that is worth paying attention to. It's really like the next logical step after prompting. I think the people who get the most out of AI will be the people who know how to break down work into the right pieces, give each piece the right context, check the output, and keep the human in the right place. Now that we're towards the end of the episode, here's what I would do to try to learn this. I would pick one workflow you're ready run, draw those jobs and arrows, delete the fake waiting, run the independent jobs in parallel, add a skeptic, merge the survivors, approve the final step yourself, and there you have it. That'll be your first graph. And once you have one graph that works, you're not just prompting AI anymore, you're managing AI work. It's sort of this like next level in being an agent manager and really just like stepping yourself into this new world deep into this new world where you're getting the most out of AI to build out your dreams, to take ideas and put them out there, and getting something I just think a lot about now is just like how do I get the most out of these platforms? And graph engineering is just a concept that helps you think about that. So there you have it folks, graph engineering clearly explained, hope that it got your creative juices flowing, hope it's been helpful. My name is Greg Eisenberg, I'm the host of the Startup Ideas Podcast for more, like, comment and subscribe, follow on Spotify and Apple, and I feel grateful that you're here, that I'm able to teach you, give you these concepts, and I just can't wait to see what you build. I'm rooting for you, have a creative day, and I'll see you next time.