Does Graph Engineering Cost More Than an Agent Loop?

Yes, a graph costs more, and the bill is predictable. Anthropic measured agents at about 4x the tokens of a chat and multi-agent systems at about 15x. Google Research’s 2026 scaling study shows the payoff depends on task shape: up to +81% on parallel work, and a 39% to 70% drop on sequential work.

So the question is never “graph or no graph” in the abstract. It is whether your task splits into pieces that can run without waiting on each other. If it does, the extra tokens buy real accuracy. If it doesn’t, you pay several times more for a worse answer.

What is graph engineering?

Graph engineering is the practice of designing an AI system as a graph of work. Each node is one bounded step: a model call, a tool, ordinary code, a validator or a human approval. Each edge is a routing rule, such as “if the tests pass, open the PR” or “if confidence is low, ask a person.” Shared state carries the goal, the evidence and the decisions between nodes.

The contrast is with a single agent loop, where the model picks the tool, reads the result, updates its plan and decides when to stop. In a graph, code owns the predictable routing and the model supplies judgment only inside the nodes that need it.

None of this vocabulary is new. Anthropic’s December 2024 engineering post Building effective agents drew the same line: workflows are “systems where LLMs and tools are orchestrated through predefined code paths,” while agents “dynamically direct their own processes and tool usage.” Its five workflow patterns (prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer) are, in today’s language, five graph shapes.

The frameworks already speak graph. The LangGraph documentation describes a “low-level orchestration framework and runtime for long-running, stateful agents” in which you “define workflows as graphs of shared state, nodes, and edges.” Google’s ADK 2.0 documentation says the release moves ADK “from a hierarchical agent executor to a graph-based execution engine,” with Python generally available since 19 May 2026.

Is graph engineering real, or a rebrand?

Both. The practice is real and in production. The label is a July 2026 social-media wave, and most of the claims that rode on it don’t hold up.

The trigger was a short X post from Peter Steinberger on 18 July 2026, quoted by Turing Post’s Is Graph Engineering Real? Why Everyone Is Talking About It (Ksenia Se, 20 July 2026): “Are we still talking loops or did we shift to graphs yet?” Within days the timeline had courses, roadmaps and threads saying Microsoft, Stanford and Anthropic had all adopted “graph engineering.” Turing Post’s fact-check table rejects each of those claims. GraphRAG is a form of RAG. Stanford’s DSPy optimizes language-model programs, not knowledge graphs. And Anthropic uses coded orchestration but has announced no discipline by that name.

Two more claims you will see quoted:

• “Graph engineering improves accuracy by 18% and cuts costs by 85%.” Per the same Turing Post piece, those figures come from one paper that applied GraphRAG to industrial engineering diagrams. It’s a narrow retrieval result, not a property of agent graphs.
• “Karpathy said to delete everything and keep the graph.” A line in that spirit circulates in screenshots and reposts. As of 4 November 2026 this post could not find it on Andrej Karpathy’s own X account or blog, so treat it as unverified. Turing Post’s coverage doesn’t attribute any graph claim to him either.

The academic version exists too. A 2026 arXiv preprint, Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence (Feng et al., 35 authors), proposes explicit, evolving graphs of tasks, agents and system states for multi-agent coordination. It’s a position-and-survey preprint, not peer-reviewed evidence that graphs win.

How is graph engineering different from loop and harness engineering?

The three terms describe layers, not rivals.

Layer	What you design	Who decides the next step
Harness	Everything around the model: tools, context, permissions, state, checks	Not applicable (it is the environment)
Loop	One agent’s act, observe, retry cycle	The model
Graph	Several loops, tools, validators and approvals wired by routing rules	Code, with the model deciding inside nodes

A loop is a graph with one node and an edge back to itself. A graph is several of those, connected. Both run inside a harness, which supplies the tools, state and evaluators every node needs. For the harness layer itself, see the named harness engineering techniques of 2026 and the six-layer agent harness checklist.

Is graph engineering the same as GraphRAG?

These share a word and nothing else. Graph engineering organizes execution: which step runs, in what order, with what permissions. GraphRAG organizes knowledge: it extracts entities and relationships from documents into a knowledge graph and uses that structure at retrieval time. Turing Post’s piece frames it as a control graph (LangGraph, ADK) versus a knowledge graph (Microsoft GraphRAG). You can use either without the other, and a GraphRAG retriever can be one node inside an agent graph.

How much more does a graph cost?

The two best primary numbers come from different labs measuring different things, so read them together rather than as one benchmark.

A graph always costs more tokens; it only sometimes scores better

Row	Value
Tokens spent, as a multiple of one chat: Chat	1x
Tokens spent, as a multiple of one chat: Single agent	4x
Tokens spent, as a multiple of one chat: Multi-agent system	15x
Score change vs a single agent: Research eval (Anthropic)	+90%
Score change vs a single agent: Finance-Agent, orchestrated (Google)	+81%
Score change vs a single agent: PlanCraft, every multi-agent variant (Google)	−39% to −70%

The token cost. In How we built our multi-agent research system (Anthropic Engineering, June 2025), Anthropic reports that agents typically use about 4x more tokens than chat interactions, and multi-agent systems about 15x. Its multi-agent setup, a Claude Opus 4 lead agent directing Claude Sonnet 4 subagents, beat a single Opus 4 agent by 90.2% on Anthropic’s internal research eval. The same post found token usage by itself explained 80% of the performance variance on BrowseComp. Put plainly, much of what a multi-agent graph buys is the permission to spend more tokens in parallel.

The payoff, by task shape. Google Research’s Towards a science of scaling agent systems (blog, 28 January 2026; full paper as arXiv preprint 2512.08296, Google Research, Google DeepMind and MIT) compares one single-agent system with four multi-agent architectures (independent, centralized, decentralized, hybrid) across three model families. The January blog reported 180 configurations on four benchmarks; the revised preprint extends that to 260 configurations on six, adding SWE-bench Verified and Terminal-Bench. Centralized coordination improved Finance-Agent, a parallelizable task, by 80.9% (80.8% in the revised preprint). On PlanCraft, a sequential planning task, every multi-agent variant degraded performance by 39% to 70%.

Structure also changes how errors spread. In the same study, independent agents working in parallel without an orchestrator amplified errors by up to 17.2x. A central orchestrator, which acts as a validation checkpoint, held that to 4.4x. That’s the strongest case for one specific graph node: the verifier.

What that means per 1,000 runs, assuming a task a chat answers in 20,000 tokens and a blended rate of $10 per million tokens (an assumption for the arithmetic, not a quoted price):

Architecture	Tokens per run	Cost per 1,000 runs	Pays off when
Chat (one call)	20,000	$200	The answer needs no tools or iteration
Single agent loop (~4x)	80,000	$800	The task needs tools and retries, one step at a time
Multi-agent graph (~15x)	300,000	$3,000	The task splits into independent branches worth checking

The multipliers are Anthropic’s averages for its own systems, so your ratio will differ. The shape won’t: each layer up costs a multiple, not a percentage. For what those multiples do to a monthly bill, see what an AI agent costs in production and how many tokens a coding agent actually burns.

When is a graph worth it?

Run four questions before adding a node. If the answer to all four is no, keep the single loop.

1. Can the subtasks run without waiting on each other? Parallel search across sources, or reviewing ten files independently, is where Google measured the +81%. Step-by-step planning is where it measured the 39% to 70% drop. Coding leans sequential too: in the revised Google preprint, every multi-agent architecture did slightly worse than a single agent on SWE-bench Verified (−15% to −2%), and Anthropic’s post notes that most coding tasks involve fewer truly parallelizable pieces than research does.
2. Does an output need an independent check? A separate verifier node with explicit criteria is the cheapest graph upgrade there is, and it’s the node that cut error amplification from 17.2x to 4.4x.
3. Does a person have to approve something? Deploys, refunds, deletions and outbound emails belong behind a human approval node with an edge that cannot be skipped. A prompt that says “ask first” is not a gate.
4. Must state survive a crash or a day-long pause? If a run waits for approval overnight or calls an expensive model you never want to pay for twice, you need durable execution under the graph. That’s a separate layer, covered in DBOS and durable execution for agent harnesses.

There’s a fifth signal that argues against a graph: heavy shared context. Anthropic lists domains where every agent must share the same context, or where agents have many dependencies on each other, as poor fits for multi-agent systems today. Splitting those across nodes means re-sending the same context to every node, and that is where the 15x comes from.

How to start without overbuilding

Start with one loop and a budget. Add a deterministic check (tests, schema validation) before you add a second model.

Then apply the collapse test to any graph you draw: if you could merge its nodes back into one agent’s loop and lose nothing you can measure, merge them. Every node you keep adds a model call, a place for state to drift, and something to evaluate.

When you do need a graph, pick the smallest runtime that gives you the edges you need:

• A plain state machine in your own code covers routing and an approval gate in a few dozen lines, and you can read every transition.
• LangGraph adds checkpointing, human-in-the-loop interrupts and streaming over a nodes-and-edges API.
• Google ADK 2.0 runs agents, tools and functions as nodes in a graph-based workflow runtime, with retries and human-in-the-loop pauses built in.

If you are deciding whether to build this yourself at all, the build-or-adopt guide for agent harnesses covers when an existing harness like Claude Code already gives you the loop and the subagents for free.

Frequently asked questions

Is graph engineering the same as multi-agent?

No. A graph can have one model and several plain-code nodes, such as a router, a test runner and a human approval step. Multi-agent is one kind of graph, where several nodes are model loops. It is also the expensive kind: Anthropic measured multi-agent systems at about 15x the tokens of a chat.

Did Andrej Karpathy coin graph engineering?

There is no primary source for that. The July 2026 wave traces to an 18 July X post by Peter Steinberger asking whether the field had shifted from loops to graphs. A line attributed to Karpathy about keeping the graph circulates in screenshots, but it could not be found on his own accounts as of 4 November 2026.

Does graph engineering replace RAG?

No. Graph engineering organizes how an agent system runs. RAG and GraphRAG organize what evidence the model can retrieve. Microsoft describes GraphRAG as a form of RAG, and a retriever of either kind can sit inside one node of an agent graph.

When does a multi-agent graph make results worse?

On sequential tasks where each step depends on the last. Google Research found every multi-agent variant it tested degraded PlanCraft, a sequential planning benchmark, by 39% to 70% against a single agent, while still spending more tokens.

Sources

• Anthropic (2025). How we built our multi-agent research system. Anthropic Engineering. https://www.anthropic.com/engineering/multi-agent-research-system
• Anthropic (2024). Building effective agents. Anthropic Engineering. https://www.anthropic.com/engineering/building-effective-agents
• Kim, Y. and Liu, X. (2026). Towards a science of scaling agent systems: When and why agent systems work. Google Research blog. https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/
• Kim, Y. et al. (2025, revised 2026). Towards a Science of Scaling Agent Systems. arXiv (preprint, v3). https://arxiv.org/abs/2512.08296
• Feng, Y. et al. (2026). Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence. arXiv (preprint). https://arxiv.org/abs/2608.21156
• Se, K. (2026). Is Graph Engineering Real? Why Everyone Is Talking About It. Turing Post (secondary commentary). https://www.turingpost.com/p/is-graph-engineering-real-why-everyone-is-talking-about-it
• LangChain (2026). LangGraph overview. LangGraph documentation. https://docs.langchain.com/oss/python/langgraph/overview
• Google (2026). Welcome to ADK 2.0. Agent Development Kit documentation. https://adk.dev/2.0/