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.

>> [music]

>> 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.