Jonathon's AI Wiki

Graph Engineering — Designing the Work Around the Agent (Greg Isenberg)

8 min read

Source: raw/Why_Graph_Engineering_will_10x_your_Claude_Codex.md — Greg Isenberg, Startup Ideas podcast, youtu.be/JWhICz1QR8M, transcript fetched 2026-08-05.

“Graph engineering” is the latest term in the prompt → context → agent → loop lineage this topic tracks, and Isenberg’s episode is the first plain-English explainer of it in the wiki. The one-line definition: prompt engineering is how you ask the model, context engineering is how you inform it, and graph engineering is how you design the work around it — so the job stops living inside one long chat. For this wiki it lands as the shape layer sitting next to the loop as the unit of work: a loop says “keep going until done,” a graph says “here is who does what, in what order, and who checks it.”

Key Takeaways

  • The core move is splitting one blob into named jobs. The failure mode Isenberg names is that a single model in a single pass “decided what mattered, researched the market, interpreted the evidence, wrote the recommendation, and graded its own confidence.” A graph gives each of those its own lane.
  • A graph is just jobs connected by arrows, plus shared state. State = “what does the system know so far.” Nothing more computer-science-y than that is required to start.
  • The canonical shape is a diamond: one question → split into parallel independent jobs → a skeptic that attacks the findings → a merge into one recommendation → a human gate before acting.
  • Checking must be its own job. “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 visionary.” This is the same maker/checker rule as verifier-first loops, arrived at from the workflow side rather than the verification side.
  • Two different things are called “graph” in AI, and conflating them is the main source of confusion. A knowledge graph helps a model reason over relationships in data (Isenberg cites Microsoft GraphRAG; it helps where plain RAG retrieves a similar-looking chunk but the answer needs connections across people, companies, and events). An agent graph governs how work moves. This episode — and this article — is about agent graphs.
  • Bigger graphs are not better graphs. “Sometimes more agents mean more noise… five AI workers confidently repeating the same wrong idea… the system spends more time coordinating than thinking.” The stated goal is the smallest graph that improves the quality of the work, explicitly against the big-graph screenshots that go viral on X.
  • The compounding payoff is memory, not speed. Every research graph leaves better customer notes, every content graph better examples, every support graph better product feedback — “the graph produces the work, but it also produces the memory that makes the next graph smarter.”

When a graph is worth it

Isenberg’s rule: use a graph when the work has multiple steps, some steps can run at the same time, and the final output needs checking before it matters.

  • Not worth it: brainstorming 10 project names, summarizing a short email.
  • Worth it: deep research, go-to-market plans, support triage, code review, sales-call prep, customer-feedback synthesis, recurring content production.

The three tiers

The episode’s most useful practical content is that you should not start with a framework.

TierWhat it isWhen
Level 1 — manual lanesRun each job yourself in a separate lane/chat. No automation at all.The first three reps. “If the manual version doesn’t produce way better work, automating it will just produce mediocre work way faster.”
Level 2 — files as stateClaude Code / Codex / a repo where each step writes a file: planner → plan.md, researchers → customer.md / competitors.md / distribution.md, skeptic → review.md, merge → recommendation.md.Once the shape works. Leaves a paper trail, diffable across versions, reusable next week.
Level 3 — orchestratedLangGraph (state checkpoints, persistence, human-in-the-loop approvals), AutoGen GraphFlow (sequential/parallel/conditional/loops), n8n or make.com (when the graph touches Slack, email, Airtable, CRM).Only after the workflow is understood. “If you automate a workflow you do not understand, you get a mess.”

The first rep is to draw the graph before you automate the graph — Isenberg does this on a blank Excalidraw/tldraw board: final outcome at the top, then the jobs (planner, three researchers, skeptic, merge, human approval), then the arrows.

Level 2 is the tier this wiki is already equipped for: it is the same files-as-state discipline as Anthropic’s harness design and the artifact trail in verifier-first loops.

Worked example — the startup-idea diamond

Question: “Should I launch an AI bookkeeping product for Shopify merchants?”

  1. Planner — decides the answer needs customer pain, competitive landscape, GTM wedge, pricing pressure, risks.
  2. Three researchers in parallel (they don’t depend on each other) — one on Shopify merchant bookkeeping pain (QuickBooks? spreadsheets? hired bookkeepers? annoyed at tax time?), one on competitors (existing Shopify apps? accounting firms doing it manually? Upwork/Fiverr freelancers software could replace?), one on distribution (what newsletters do they read? which agencies already have trust? which app categories do they search?).
  3. Skeptic — which claims are actually supported, which evidence is stale, which competitor is being ignored, where are we confusing pain with willingness to pay, where did the model sound confident without proving anything.
  4. Merge — pursue/pause/kill, the wedge, the first customer, what to test this week, and what evidence would change our mind.
  5. Human gate — the decision itself. “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.”

Isenberg gives three more sketches: support (classify → check account context → search docs/policy → draft → checker reviews for accuracy/tone/risk → human approves anything touching refunds, angry customers, or legal risk), content (research → thesis → examples → hook → script → checker on specificity/pacing/voice → branch to titles, thumbnails, captions, B-roll), and coding (plan → edit → review the diff → run tests → check the UI in a browser → hunt edge cases → human approves the PR).

Where the human gate goes

Calibrate gate strictness to the cost of being wrong: light for a private memo; strict for a customer email, a public post, a code deploy, a refund, or anything touching production data. This is the same risk-tiering as the loop security tax.

Try It

  1. Pick one workflow you already run with AI every week (idea research, landing-page review, customer-feedback analysis).
  2. Write the final output in one sentence — e.g. “a one-page recommendation on whether this idea is worth testing.”
  3. List the jobs a great human would do, then draw arrows only where a step genuinely depends on another.
  4. Delete the fake waiting — run the independent jobs in parallel.
  5. Add a skeptic, merge the survivors, and put one human gate before the expensive decision.
  6. Run it manually once before automating anything.

Terminology note — “graph engineering” is not an Anthropic term

Isenberg is careful that he is explaining a phrase already circulating (“a term I keep seeing going viral on Twitter”), not coining one, and his opening question is whether it is real or “another phrase to make everyone feel behind.”

That caution is warranted. Around 2026-08-01 a widely-shared post summarized a ~30-minute Boris Cherny video as “build a graph that writes itself” and linked a “graph engineering” guide. Cherny replied publicly: “I did not use the word ‘graph’, nor am I talking about graphs in this video. Please don’t attribute words to me that I did not say. I do encourage people to watch the video!” — and a community note was added to the original post (x.com/bcherny/status/2083782540570279992).

So: treat “graph engineering” as community vocabulary for a real design practice, not as first-party Anthropic terminology. The underlying practice — parallel specialist jobs, a separate checker, a merge, a human gate — is first-party, but Anthropic’s own vocabulary for it is subagents, dynamic workflows, and the loop taxonomy in Getting Started with Loops.

Open Questions

  • The Cherny correction above is sourced from a public X permalink surfaced during the 2026-08-05 inbox sweep, but the post itself was not staged into raw/ (triaged as reply-banter), so it is not in this article’s sources: array. Verify against the permalink before relying on the exact wording, and stage it if the attribution question is ever revisited.
  • Isenberg offers an “advanced graph engineering tutorial” using LangGraph or Claude Code if there is interest — not yet published as of this ingest. Worth a refresh if it lands.
  • No cost figures, latency numbers, or before/after quality measurements are given anywhere in the episode. Every claim of improvement is qualitative. The topic’s economics article is the counterweight until someone publishes a measured comparison.

Graph View

Backlinks