Graph Engineering

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 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, port 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 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 new 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 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 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

graph theory and and and so 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 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 5 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 Excalidraw, 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.

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 Excalidraw. But other pieces can happen at the same time. One

re- One researcher can look for examples while another looks for counterarguments. 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 retrieve 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, 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 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.

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 into

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'll 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 competitor is 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 vision- 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 teardown of a Shopify merchants.

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.

Now, once that works three times manually, then I would think about all the tools. The beginner version is a manual run with with separate lanes. But the intermediate version is Claude code,

code acts, or 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 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 LangGraph, AutoGen Graph Flow, 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 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 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

advanced tutorial if people are interested uh using things like LangGraph 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. Okay, 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 answered the 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 attention based on what's, you know, 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 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 summer 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 be human approval where

mistakes are expensive. And it should stop when the answer is good enough.

Shouldn't need to continue. And it should leave behind the useful state, the meeting 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 gra- 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 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.

Cuz you're not thinking about like, "Okay, I need to do the most perfect prompt ever. What What is that 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 AI 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's Greg Eisenberg. I'm the host of the Startup Ideas podcast. For more, uh you know, like, comment, and

subscribe. Follow on on uh 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.