Graph Engineering, Explained: Design AI Work Like a Small Team

Every few weeks AI Twitter invents a new term designed to make you feel behind.

Prompt engineering. Context engineering. Vibe coding. Loop engineering.

Now it's graph engineering, and Greg Isenberg just spent a full episode on it. My first reaction was the same as his: is this real, or did we just rename "having a process"?

I watched the whole thing. It's real. And it explains something I got wrong for months: I kept trying to write the perfect prompt when the actual problem was the workflow around the prompt.

Here's the full episode, then my breakdown for founders who don't want a computer science lecture.

What Graph Engineering Actually Is (In One Sentence)

Greg's framing is the cleanest one I've heard:

→ Prompt engineering is how you ask AI a better question.
→ Context engineering is how you give AI better information.
→ Graph engineering is how you design the work around the AI.

A "graph" sounds academic. It just means jobs connected by arrows. Each job is a step. The arrows show what depends on what. The notes moving through the system are the "state", which is a fancy word for "what do we know so far".

You already work this way with humans. A support ticket isn't "answer the ticket". It's classify the issue, check the account, look up the policy, draft a reply, decide if a human needs to review it. Draw those steps with arrows and you have a graph.

Greg's point: your AI work should run the same way, instead of living inside one giant messy chat.

The Problem With Asking ChatGPT "Should I Build This?"

This part of the episode stung, because I've done exactly this.

You open a chat. You type "should I build this idea?" The model gives you a confident answer with market size, competitors, a go-to-market plan. You feel like you did research.

But slow down and look at what happened. One model, in one pass, decided what mattered, did the research, interpreted the evidence, wrote the recommendation, and graded its own confidence.

Greg's line: that's like asking someone to write their own performance review and being shocked when they describe themselves as a visionary.

And the stakes aren't small. You might spend two years of your life on the answer to that one lazy question.

The Diamond: How a Real Research Graph Works

The core shape Greg teaches is a diamond. One question splits into parallel paths, gets checked, then merges back into one answer.

His example: "Should I launch an AI bookkeeping product for Shopify merchants?"

The graph version looks like this:

1. Planner. Breaks the question into angles: customer pain, competitors, distribution, pricing, risks.

2. Three researchers, running at the same time. One studies Shopify merchants (are they on QuickBooks, spreadsheets, or paying a bookkeeper who cleans up the mess once a month?). One studies competitors (existing Shopify apps, accounting firms, freelancers on Upwork doing it manually). One studies distribution (which newsletters merchants read, which app store categories they search, which agencies already have their trust).

3. Skeptic. A separate pass whose only job is to kill weak findings. Which claims have no support? Which data is stale? Where are we confusing pain with willingness to pay?

4. Merge. Turns the surviving evidence into a one-page recommendation: pursue, pause, or kill. What's the wedge, who's the first customer, what do we test this week.

5. Human gate. You. You approve the next move before money or months get spent.

The output is still a written report. The difference is the work behind it. The checking is a separate job from the writing, and that one change fixes most of what makes AI research untrustworthy.

Start Embarrassingly Manual (Level 1)

This is where Greg gives the advice most people skip, and it's the part I'd tattoo on the inside of every founder's laptop lid.

Do not start with LangGraph. Do not start with AutoGen or a custom agent framework on day one.

Start by running the graph manually:

→ Open a blank Excalidraw or tldraw board.
→ Write the final outcome at the top ("a one-page recommendation on whether this idea is worth testing").
→ Draw the jobs: planner, customer researcher, competitor researcher, distribution researcher, skeptic, merge, human approval.
→ Draw the arrows where work actually depends on other work.
→ Run each lane as its own separate AI chat.

Yes, it's slower than a fully automated system. But if the manual version doesn't produce better work, automating it just produces mediocre work faster.

Draw the graph before you automate the graph. Run it three times by hand first.

Level 2 and Level 3: Files, Then Frameworks

Once the manual version works, the intermediate move is running it in Claude Code or Codex inside a repo, where each step writes a file.

The planner writes plan.md. The researchers write customer.md, competitors.md, distribution.md. The skeptic writes review.md. The merge step writes recommendation.md.

I love this version because it leaves a paper trail. You can see what happened, compare runs, and reuse the structure next week. It's the same reason I make podcast guests walk me through their actual numbers instead of their narrative: the artifacts don't lie.

Level 3 is the tooling everyone starts with by mistake: LangGraph when you need checkpoints, persistence, and human-in-the-loop controls. AutoGen GraphFlow for conditional branches and loops. n8n or Make when the graph touches Slack, email, Airtable, or your CRM.

The tool comes after the workflow. Automate a workflow you don't understand and you get a mess with better uptime.

Where This Makes Actual Money

Three workflows from the episode where graph thinking pays fastest:

Customer support. Classify the issue → check account context (new customer? high value? already frustrated?) → search your docs and policies → draft the reply → a checker reviews tone and accuracy → a human approves anything touching refunds, cancellations, or promises you'll regret. That last gate is the difference between "AI support" and a public apology thread.

Content. Research → thesis → examples → hook → script, with a checker asking whether the examples are specific and whether the writing sounds like a person (Greg's test: "does this sound like a human or someone trapped inside a SaaS onboarding flow?"). Then it branches into titles, thumbnails, captions. This is close to how the marketing agent stacks I broke down in Marketing Agents Are Too Good Now actually run.

Coding. Plan → one agent edits → another reviews the diff → another runs tests → another checks the UI → you approve the pull request. Every serious AI coding setup is converging on this shape.

Notice the pattern: the model doing the work is only one node. The leverage is in the checking, merging, and deciding what's safe to ship.

The Mistake: Bigger Graphs Are Not Better Graphs

The viral screenshots on X are always these sprawling 40-node monsters. Greg calls this out directly, and he's right.

More agents can just mean more noise. Five AI workers confidently repeating the same wrong idea. A system that spends more time coordinating than thinking.

The goal is the smallest graph that improves the quality of the work:

→ Run independent jobs in parallel (kill the fake waiting).
→ Separate workers from checkers.
→ Put human approval where mistakes are expensive.
→ Stop when the answer is good enough.

If you're brainstorming 10 names or summarizing an email, you don't need a graph. You need a chat. Graphs earn their cost when work has multiple steps, multiple sources, and an output that needs checking before it matters.

The Underrated Part: Graphs Produce Memory

The point that stuck with me most wasn't about speed or quality. It was about compounding.

Every customer research graph leaves behind better customer notes. Every content graph leaves behind examples and audience insights. Every support graph leaves behind product feedback. The graph produces the work, and it also produces the memory that makes the next graph smarter.

That's the moat. Everyone has the same prompts. Nobody has your accumulated state.

This connects to something I keep saying on the podcast: the founders winning with AI right now aren't better prompters. They're better managers. I went deep on that in Managing AI Agents Is the Most Valuable Skill of 2026, and graph engineering is basically the org chart for it.

Your First Graph This Week

Greg's homework, compressed:

→ Pick one AI workflow you already run weekly (idea research, podcast prep, landing page reviews, customer feedback).
→ Write the final output in one sentence.
→ List the jobs a great human team would do.
→ Draw arrows only where one job truly depends on another.
→ Add a skeptic. Add one human gate before anything expensive.
→ Run it manually once.

After the first rep, you stop asking "what's the perfect prompt?" and start asking "what's the perfect workflow?". That shift is the whole game.

Once you have one graph that works, you're not prompting AI anymore. You're managing AI work.

FAQ

What is graph engineering?

Graph engineering is designing AI work as a set of connected jobs (a graph) instead of one long chat. A planner splits the task, workers run in parallel, a skeptic checks the output, a merge step combines the surviving evidence, and a human approves the result. It's the workflow layer on top of prompting.

What's the difference between a knowledge graph and an agent graph?

A knowledge graph maps how information connects (this customer works at this company, this issue relates to this feature), which helps AI reason over relationships where normal RAG fails. An agent graph maps how work moves between AI workers and humans. Greg's episode, and this article, are mostly about agent graphs, because you can start using those today with zero infrastructure.

Do I need LangGraph or n8n to do graph engineering?

No. Start manually: separate chat lanes for each job, an Excalidraw board for the arrows, and you running the handoffs. Move to Claude Code with markdown files per step once the structure works. Only reach for LangGraph, AutoGen, n8n, or Make after the manual version has produced better output three times in a row.

When is a graph overkill?

Single-step tasks: naming brainstorms, short summaries, quick rewrites. A graph pays off when the work has multiple steps, parallel research angles, and an output where being wrong is expensive (research you'll bet months on, code you'll ship, replies customers will read).