39:43Greg Isenberg · Interview
Making $$$ with Loop Engineering
Elie Steinbock walks Greg Isenberg through the build-verify-learn loop he's using to run SEO, ads, and product feedback on autopilot.
July 13thThe argument in one line.
Graph engineering means designing AI work as a map of jobs, arrows, and shared state — planner, parallel researchers, a skeptic, and a human gate — instead of trusting one model to research, write, and grade its own answer inside a single chat.
Read if. Skip if.
READ IF YOU ARE…
- You run a recurring AI workflow — research, support, content, or code — that currently lives inside one long chat thread.
- You've noticed AI answers sound confident but you have no way to check what evidence they're actually built on.
- You're a founder, creator, or small team lead who wants a repeatable structure before reaching for a framework like LangGraph.
SKIP IF…
- Your AI use is one-off tasks like brainstorming names or summarizing a short email — those don't need a graph.
- You're looking for a hands-on coding tutorial on building LangGraph or AutoGen pipelines — this stays at the concept and manual-lanes level.
The full version, fast.
Graph engineering is the layer above prompt and context engineering: instead of asking one model to research, write, and grade its own answer inside a single chat, you break the work into jobs connected by arrows, with shared state moving between them. A planner splits a question into parallel research lanes, a skeptic checks the findings, a merge step turns survivors into a recommendation, and a human approves before anything expensive happens. Reserve this for work with multiple steps, sources, or risk — not for brainstorming or a quick summary. Start by running the lanes manually on a whiteboard before automating with Claude Code, LangGraph, or n8n.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 01:24
01 · Intro
Greg introduces graph engineering as a viral AI term and questions whether it's real or just another buzzword alongside prompt/context/agent engineering and vibe coding.
01:24 – 02:50
02 · Prompt, Context, and Graph Engineering
Defines the three layers: prompt engineering asks a better question, context engineering gives better information, graph engineering designs the work around the AI.
02:50 – 03:35
03 · Chat vs. Graph
Contrasts one model doing every job in one pass against a graph with separate lanes — planner, researchers, skeptic, merge — for the same startup-idea question.
03:35 – 06:44
04 · Defining Terms and Workflows
Breaks down the vocabulary — jobs, arrows, state — using customer support and YouTube content production as real-world examples of work that's already a graph.
06:44 – 08:47
05 · Knowledge Graphs vs. Agent Graphs
Separates two meanings of "graph": knowledge graphs help AI reason across relationships in data, agent graphs govern how work moves between roles. This episode focuses on agent graphs.
08:47 – 10:01
06 · When to Use Graph Engineering
Lays out six qualifying conditions — multiple steps, multiple sources, parallel paths, checks, risk, approvals — and says skip the graph if none apply; just write a better prompt.
10:01 – 13:22
07 · Worked Example: AI Bookkeeping for Shopify
Runs a full example: should you launch an AI bookkeeping product for Shopify merchants? A planner splits the question into parallel customer/competitor/distribution research, a skeptic attacks the evidence, a merge step recommends, and a human picks the next move.
13:22 – 15:10
08 · The Diamond Pattern Visualized
Names the shape from the example "the diamond pattern" — planner fans out to parallel researchers, funnels through a skeptic, then merges into a human-approved recommendation — and calls it the first graph most people should learn.
15:10 – 17:14
09 · Three Levels of Implementation
Level 1: run the lanes manually on Excalidraw or tldraw. Level 2: Claude Code or Codex, where each step writes its own file, leaving a paper trail. Level 3: orchestrated tools like LangGraph, AutoGen GraphFlow, n8n, or Make.com.
17:14 – 18:45
10 · Customer Support Graph
A support graph classifies the issue, checks account context, searches docs/policy, drafts a reply, has a checker review accuracy/tone/risk, then routes refunds and angry customers to a human.
18:45 – 19:30
11 · Content Creation Graph
A content graph moves research to thesis, examples, hook, and script, with a checker on specificity, pacing, and voice before branching into titles, thumbnails, and captions.
19:30 – 20:42
12 · Coding Graph
A coding graph plans, edits, reviews the diff, runs tests, checks the UI, hunts edge cases, and ends with a human approving the pull request.
20:42 – 22:22
13 · The Trap of Oversized Graphs
Warns that more agents doesn't mean better output — it can mean noise, repeated wrong ideas, or more time coordinating than thinking. The goal is the smallest graph that improves quality.
22:22 – 24:53
14 · Building Your First Graph
A good graph removes fake waiting, separates workers from checkers, and puts the human gate where mistakes are expensive. Walks through the first-rep steps: draw the workflow, run it by hand, then automate.
24:53 – 26:28
15 · Closing Thoughts
Recaps graph engineering as a concept for getting more out of AI platforms and signs off as host of The Startup Ideas Podcast.
Lines worth screenshotting.
- Graph engineering means designing the work around the AI as jobs connected by arrows, not living inside one giant chat.
- Prompt engineering improves the question, context engineering improves the information, and graph engineering improves the structure of the work itself.
- A single model that researches, writes, and grades its own answer is like someone writing their own performance review.
- Knowledge graphs help AI reason across relationships in data; agent graphs govern how work moves between planner, researchers, and checkers.
- A graph only earns its place when work has multiple steps, multiple sources, parallel paths, checks, risk, or approvals — otherwise a better prompt is enough.
- The diamond pattern — a planner that splits into parallel researchers, a skeptic that attacks the findings, and a merge step — is the first graph most people should learn.
- Run a new graph manually with separate lanes at least a few times before automating it with a framework.
- The intermediate level of graph engineering is Claude Code or Codex writing each step to its own file, leaving a paper trail you can compare and reuse.
- LangGraph is for state checkpoints and human-in-the-loop approval, AutoGen GraphFlow is for branching and loops, and n8n or Make.com are for graphs that touch Slack, email, or a CRM.
- More agents doesn't automatically mean better output — it can mean five AI workers confidently repeating the same wrong idea.
- The goal is the smallest graph that improves the quality of work, not the biggest graph that goes viral online.
- Every graph run should leave behind evidence, drafts, and decisions, because that residue is what makes the next run smarter.
- Support, content, and coding workflows all resolve into the same shape: classify or plan, work in parallel, check, then get human approval on anything expensive to get wrong.
Stop trusting one AI pass to research, write, and grade itself
WHAT TO LEARN
Any AI task with multiple steps, sources, or real risk gets more reliable when you split it into a planner, parallel researchers, a separate skeptic, and a human gate instead of one long chat.
- A single model that researches a question, writes the answer, and grades its own confidence is structurally the same as someone writing their own performance review — don't trust the score.
- Before reaching for AI on a multi-step task, check six conditions: multiple steps, multiple sources, parallel paths, checks, risk, or approvals. If none apply, a better prompt is enough.
- The diamond pattern — planner splits the question, parallel researchers gather evidence, a skeptic attacks it, a merge step recommends — is a reusable shape for any research or evaluation task, not just AI workflows.
- Separate the person or process doing the work from the one checking it; letting the same actor do both quietly inflates confidence in bad answers.
- Draw a workflow's steps and run them manually at least once before automating anything — automating a process you don't understand just produces mediocre output faster.
- Put the strictest approval step where a mistake would actually cost something (money, a public post, production data) and keep it lighter everywhere else.
- Every completed workflow should leave behind reusable residue — notes, evidence, drafts, decisions — so the next pass starts smarter instead of from scratch.
- More parallel workers isn't automatically better; it can just mean more noise, more coordination overhead, and the same wrong idea repeated with confidence.
Terms worth knowing.
- Graph engineering
- Designing an AI workflow as jobs connected by arrows with shared state moving between them, instead of running everything inside one long chat.
- Knowledge graph
- A structure that helps AI reason over relationships between entities like customers, companies, and products, useful when plain retrieval only returns the nearest-looking paragraph.
- Agent graph
- A structure that governs how work moves between roles such as planner, researcher, skeptic, and human approver.
- State (in a graph)
- The shared record of what a workflow knows so far as it passes between jobs.
- Diamond pattern
- A graph shape where one planner splits into several parallel researchers, funnels into a skeptic, then a merge step, ending in human approval.
- Human gate
- The point in a workflow where a person must approve the output before anything expensive or risky happens, such as a refund or a public post.
- Skeptic role
- A dedicated checking job in a graph that attacks and stress-tests findings instead of letting the same model grade its own work.
Things they pointed at.
07:42toolMicrosoft GraphRAG
16:10toolExcalidraw
16:19tooltldraw
16:03toolLangGraph
16:25toolAutoGen GraphFlow
16:33tooln8n
16:36toolMake.com
Lines you could clip.
05:16
“That is like asking someone to write their own performance review and then being shocked when they describe themselves as a visionary.”
14:08
“The tool is not the point. The tool should come after the workflow. If you automate a workflow you do not understand, you get a mess.”
21:19
“The goal is not to make the biggest graph possible... the goal is actually to make the smallest graph that improves the quality of work.”
33:13
“Once you have one graph that works, you're not just prompting AI anymore, you're managing AI work.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
analogy
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.
Prop 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 gonna 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 gonna talk about all that and how you can do it. It's gonna 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 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 their 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'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 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 directions, then a 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 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, 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 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, 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 kinda 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 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 stunning 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 gonna 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 merchant.
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 wanna 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 lang 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 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 TL draw a TL draw 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, codecs, or a repo where each step writes files. The planner writes plan dot m d, 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 act 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.
So 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 AutoGen, Graphflow, and that's useful when you want directed workflow with sequential steps, parallel steps, conditional branches, loops.
Tools like nan, 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. 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 using things like lang lang graph or Claude code.
But for the purpose of this episode, I think we just wanna 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.
The one that comes to mind first is customer support. So a simple support graph might start by classifying the issue.
Is it billing? Is it product confusion? 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 the support ticket, because the support ticket is not the real workflow. The real workflow is understanding and researching and drafting checking and approving.
It's probably starting to click now. Content 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 the 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 purse 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 some 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 wanna 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 meeting 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, like, asset for you. So if you wanna get into graph engineering and you're like, how do I start? Here's 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 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 gotta have a human gate that's stricter.
Then I would run it manually once. This is the whole first rep that we wanna 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 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 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 being an agent manager and 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 you know, 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, you know, like, comment, and subscribe.
Follow on on Spotify and Apple. And, you know, I feel grateful that you're here, that I 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.
The Hook
The bait, then the rug-pull.
Greg Isenberg opens by admitting his first reaction to "graph engineering" going viral on X was skepticism — just another buzzword to make everyone feel behind. Then he makes the case it's one of the useful ones: it's not about writing a better prompt, it's about not trusting one model to research, write, and grade its own answer in a single pass.
Named ideas worth stealing.
01:29list
Prompt → Context → Graph
- Prompt engineering — how you ask a better question
- Context engineering — how you give better information
- Graph engineering — how you design the work around the AI
Three layers of getting better work out of AI, with graph engineering as the layer above the other two: not one giant chat, but a managed workflow.
Steal forframing any AI-workflow explanation to a non-technical audience
13:54model
The Diamond Pattern
- Planner
- Customer researcher (parallel)
- Competitor researcher (parallel)
- Distribution researcher (parallel)
- Skeptic
- Merge + Human YES
One planner splits a question into parallel research lanes, a skeptic attacks the surviving evidence, and a merge step turns it into a recommendation a human approves.
Steal forany research or evaluation task (startup idea, competitor teardown, hiring decision) that currently gets answered in one chat message
15:41list
Three Levels of Implementation
- Level 1: Manual lanes on a whiteboard (Excalidraw/tldraw)
- Level 2: File-based (Claude Code/Codex, each step writes its own .md file)
- Level 3: Orchestrated (LangGraph, AutoGen GraphFlow, n8n, Make.com)
Draw and run the graph manually before automating it — automating a workflow you don't understand yet just produces mediocre work faster.
Steal fordeciding how much tooling investment a new AI workflow deserves before building it
08:57acronym
When a Graph Earns Its Place (6 conditions)
- Multiple steps
- Multiple sources
- Parallel paths
- Checks
- Risk
- Approvals
If none of these six conditions are true for a task, a graph is overhead — just write a better prompt instead.
Steal fora quick gut-check before building any multi-agent system
17:39list
Three Graphs You Can Steal
- Support: classify → account context → docs+policy → draft reply → checker (accuracy/tone/risk) → human approves refunds/angry customers
- Content: research → thesis → examples → hook → script → checker (specificity/pacing) → titles/thumbnails/captions
- Code: plan → edit → review the diff → run tests → check the UI → hunt edge cases → human approves the PR
Three ready-made agent graphs for the most common creator/founder workflows, each with a checker role that isn't the same agent as the writer.
Steal forsupport ticket handling, YouTube/content production, and code review pipelines
How they asked for the click.
VERBAL ASK
25:47subscribe
“For more, you know, like, comment, and subscribe. Follow on Spotify and Apple.”
Soft, single-line CTA at the very end asking for likes/comments/subscribes and a podcast follow — no mid-video pitch or product push.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
