Graph Engineering for Claude and Codex: Turn One Giant Chat Into a Managed Workflow

Direct Answer

Graph engineering means designing the work around the model instead of asking one enormous chat to do everything. Break a recurring workflow into jobs, connect those jobs with explicit dependencies, preserve shared state, run independent branches in parallel, separate creation from checking, and place a human approval before expensive or irreversible actions.

Greg Isenberg's framing is useful because it names a change many Claude Code and Codex users already feel. Better prompting improves one turn. Better context improves what the model can see. A better graph improves how the whole job moves. The headline's "10x" is motivational, not a measured benchmark; a graph earns its complexity only when it produces more accepted work, fewer costly errors, or faster decisions.

Watch Greg Isenberg's Episode

Credit: concept, worked example, and episode by Greg Isenberg, host of the Startup Ideas Podcast. Follow Greg on X and watch the original video. This article turns his framework into an implementation guide and checks the named tools against their current documentation.

What Graph Engineering Means

"Graph engineering" is not yet a universal technical standard. Here it is best understood as a design discipline for graph-shaped agent workflows: nodes perform bounded jobs, edges determine what can happen next, and state carries approved information through the system. Some paths are sequential, some run in parallel, some branch on conditions, and some loop until a measurable acceptance test passes.

These layers are complements. A graph full of vague prompts still fails. A strong prompt with stale context still fails. A beautifully curated context window inside a confused one-shot workflow still fails. The architecture becomes useful when each layer has one clear responsibility.

Knowledge Graphs and Agent Graphs Are Different

A knowledge graph models how information connects: a customer belongs to an account, bought a product, opened a ticket, and is covered by a policy. Microsoft's GraphRAG, for example, extracts entities, relationships, and claims from source material, then builds community reports that can support local or global retrieval.

An agent graph models how work moves: classify the ticket, retrieve account context, search policy, draft the response, check risk, and ask a person to approve a refund. The first graph helps the system understand relationships in the evidence. The second controls execution. One workflow can use both, but installing a knowledge graph does not give you reliable orchestration, and drawing an agent graph does not make its facts true.

Jobs, Arrows, and State

Greg reduces the vocabulary to three useful parts. Official LangGraph documentation uses the closely related terms nodes, edges, and state.

State should not be an unbounded transcript. Keep the brief, assumptions, source references, decisions, open questions, budgets, and status in explicit fields. Preserve large evidence as files and point to it. This makes failures inspectable and allows a later node to consume only the context it needs.

The Diamond Pattern: One Question, Parallel Evidence, One Decision

Greg's worked example asks whether to launch an AI bookkeeping product for Shopify merchants. One giant prompt might produce a confident market essay. The graph instead creates competing evidence paths and a deliberate merge.

Question
   |
 Planner
 /   |   \
Customer  Competitors  Distribution
 \   |   /
  Skeptic
     |
 Synthesizer
     |
 Human gate
     |
 Next experiment

1. Planner: decomposes the decision into customer pain, competitive landscape, distribution, pricing, and risk. It creates the research contract but does not decide the answer.
2. Customer researcher: looks for recurring bookkeeping pain, current workarounds, switching friction, urgency, and evidence of willingness to pay.
3. Competitor researcher: maps accounting products, Shopify apps, service substitutes, pricing, reviews, and neglected segments.
4. Distribution researcher: tests reachable channels, partnerships, communities, app-store economics, and the cost of earning trust.
5. Skeptic: attacks stale sources, unsupported market sizes, circular claims, hidden compliance work, and the common confusion between expressed pain and purchase intent.
6. Synthesizer: produces pursue, pause, or kill; a narrow wedge; the first target customer; the cheapest useful experiment; and evidence that would reverse the recommendation.
7. Human gate: chooses the next action and owns the money, customer contact, legal exposure, and product commitment.

The shape matters. Research branches can run in parallel because they do not depend on one another. Critique waits for all three. Synthesis waits for the critique. The human does not review raw agent chatter; they review a decision packet with sources, disagreements, uncertainty, and a proposed test.

Three Levels of Implementation

Level 1: draw it and run it manually

Start in Excalidraw, tldraw, a whiteboard, or a plain document. Open separate Claude or Codex threads for planner, researchers, checker, and synthesizer. Pass artifacts between them deliberately. This feels less magical than full automation, which is precisely why it exposes missing dependencies and vague acceptance criteria quickly.

Level 2: use a repository as the state machine

Claude Code and Codex already work well with durable files. Give one folder to each run and require every job to read named inputs and write named outputs. A practical structure for the Shopify example could be:

runs/2026-08-03-shopify-bookkeeping/
  00-brief.md
  10-plan.md
  20-customer.md
  20-competitors.md
  20-distribution.md
  30-review.md
  40-recommendation.md
  state.json
  sources.csv

The filenames are the graph made visible. Git records changes. The source table makes claims traceable. state.json holds status, budgets, approvals, and retry counts. This is often enough for a high-value workflow operated by one person.

Level 3: add an orchestrator after the graph works

A Production Node Contract

A box on a diagram is not an implementation. Before automating a node, give it a contract that another person could test without reading the prompt.

This contract is the difference between orchestration and choreography by hope. It also makes model routing easier: a cheap model can classify a low-risk input, while a stronger model handles synthesis, and deterministic code validates the schema before either result reaches production.

Three Graphs You Can Reuse

1. Customer support

Classify issue -> load account context -> search documentation and policy -> draft answer -> check accuracy, tone, and risk -> send or escalate.

Run account lookup and documentation search in parallel when possible. A deterministic policy check should catch hard limits. Route refunds, account changes, legal threats, safety issues, angry customers, and promises outside policy to a person. Store the evidence used for the reply, not just the final prose.

2. Content production

Research -> thesis -> examples -> hook -> script -> editorial check -> titles, thumbnails, captions, and B-roll in parallel -> human publish approval.

The checker scores specificity, evidence, pacing, voice, and originality. Distribution assets branch only after the core argument is accepted, so the system does not efficiently multiply a weak idea. Publishing credentials remain outside the creative nodes.

3. Software delivery

Plan -> edit -> inspect diff -> run tests -> exercise browser or UI -> probe edge cases -> human pull-request approval.

Tests and static analysis should be deterministic wherever possible. Browser evidence should include the route, viewport, console output, and screenshots. A second coding agent can review the diff, but passing tests and an agent's confidence do not remove the need for human review around authentication, money, destructive operations, migrations, secrets, or broad shared behavior.

Separate the Writer From the Checker

Greg's advice to separate creation from verification is sound. A writer is optimized to complete the artifact; a checker is optimized to find reasons it should not pass. Give the checker the brief, sources, output, and rubric, but avoid feeding it the writer's self-justification. Ask for evidence-backed defects, not a vague score.

The separation is helpful, not magically independent. Two roles can share the same model, blind spots, retrieved sources, and assumptions. For high-risk work, combine the reviewer with deterministic tests, a different evidence source, a separate model where useful, and an accountable human. The checker should be able to return pass, revise, or escalate, with a bounded number of revisions.

State, Interrupts, Retries, and Side Effects

Production graphs fail in mundane ways: a request times out after the external system accepted it, a human responds tomorrow, a model returns malformed JSON, a source changes, or a retry sends the same message twice. The graph must survive those conditions.

• Checkpoint state. Persist the state after important nodes so the run can resume rather than restart. LangGraph's checkpointers and threads are designed for this class of durable state.
• Use interrupts for approval. A human-in-the-loop step should pause, save state, wait, and resume with the person's decision. It should not hold a fragile process open.
• Make side effects idempotent. Use a stable operation key and check whether the email, invoice, deployment, or CRM update already happened before retrying.
• Cap loops. Set a maximum revision count, budget, deadline, and escalation path. "Keep improving" is not a safe stop condition.
• Separate evidence from conclusions. Preserve source URLs, dates, test output, and raw measurements so the final recommendation can be audited.
• Log decisions, not private chain-of-thought. Keep inputs, outputs, tool calls, approvals, errors, and concise reasons. Do not design the system around extracting hidden reasoning.
• Default to least privilege. Research nodes rarely need send, delete, deploy, or payment permissions. Grant the minimum tool access at the last responsible moment.

The Oversized-Graph Trap

A complicated graph can look rigorous while merely repeating the same weak idea through more expensive steps. Every extra agent creates context loss, latency, cost, duplicated research, another schema boundary, and another place to fail. Do not create separate roles because the labels sound impressive.

Measure cost per accepted result, not number of agents, tokens consumed, or sophistication of the diagram. If the manual two-step workflow already passes, do not build a twelve-node platform.

Build Your First Graph This Week

1. Pick one recurring workflow. Choose something you run at least weekly and can evaluate, such as a customer reply, research memo, content brief, or small code change.
2. Define the final accepted output. Write the rubric before the graph. Include evidence, quality, risk, time, and cost.
3. List the real jobs. Use verbs: classify, retrieve, compare, draft, test, approve. Split only when inputs, tools, or checks differ.
4. Draw dependencies. Connect jobs that truly depend on one another. Run independent research or tests in parallel.
5. Design state. Create a small schema for the brief, artifacts, sources, decisions, status, budgets, retries, and approvals.
6. Place the human gate. Put it immediately before the action where an error becomes expensive, public, sensitive, or hard to reverse.
7. Run it manually five times. Save every artifact and record corrections, failure points, total cost, elapsed time, and accepted-result quality.
8. Automate only the stable path. Start with file handoffs or a small script. Introduce an orchestration framework only when persistence, branching, concurrency, or integrations justify it.

Video Chapters

Bottom Line

The valuable part of graph engineering is not drawing arrows or hiring a committee of agents. It is making the workflow explicit: what each step owns, what evidence it needs, what it produces, who checks it, when it stops, and where a person takes responsibility.

Claude and Codex become more dependable when they operate inside that structure. Start with one recurring job, build the smallest graph that can outperform a single chat, preserve the artifacts, and automate only after the real dependencies are visible. The graph should make work easier to inspect and improve, not merely more impressive to describe.

Sources and Further Reading

• Greg Isenberg: Why Graph Engineering will 10x your Claude/Codex
• LangGraph reference: stateful agent orchestration
• LangGraph Graph API: state, nodes, and edges
• LangGraph interrupts and human-in-the-loop execution
• Microsoft AutoGen GraphFlow documentation
• Microsoft GraphRAG overview
• Microsoft GraphRAG query engine
• n8n: human review for AI tool calls
• n8n workflow executions and retries
• Make AI Agents: introduction
• Make: scenarios as structured agent tools
• Make: scenario inputs and outputs