AI / Agents
Graph Engineering Is Not a New Discipline. That Is the Point.
The techniques are forty years old. The label is a few months old. The thing worth arguing about is neither.
A term has been circulating: graph engineering. The pitch is that we have moved through prompt engineering, then context engineering, then tool engineering, then loop engineering, and have now arrived at the phase where the real work is wiring multiple model calls, tools, functions, and humans into an explicit execution graph.
I went looking for where the term came from. What I found was more instructive than the term itself.
The citation that is not there
The essay usually credited with popularizing "graph engineering" is one I could not verify. The site it supposedly lives on is real and has been publishing for over a year. But the essay returns zero exact-phrase hits anywhere on the web, no third party quotes it, and the Internet Archive holds no copy. Across roughly three thousand archived URLs on that domain, not one contains the word "graph." The most recent archive snapshot lists nothing newer than early May. And the URL it is cited under does not match the slug format the site itself has used since last August.
I cannot prove a negative. It may exist and be very new. But the more interesting finding did not depend on that essay at all.
"Graph engineering" does not appear in the literature. I ran full-text searches across the two survey-class papers that cover exactly this ground. Zero occurrences in either. The field has its own vocabulary, and it is not this: "flow engineering," "agentic computation graph," "workflow optimization," "orchestration graphs," "communication graphs." One survey has a section titled "Graph based orchestration and flow engineering," which is close enough to fool a skimmer, and it says flow, not graph.
So the honest framing is this. Nobody in the research literature is using the term. Its popular origin is a document I cannot read. It is a practitioner coinage, and anyone using it, including me in this article, is adopting it rather than reporting on an established discipline.
That sounds like a debunking. It is not. It is the setup.
The most common objection is correct
The standard reaction to "graph engineering" is that it is a rebrand of things software engineers have done for decades. Finite-state machines. Directed acyclic graphs. Workflow orchestration. Actor and message-passing systems. Durable execution. Event sourcing. Distributed scheduling. Dataflow programming. Business process management.
That objection is right, and conceding it immediately makes the rest of the argument stronger. Nobody invented nodes and edges in 2026. Graph-shaped agent systems are not new either: AlphaCodium called its multi-stage approach "flow engineering" in January 2024, GPTSwarm was treating agent systems as optimizable graphs at ICML that same year, and LangGraph, AutoGen, and every workflow engine on the market already exposed graph-oriented orchestration.
The novelty is not the graph. The novelty is what you are putting inside it: components that are probabilistic, expensive, and capable of confidently producing plausible nonsense. Every classical technique in that list assumed deterministic steps. Retry logic assumed a failed step failed loudly. Scheduling assumed bounded, predictable work. None of that survives contact with a language model, and that is what makes the old toolbox interesting again rather than merely familiar.
There is also a genuine ambiguity worth clearing up, because the word "graph" is doing at least four different jobs.
Four graphs, routinely confused
The control or workflow graph. Nodes do work, edges govern execution. This is what people usually mean, and what LangGraph, Microsoft Agent Framework, and Google ADK implement.
flowchart TD
REQ([User request]) --> C{Classify}
C -->|simple| A[Answer directly]
C -->|complex| P[Plan]
P --> W[Workers]
W --> V{Verify}
V -->|pass| OUT([Done])
V -->|fail| RV[Revise] --> W
A --> OUT
The multi-agent communication graph. Nodes are agents, edges say who may talk to whom. Supervisor and workers, peer debate, hierarchies. A live research area asks whether the topology itself can be optimized.
The knowledge or memory graph. Nodes are entities and claims, edges are relationships. decision → justified_by → policy. This powers GraphRAG, provenance, and long-term memory.
The reasoning or thought graph. Nodes are partial solutions, edges are refinement and critique. Graph of Thoughts is the canonical example.
These solve different problems and fail in different ways. The practical consequence: you do not need a graph database to do graph engineering. Conflating the workflow graph with the knowledge graph is the fastest way to buy a large infrastructure problem you did not need.
One more distinction that matters more than it sounds. A graph does not replace an agent loop. A loop becomes a node inside the graph. "Graphs replace loops" is the single most common error in writing on this topic. Graphs contain and constrain loops.
flowchart TD
IN([Request]) --> VAL["Validate and retrieve<br/>plain code"]
VAL --> T
subgraph AG [Agent node: the loop lives here]
T[Think] --> TOOL[Call tool]
TOOL --> OBS[Observe]
OBS --> T
end
OBS --> HUM{Human approval}
HUM -->|approved| FX["Side effect<br/>plain code"]
HUM -->|rejected| T
FX --> OUT([Done])
The loop still exists. It is now bounded by an approval gate on one side and a deterministic side effect on the other, and its budget is enforced from outside.
What the evidence actually supports
Here is where most writing on this gets lazy, in both directions. So let me give the strongest thing I found on each side.
The best argument for structure comes from a Berkeley-led paper that built a taxonomy of multi-agent failures by hand-annotating traces, then tried to fix the systems it studied. On one benchmark task, the baseline scored 25.0. A better prompt got it to 34.4. Changing the topology got it to 40.6. The paper states plainly that topology changes were more effective than prompt changes on both systems it repaired.
That is the number I would put in front of anyone who thinks orchestration is decoration. It is a structural change beating a prompt change, in a peer-reviewed venue, on a system that was already broken in measurable ways.
Two honesty requirements come attached. First, the same paper notes that even after repair, absolute completion rates remain "insufficiently low for real-world deployment." Second, its broader claim, that better base models will not fix these failures, is explicitly labeled a conjecture by its own authors. It is an argued position with a taxonomy behind it, not a measurement, and anyone citing it as proof is overreading.
The supporting cast is real but weaker than it looks in aggregate. AlphaCodium moved GPT-4 from 19% to 44% pass@5 on CodeContests, though that is the validation split and the test split moved 12% to 29%, a distinction almost everyone drops. Anthropic reported a multi-agent research system beating a single agent by 90.2%, on an internal, unpublished eval, restricted to breadth-first research queries. There is a whole literature on optimizing agent topologies automatically. But five of the seven papers in that line coin their own problem name, pick their own baselines, and replicate nobody. Reading them as converging evidence is an inference, not a finding.
What the evidence actually says against
Now the other side, which is stronger than proponents admit.
A controlled study this spring put an entire procedure into a system prompt and let the model self-orchestrate, then compared it against a graph orchestrator running the same model. Twelve hundred conversations across travel booking, technical support, and insurance claims. The in-context version won on every domain, with failure rates two to eighteen times lower, and the differences held up statistically.
That is a real result and it deserves to be uncomfortable. But it needs dismantling in the same breath, because the authors built the orchestrated baseline themselves, they work at a company selling an alternative, the domains were synthetic, and every procedure fit inside the context window. That last point may be the entire finding. If the whole task fits in one context, of course splitting it across nodes and re-injecting prompts at each hop costs you more than it buys.
Their conclusion is the sharpest version of the bear case: external orchestration "may have been necessary for earlier models," and frontier capability has absorbed it. Note that they never ran the weaker-model condition that would test this.
Then there is cost. Anthropic's own numbers: agents use roughly four times the tokens of a chat interaction, multi-agent systems roughly fifteen times. And on one evaluation, token usage alone explained 80% of the performance variance. Read that twice. Some meaningful fraction of any multi-agent win may just be spending more money, not thinking better.
The gap nobody has measured
Put the two bodies of evidence side by side and something obvious falls out.
The case for structure is strongest when the system is already multi-agent, already failing, and you are repairing it. The case against is strongest when the task fits in one context and one competent model could just do it.
Those are different regimes, and they do not contradict each other. The bear case says do not decompose a task one model handles coherently. The bull case says once decomposition is forced on you, structure beats prompting. Both are true.
What nobody has measured is the regime practitioners actually point at when they defend graphs: runs that outlive a process, work that must survive a crash and resume, genuine parallel fan-out, human approval gates in the middle of a transaction, different models on different nodes. Every study I found lives in the short, single-model, fits-in-context world. The interesting territory is empirically empty.
flowchart TD
M1["Measured: the bear case wins.<br/>Fits in one context, one model,<br/>short procedure."]
M2["Measured: the bull case wins.<br/>Already multi-agent, already failing,<br/>repaired by changing topology."]
U["Unmeasured.<br/>Outlives the process, survives a crash,<br/>real parallel fan-out, human gates mid-run."]
M1 -.-> U
M2 -.-> U
The dotted arrows are the inference everyone is making and nobody has earned.
So when someone tells you graphs are obsolete because a frontier model beat an orchestrator on a customer service script, the correct response is that they measured the one regime where nobody serious was arguing for a graph.
The durability claim is mostly marketing
If you do reach for a graph runtime, understand what you are actually buying, because the gap between the blog posts and the documentation is wide.
LangGraph's own docs say that on resume "the runtime restarts the entire node from the beginning, it does not resume from the exact line where interrupt was called," that "a task that started but did not finish may run again," and, in bold, that "replay re-executes nodes, it doesn't just read from cache." Google ADK's documentation says its resume feature ensures tools "are run at least once, and may run more than once." Microsoft draws the line itself, distinguishing checkpoint storage, which "helps resume a workflow run," from its Durable Extension, which actually runs the workflow on durable infrastructure.
The precise fact worth internalizing: completed steps are not re-run, but the node that was executing when you paused restarts from its first line.
flowchart TD
A["Nodes 1 and 2 complete"] --> B["Node 3: charge the card,<br/>then wait for approval"]
B --> C{{"Crash or pause here"}}
C --> D([Resume])
D --> E["Nodes 1 and 2 restored<br/>from checkpoint, not re-run"]
E --> F["Node 3 re-runs<br/>from line one"]
F --> G["Card charged twice"]
Which is why the most important practice in this entire field is unglamorous. Any node with a side effect must be idempotent, or must be structured so the side effect happens after the pause point, or must be split into its own node. Otherwise your checkpoint-and-resume story is a duplicate-charge story.
It is worth noting that the sharpest critics of framework checkpointing all sell durable execution runtimes. They are commercially interested, and they are also substantially correct. Both halves of that sentence are true.
What survives
Strip out the label and the vendor claims, and a short list of practices remains standing.
Design the state before the prompts. If you cannot say what the system knows at each stage, your transcript has become an accidental database. Whether tests passed, which plan is active, how many retries remain, who approved the risky action, how much the run has cost: none of that belongs only in a conversation history.
Keep nodes bounded. One responsibility, typed inputs and outputs, a timeout, a retry policy, a defined failure mode. A node that plans, retrieves, writes, validates, and deploys is a monolithic agent loop wearing a costume.
Make deterministic transitions deterministic. Schema validation, permission checks, thresholds, business rules, budget enforcement, and test execution are code. Reserve the model for edges that genuinely need semantic judgment.
Treat edges as contracts. Preconditions, schema, required authority, failure behavior, reversibility, retry and cost ceilings.
Put budgets in state. Tokens, money, wall-clock, retries, parallel workers, and consecutive no-progress transitions. Hard ceilings, enforced in code.
Evaluate paths, not just outputs. Whether the router chose correctly, whether the trajectory contained loops without progress, whether the final environment actually reached the right state. A good draft that was never sent is not a success.
On that last point, one caution. Observability tooling here is less mature than it appears. OpenTelemetry's GenAI semantic conventions carry ninety-nine "Development" badges and zero "Stable" ones, and by default capture no prompt content or tool arguments at all. It is a converging convention, not a stable spec.
The useful version of the idea
I do not think "graph engineering" will survive as a term, and it does not deserve to be defended as a discipline. But the thing it points at is the correct next problem.
Agents made a single model call useful. Loops made a single agent useful. The open question now is how multiple loops, deterministic functions, external systems, and human authority compose into something you can debug on a Friday evening. That question is old software engineering pointed at new components, and the answer looks conservative:
Use deterministic software for everything you already know how to determine. Insert agentic nodes only where semantic judgment or open-ended exploration creates measurable value. Then make those nodes participate in an explicit, durable, testable system.
The thing to resist is the assumption that more structure is more engineering. The evidence does not support that, and one careful study suggests the opposite in the regime it tested. Nodes are not free. Every hop is a place to lose context, spend tokens, and add a failure mode.
Put uncertainty in nodes, policy in edges, truth in state, resilience in the runtime, and accountability in traces. Then add as few of them as the problem will tolerate.
References
- Cemri, Mert, et al. Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657. NeurIPS 2025 Datasets and Benchmarks Track. See Section 5.3 on topology versus prompt interventions.
- Ridnik, Tal, Dedy Kredo, and Itamar Friedman. Code Generation with AlphaCodium: From Prompt Engineering to Flow Engineering. arXiv:2401.08500, January 2024. The 19% to 44% figure is pass@5 on the CodeContests validation split.
- Anthropic. How we built our multi-agent research system. Anthropic Engineering, June 2025.
- Yan, Walden. Don't Build Multi-Agents and Multi-Agents: What's Actually Working. Cognition, June 2025 and April 2026.
- Yue, Ling, et al. From Static Templates to Dynamic Runtime Graphs: A Survey of Workflow Optimization for LLM Agents. arXiv:2603.22386, March 2026.
- Dennis, et al. In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks. arXiv:2604.27891, April 2026. Preprint; see the limitations discussion on baseline construction.
- Zhuge, Mingchen, et al. GPTSwarm: Language Agents as Optimizable Graphs. ICML 2024.
- Besta, Maciej, et al. Graph of Thoughts: Solving Elaborate Problems with Large Language Models. AAAI 2024.
- LangChain. LangGraph persistence, durability modes, and time travel. Documentation retrieved July 2026.
- Microsoft. Agent Framework Workflows and Durable Extension. Documentation retrieved July 2026.
- Anthropic. Building Effective Agents. Anthropic Engineering.