What Is Graph Engineering? How to Use the Fake-Edge Test

Graph engineering is how you design multi-step AI work as a directed graph of jobs, not as one long chat.

This page is a how-to. It is for people who already run agents and still run every step in a line. If you are searching for "graph engineering", "fake-edge test", or "agent graph vs loop", start here.

What is graph engineering?

Graph engineering is the practice of designing multi-step AI workflows as a directed graph of independent jobs connected by dependencies, rather than a single chat conversation.

Each step in the workflow runs as a separate AI agent call with its own input and output. The graph structure defines which jobs depend on other jobs and which can run in parallel.

The term gained traction on X in mid-July 2026. Peter Steinberger, creator of OpenClaw, posted a question that received millions of views: "Are we still talking loops or did we shift to graphs yet?" Within days, the AI community adopted "graph engineering" as the name for a design problem builders were already solving.

Harrison Chase, who built LangGraph at LangChain, noted that the concept is not new. LangGraph has modeled agent workflows as graphs for three years. What changed in July 2026 was the vocabulary, not the capability.

The evolution: five layers of AI engineering

Each year, the leverage in AI engineering moves one level further from the model. Each layer builds on the one before it.

Graph engineering is the newest layer. It does not replace the others. It sits on top of them. A graph node can contain a prompt, use context, run inside a harness, and execute a loop. The graph decides how nodes connect.

What problem does graph engineering solve?

A single AI chat pass handles the entire workflow in one request. The model decides what matters, researches it, interprets the evidence, writes the answer, and grades its own confidence. All of that happens inside one model call with no separation between research, analysis, and review.

Graph engineering splits that single pass into separate jobs. A planner defines the angles. Researchers work in parallel. A reviewer checks the findings. A synthesizer combines what survived. A human approves before action.

The output is the same type of deliverable. The process has separation of concerns.

Key terms in graph engineering

Knowledge graph vs agent graph

The word "graph" has two meanings in AI. The distinction matters.

This article covers agent graphs. That is the version you can build and use today.

A loop is a simple graph

A common misconception is that loops and graphs are alternatives. They are not. A loop is a single-node graph with an edge back to itself.

Loop engineering designs the cycle one agent repeats: plan, act, verify, retry. Graph engineering decides how several of those loops connect. Every loop is a graph. Not every graph is a loop.

This matters because it means graph engineering does not replace loop engineering. It is the layer above it. A node in a graph can contain a full agent loop inside it.

When to use a graph

Use a graph when the work has:

• Multiple steps
• Multiple sources
• Parallel paths (things that can happen at the same time)
• Different tools or models per step
• Checks needed before the output matters
• Risk involved
• Approvals required

Use cases:

• Deep research
• Go-to-market plans
• Support triage
• Code review
• Content production
• Customer feedback synthesis

When not to use a graph

Do not use a graph when:

• The task is small (adding one function, fixing one bug). Coordination costs more than the work.
• You want to approve every step. A graph runs wide without you. If you need hands-on control, use a single chat.
• You do not know what you are looking for yet. Exploratory work needs one agent you can steer, not a fleet locked into a plan. LangChain moved its own deep research tool from a predefined graph to a more agentic loop for this reason.
• The steps depend on each other in strict order. Forcing a graph onto sequential work adds cost with no speedup.

What is the fake-edge test?

The fake-edge test is a method for finding unnecessary dependencies in a workflow. It is the most useful idea in graph engineering.

Walk your workflow step by step. At each arrow, ask one question: does this step need the result of the step before it?

• If yes, the edge is real. Keep the order.
• If no, the edge is fake. Those two jobs can run at the same time.

Example: "Review file A for bugs, then review file B for bugs." This reads like a sequence. But file B never looks at what file A returned. They are chained because someone typed them in that order. Run them side by side. The whole thing finishes in the time of the slower job, not both added together.

You will find two or three fake edges in almost any workflow. Each one is wasted time.

What is the diamond pattern?

The diamond is the most common graph pattern. The work splits into parallel jobs, a reviewer checks the results, and everything merges into one answer.

The four stages:

1. Fan out — a planner breaks the question into angles
2. Parallel research — multiple jobs run at the same time
3. Review — a checker tests the findings for accuracy and gaps
4. Synthesize — a merger combines surviving evidence into a recommendation

Example: Should I launch an AI bookkeeping product for Shopify merchants?

The three research jobs do not depend on each other. They run in parallel. The skeptic needs all three before it can check. The merger needs the skeptic pass before it can synthesize.

Why the reviewer must be a separate job

A lot of AI research fails because the same model that wrote the answer also graded the answer. The model checks its own work. It has no reason to find fault.

In a good graph, checking is a separate job. The checker does not share context with the worker it checks. If it does, it reads the output with the worker's assumptions already in mind.

How to build a graph: three levels

Level 1: Manual (no tools)

1. Draw the workflow on a whiteboard, Excalidraw, or TLDraw
2. Give each job its own lane
3. Run each job yourself in a separate chat session
4. One chat does customer research. Another does competitor research. Another does distribution.
5. You play the reviewer. You play the synthesizer.
6. If the manual version does not produce better work, automating it will produce mediocre work faster.

Level 2: Files in a repo

1. Use Claude Code, Codex, or any tool where each step writes its own file
2. The planner writes plan.md
3. Researchers write customer.md, competitors.md, distribution.md
4. The reviewer writes review.md
5. The synthesizer writes recommendation.md
6. This leaves a paper trail. You can compare versions and reuse the structure.

Level 3: Frameworks

Use these tools after you understand the workflow, not before. If you automate a workflow you do not understand, you get a mess. Draw before you automate.

Example graphs

Customer support graph

1. Classify the issue (billing, bug, cancellation risk)
2. Check account context (new customer, high value, frustrated)
3. Search docs and policies
4. Draft a reply
5. A checker reviews for accuracy, tone, and risk
6. A human approves anything involving refunds, angry customers, or legal exposure

Content creation graph

1. Research the topic
2. Write a thesis
3. Find examples
4. Write a hook
5. Draft the script
6. A checker asks: are the examples specific? Does the pacing work? Does it sound human?
7. Branch into titles, thumbnails, and captions

Code review graph

1. Plan the change
2. One agent edits the code
3. Another agent reviews the diff
4. Another agent runs tests
5. Another agent checks the UI in a browser
6. Another agent hunts for edge cases
7. A human approves the pull request

Parallel review pattern

The parallel review pattern is one of the most effective graph shapes. Instead of running three checks one after another, run them all at once.

Sequential (loop):

Plan → Code → Security review → wait → Logic review → wait → Style review → wait → Synthesize

Parallel (graph):

Plan → Code → [Security review, Logic review, Style review] → Synthesize
                     ↘                    ↗
                        → Synthesize →

Three reviews fire at the same time. The wall-clock time drops from three sequential cycles to one parallel cycle.

How to build your first graph: step by step

1. Pick one workflow you already run with AI every week. Research, content, support, or code review.

1. Write the final output in one sentence. Example: "I want a one-page recommendation on whether this idea is worth testing."

1. List the jobs. Write each job a skilled human would do. Clarify the question. Research customers. Research competitors. Look at distribution. Check risks. Check evidence. Make the recommendation.

1. Draw arrows where work depends on another step. Customer research and competitor research can happen at the same time. The reviewer needs all research before it can check. The recommendation needs the reviewer pass before it can merge.

1. Delete fake edges. Any two jobs with no real dependency between them can run in parallel.

1. Add a human gate before the expensive decision. A private memo can use a light gate (a quick read). A customer email, public post, code deploy, or refund needs a strict gate (a full review).

1. Run it manually once. Do not build automation. Create the jobs and the arrows and run them yourself.

1. After it works three times manually, consider tools (Level 2 or Level 3 above).

Cost of graph engineering

The coordination gets cheaper as you automate. The work itself does not. Each agent in the graph burns tokens. Cost scales with the number of agents and how many run at once.

Real example: the Bun runtime rewrite

Jarred Sumner, creator of the Bun JavaScript runtime, used 64 parallel AI agents to rewrite the runtime from Zig to Rust. The rewrite covered 535,496 lines of Zig code, produced over a million lines of Rust, and took 11 days with 6,500 commits. It passed 99.8% of the existing test suite.

The cost was approximately $165,000 in API usage. The work also needed a human watching the entire time and drew criticism from the Zig creator, who called the output "unreviewed slop."

Cost control rules

• Start small. Watch what one run costs.
• Use scripts for mechanical work. Scripts cost zero tokens.
• Use agents only where reasoning is needed.
• Widen the graph only after it has proven value.
• Track cost per successful completion, not just wall-clock time. Graphs cost more tokens per cycle than a single chat.

Common pitfalls

More agents does not mean better output

Five agents can repeat the same wrong idea with confidence. The system can spend more time coordinating than thinking. The goal is the smallest graph that improves quality.

Consistency without verification

A full graph with paired checkers and audit nodes can look consistent without being verified. The audit checks the numbers against the finance numbers. The finance numbers came from the same system. Everything checks out. Nothing is true.

A graph is only as honest as the things inside it that refuse to move. Tests that ran. Revenue that landed. Rules frozen because an optimizer would bend them.

Agent graphs are not always DAGs

A directed acyclic graph (DAG) has no cycles. You go forward only. Production agent workflows often need cycles: retrying failed tool calls, asking users for missing information, revising answers after validation, pausing for human input. Agent graphs are usually cyclic, not acyclic. Plan for loops inside your graph.

Automating before understanding

If the manual version does not produce better work, automating it produces mediocre work faster. Draw the graph first. Run it by hand. Then automate.

Forcing graphs onto agentic tasks

Some tasks are agentic by nature. Deep research, exploratory coding, and open-ended planning need an agent that can steer itself. Forcing these into a fixed graph with predetermined paths makes them worse. LangChain learned this lesson: their deep research tool started as a predefined graph, then moved to a more agentic core loop because the graph could not anticipate the right paths.

Quick reference: graph engineering checklist

• [ ] The task has multiple steps
• [ ] Some steps can run in parallel (no real dependency)
• [ ] The output needs checking before it matters
• [ ] A human gate exists before expensive decisions
• [ ] The reviewer is a separate job from the worker
• [ ] You ran it manually at least once before automating
• [ ] You know what one run costs in tokens
• [ ] The graph is the smallest one that improves quality
• [ ] You are not forcing a graph onto a task that is naturally exploratory
• [ ] You have cycles for retries, not just a forward-only DAG

FAQ

What is the difference between graph engineering and prompt engineering?

Prompt engineering improves the question you ask an AI model. Graph engineering improves how the work itself is structured around the AI. Prompt engineering happens inside one chat. Graph engineering splits the work into multiple agent calls connected by dependencies.

What is the difference between graph engineering and context engineering?

Context engineering improves the information you give an AI model before it starts. Graph engineering improves the workflow that processes that information after the model starts. Context engineering is about what the model knows. Graph engineering is about what the model does, in what order, and with what checks.

Is graph engineering the same as multi-agent systems?

They overlap but are not the same. Multi-agent systems use multiple AI agents that talk to each other. Graph engineering is the specific practice of designing those agents as a directed graph with explicit dependencies, parallel paths, and review gates. A multi-agent system without a graph structure is agents in a group chat. A graph engineering workflow is agents with a defined shape.

Is graph engineering just LangGraph?

LangGraph is the most popular framework for building agent graphs, but graph engineering is a design discipline, not a tool. LangGraph has modeled agent workflows as graphs for three years. The term "graph engineering" appeared in July 2026 as a name for the design problem LangGraph and similar frameworks already solve. You can practice graph engineering with no framework at all (Level 1, manual).

What is a fake edge in graph engineering?

A fake edge is a dependency between two jobs that does not actually exist. Job A and Job B are chained in sequence, but Job B does not need the output of Job A. They can run in parallel. The fake-edge test finds and removes these false dependencies.

What is the diamond pattern in graph engineering?

The diamond pattern has four stages: fan out, parallel research, review, and synthesize. The work splits into parallel jobs, a reviewer checks the results, and a merger combines them into one answer. It is the most common graph shape because it separates research from review.

How is a knowledge graph different from an agent graph?

A knowledge graph maps how information connects (entities and relationships). An agent graph maps how work moves (jobs and dependencies). Knowledge graphs help AI retrieve and connect facts. Agent graphs help AI execute multi-step workflows with checks.

What tools are used for graph engineering?

Three levels. Level 1: no tools. Draw the graph and run jobs manually in separate chat sessions. Level 2: files in a repo. Each step writes its own file (Claude Code, Codex). Level 3: frameworks. LangGraph for state checkpoints and human approvals. Microsoft Agent Framework for enterprise Azure deployments. AutoGen for research and prototyping. CrewAI for fast role-based crews. Google ADK for Gemini integration. n8n or Make.com for external tool integration.

How much does graph engineering cost?

Cost scales with the number of agents and how many run at once. Each agent call burns tokens. A small workflow on a single repo costs a few dollars. The largest public example cost about $165,000 in API usage to rewrite 535,496 lines of the Bun runtime from Zig to Rust in eleven days with 64 parallel agents. Start small, track cost per run, and widen only after the graph proves value.

When should you not use graph engineering?

Do not use a graph when the task is small, the steps depend on each other in strict order, you want to approve every step yourself, or you do not know what you are looking for yet. A graph adds coordination overhead. If the work does not have parallel paths and review needs, a single chat is better.

What is state in graph engineering?

State is the shared memory that moves through the workflow. Each job writes its findings into the state. The next job reads from it. State lets jobs hand off results without reading each other's full output. It also lets you resume the workflow from the last completed step if something fails.

What is a human gate in graph engineering?

A human gate is a required approval step before the workflow continues. It is placed where mistakes are expensive: before a customer email sends, before code deploys, before a refund processes. The gate can be light (a quick read) or strict (a full review) depending on the risk.

Can you do graph engineering without coding?

Yes. Level 1 is fully manual. Draw the graph on paper or a whiteboard. Run each job in a separate chat session. Copy the output from one chat into the next. You are the planner, the reviewer, and the synthesizer. This is graph engineering. No code needed.

What is the fake-edge test?

The fake-edge test is a method for finding unnecessary dependencies in a workflow. Walk each step. At each arrow, ask: does this step need the result of the step before it? If yes, keep the order. If no, remove the arrow and run both jobs at the same time.

How does graph engineering handle errors?

Each job writes its output to state before the next job runs. If a job fails, the workflow can resume from the last completed step. In frameworks like LangGraph, you can add retry logic and fallback branches. In a manual graph, you rerun the failed job and continue. The graph structure makes failure points visible because each step is a separate call with its own input and output.

What is the relationship between graph engineering and RAG?

RAG (retrieval-augmented generation) gives a model external knowledge before it answers. Graph engineering structures how the model works after it has that knowledge. A graph can include RAG as one job — the retrieval step — alongside research, review, and synthesis jobs. RAG improves what the model knows. Graph engineering improves what the model does with it.

Are agent graphs DAGs?

Not usually. A DAG (directed acyclic graph) has no cycles. Production agent workflows often need cycles: retrying failed calls, asking users for input, revising after validation. Agent graphs are typically cyclic. Plan for loops inside your graph.

Is graph engineering worth it for small projects?

Often, no. If the task fits in one chat, a graph adds overhead without value. Graph engineering pays off when the work has multiple steps, some can run in parallel, and the output needs checking. For a single summary, a single code fix, or a quick brainstorm, use a single chat. Start there. Add a graph only when the single chat is not good enough.

Is graph engineering just LangGraph?

No. LangGraph is one production framework for nodes, edges, and state. Graph engineering is the design work: which jobs exist, which depend on each other, and which can run at the same time. You can do that on a whiteboard. LangGraph, AutoGen, CrewAI, and Google ADK are ways to run a graph you already understand.

What is the parallel review pattern?

The parallel review pattern runs multiple review checks at the same time instead of one after another. Three reviewers (security, logic, style) all run at once. The results merge into one synthesis step. This cuts wall-clock time from three sequential cycles to one parallel cycle.

---

Sources

• Greg Isenberg. "Why Graph Engineering will 10x your Claude/Codex." YouTube, 3 August 2026. https://www.youtube.com/watch?v=JWhICz1QR8M. Instructional structure, three-level ladder, draw-before-you-automate. Paraphrased, not copied.
• Anatoli Kopadze (@AnatoliKopadze). "Graph Engineering explained." X, 24 July 2026. https://x.com/AnatoliKopadze/status/2080668775796314331. Fake-edge test and cost failure modes.
• Harrison Chase and Sydney Runkle. "3 Years of Graph Engineering with LangGraph." LangChain, 22 July 2026. https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph. Loops are graphs. Agent graphs are often cyclic. Node, edge, and state.
• Peter Steinberger (@steipete). X post that popularized the term, 18 July 2026. https://x.com/steipete/status/2078277297791189132.
• Jarred Sumner / Bun runtime rewrite reporting (line counts, agent count, API cost). Treat the dollar figure as reported, not as a template to copy.