YT YouTube2Text

YouTube2Text → Transcripts → Why Graph Engineering will 10x your Claude/Codex

Why Graph Engineering will 10x your Claude/Codex — Transcript

by Greg Isenberg · 4,031 words · 644 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

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

About this transcript

This page contains the full transcript of Why Graph Engineering will 10x your Claude/Codex by Greg Isenberg, generated from the public captions YouTube serves with the video. The transcript has 4,031 words across 644 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.