Graph Engineering: Structuring Workflows for AI Agents

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, "OK, is this a real thing, or did we just invent another phrase to make everyone feel behind?" Because AI has this funny habit where every few weeks there's this new term that goes viral. Prompt engineering, context engineering, agent engineering, vibe coding, uh, 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 already 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 going to 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 to context to graph. Graph engineering is the layer above the other two. Prompt Engineering: How you ask a better question. The wording. Context Engineering: How you give better information. The inputs. Graph Engineering: How you design the work around the AI. The workflow. Not one giant chat, a managed workflow. 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 pass, decided what mattered, researched 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 of 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 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 the surviving evidence into a one-page 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, uh, graph theory, and it's a real throwback for me. I will 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 share 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 customer's 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 a script, then title ideas, then thumbnail, uh, directions, then I, you know, an excalibur draw, and then a final pass where I ask, "Does this sound like a human being, or does this sound like someone trapped inside a SaaS onboarding flow?" Some of those steps have to happen in order. You probably want the thesis before the script. You probably want the script before the excalibur draw. But other pieces can happen at the same time. One researcher 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 feel 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, uh, 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 in messy data. This matters because normal RAG often retrieves chunks of text that look 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 GraphRAG, 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, approve 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. Um, the easiest way to remember the difference, though, is it's 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. Um, 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 back into one answer. So here's a, 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 risks." 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 already 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 do 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 are 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. This is like asking someone to write their own performance review and then being shocked when they describe themselves as a vision a visionary. Come on. And 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 teardown of a Shopify merchant. You might decide to interview 10 Shopify, uh, 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, on Twitter people using LangGraph, you see people using AutoGen, 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 the surviving evidence into a recommendation. That is already 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 Excalidraw or TLDraw, a TLDraw 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. And 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 reuse the structure next week or a few weeks later. Now, the advanced version is when you do use something like LangGraph, AutoGen GraphFlow, N8N, make.com, or your own small scripts to actually orchestrate the graph. So LangGraph 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 AutoGen, GraphFlow, and that's useful when you want directed workflow with sequential steps, parallel steps, conditional branches, and loops. Tools like N8N, make.com are, are useful when the graph touches everyday business systems like Slack, email, Airtable, or your CRM. But again, the tool is not the point. Uh, the tool should come 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. And I can do a Graph Engineering advance tutorial if people are interested, uh, using things like LangGraph, or Claude Code, uh, but for the purpose of this episode, I think we just want to get to level one and level two. OK, so you now 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? Uh, the one that comes to mind, uh, first, is customer support. So 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. So 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 this support ticket," because the support ticket is not the real workflow. The real workflow is understanding and researching and drafting and checking and approving. It's probably starting to click now. Content, content creation is just another, uh, 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, you know, formats that are working, and whether the writing sounds like a per 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 reviewing 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, 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, you know, 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, 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 the, and that, by the way, the last point is underrated, because the real compounding value of graph, 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 like asset for you. So if you want to get into Graph Engineering and you're like, "How do I start?" Here's, here's a way to think about it. Um, I would pick one workflow I already run with AI every week. Maybe it's researching ideas, or preparing podcast episodes, uh, 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 customer research and competitor research could happen at the same time. The skeptic needs to 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, "Okay, I need to do the most perfect prompt ever. What, what is the, what is the perfect prompt for this task I'm trying to do?" You start thinking about, "Okay, what's the most perfect workflow for this?" And then, uh, you start designing a path that produces that answer. And that's why I think Graph Engineering, in general, is a, a concept that is worth paying, uh, attention to. It's really like the next logical step after prompting. And 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. So, now that, you know, 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 already 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, uh, being an agent manager and, and really just like, stepping yourself into this new world, uh, deep into this new world where, uh, you're getting the most out of these platforms to build out your dreams, to take ideas and put them out there, and getting, you know, something I just think a lot about now is just like, "How do I get the most out of these platforms?" Um, and Graph Engineering is just a concept that helps you think about that. So, there you have it, folks. Uh, Graph Engineering clearly explained. Um, hope that it got your creative juices flowing, hope it's been helpful. Um, my name is Greg Eisenberg. I'm the host of the Startup Ideas Podcast. For more, uh, you know, like, comment, and subscribe, follow on, on Spotify and Apple, and, uh, you know, I feel grateful that you're here, um, that I I'm able to teach you, give you these concepts, um, 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.