Graph Engineering: The Signal, the Spend, and What We Don't Know

On June 13, 2025, Anthropic published a scene that seems to settle the debate about agent graphs on its own. Faced with a broad search—identifying the board members of the technology companies in the S&P 500—a lead agent split research paths among subagents and then assembled their findings. In an internal research evaluation, that multi-agent system outperformed a single Claude Opus 4 agent by 90.2%.

The percentage is real. It is also narrow: it belongs to an internal evaluation, a particular architecture, and research tasks with independent paths. It does not show that every process improves when someone draws a router, several boxes, and a review gate. The useful question is not whether the graph looks impressive, but what each edge bought, against which alternative, and with what budget.

What a graph is, without the smoke

In much of this discourse, “graph” means a workflow: one output feeds another stage, a condition chooses a path, and some branches can run at the same time. The code may be perfectly valid. Confusion starts when that topology is presented as proof of collective intelligence.

Anthropic's documentation on agentic systems separates two categories. A workflow orchestrates models and tools through predefined code paths; an agent dynamically directs its process and tool use. A chain, router, or parallel split does not become an autonomous team because its diagram has more nodes. These are useful mechanisms, but they answer a different question: how to control the path.

This distinction does not diminish the engineering. It improves it. Each decision can be measured by what it does: a fixed path adds predictability; dynamic delegation adds flexibility; a second call may add a different check. If two boxes apply the same criterion, share the same context, and consume the same faulty source, plurality does not create independence.

The signal: context really does degrade

The genre's strongest premise is that a single context does not grow for free. In a guide published on September 29, 2025, Anthropic describes context rot: as the number of tokens in the window grows, the ability to retrieve information from it accurately declines. The slope varies across models, but the company says the phenomenon appears in all of them.

Its explanation is architectural. For n tokens, transformer attention creates n² pairwise relationships while the model has a finite attention budget. This does not mean a late token makes the system useless; the guide itself describes a gradient, not a cliff. It means “it fits in the window” is not the same as “it will receive equal attention.”

Subagents with clean contexts are a documented mitigation. Each can explore extensively and return a short summary to the coordinator without importing its entire trace. But the same source lists compaction and structured notes first. Multi-agent design is a tool for tasks where parallel exploration pays; it is not the automatic cure for every long conversation.

The 90.2% does not travel alone

Anthropic's internal evaluation does compare a multi-agent system—Opus 4 as coordinator and Sonnet 4 subagents—with a single Opus 4 agent. The reported result is a 90.2% advantage in research. The page does not publish the number of cases, the relative token budget of the contenders, or the cost per correct answer there. The figure therefore supports “it performed better in this evaluation,” not “graphs improve performance by 90.2%.”

The same page contains two other measurements, but their denominators differ. In general usage data, an agent typically consumes about four times the tokens of a chat interaction and a multi-agent system about fifteen times those of a chat. That 15× does not compare the 90.2% winner with the single-agent baseline in that test. In a separate analysis, this time on BrowseComp, token spending alone explains 80% of performance variance; tool calls and model choice complete the three factors that explain 95%.

Combining the three figures would produce a clean, false story. The honest conclusion is more uncomfortable: spending more compute often buys more attempts and coverage, but the public documentation does not separate how much of that internal improvement came from budget and how much from architecture.

A graph is only as impressive as the baseline and budget it is measured against. Without equal resources or a cost-performance curve, the diagram describes a way to spend; it does not prove a superior way to think.

Parallelizing is not the same as dividing the work

Topology helps when branches can advance without waiting for one another. Searching documents in several directions is a clear case: each subagent explores in its own window, and the coordinator compresses the results. The benefit shrinks when everyone needs the same state or every step depends on the previous one.

Anthropic warns in its report on the multi-agent system that tasks requiring shared context or many dependencies are not a good fit today. It adds that most coding tasks contain less truly parallelizable work than research, and that models still struggle to coordinate and delegate in real time.

Consider a change that affects a database, its API, and a migration. Three agents can write in parallel, but the decisions are not independent: they share a schema, deployment order, and compatibility criterion. If each branch starts from a different version of that state, fan-out does not remove the context problem; it replicates it. The question before drawing the graph is what fraction of the work can be separated without sharing assumptions or waiting for results.

More nodes, more places to look for failure

A recurring promise is that a graph makes observation and debugging easier. Dividing a trace may help a person inspect it, but locating the cause remains far from solved. The Who&When paper, revised on June 2, 2025, collected failure logs from 127 multi-agent systems with annotations for the responsible agent and decisive step. The best method identified the agent correctly in 53.5% of cases and the step in 14.2%; some methods performed below chance.

Those results do not prove that every graph is harder to debug than every loop. They do prevent failure attribution from being sold as a solved property of the design. Logging each message can reconstruct a path; it does not guarantee that anyone knows which decision caused the outcome or where to intervene.

Separating builder and reviewer has a basis too, but it does not create an oracle. A study of 20 models, revised on June 2, 2026, defines self-preference bias as a deviation in which models systematically favor or disfavor their own outputs when evaluating them. A separate reviewer may reduce that contamination; if it shares the rubric, data, or blind spot, it still needs calibration against external outcomes and accountable human review.

The first alternative is a simpler system

Anthropic's December 2024 guide begins with advice that diagrams often relegate to the margin: find the simplest solution and increase complexity only when necessary. That may mean not building an agentic system. For defined tasks, one call with retrieval, examples, and a deterministic check may be enough.

This changes the order of the decision. Measure a simple baseline first. Then add one stage and test whether it buys enough accuracy, coverage, or speed to pay for latency, tokens, coordination, and maintenance. Sophistication stops being a professional identity and becomes a hypothesis that can fail.

What we do not know

The open sources provide no general success rate for graphs against loops. Nor do they support the claim that “nine out of ten” teams fail to divide the work: it is a figure without a declared measurement, not a demonstrated lie. The alleged four eras—prompt, context, loop, and graph—are a useful narrative device, not a validated technical periodization.

We also do not know how many tokens the 90.2% result cost relative to the single agent or the cost per result in that evaluation. The published multiple compares agents and multi-agent systems with chat, not the graph with the alternative it is supposed to replace. And the 80% comes from BrowseComp, a different evaluation. Three figures with three bases do not form an equation.

Other production measurements are missing too: end-to-end latency, the rate of tasks requiring human intervention, route-maintenance cost, conflict frequency between branches, and the practical ability to attribute a failure. Without them, “it worked” may mean anything from finding more correct answers to spending more without net value.

The craft being born

As drawing agents gets cheaper, the valuable work shifts to proving why they should be there. The transferable skill is not memorizing a collection of patterns but auditing the comparison: What is the baseline? Do both systems use the same model and budget? What share of the task is independent? What does each correct result cost? How do you identify the responsible agent and step when it fails? Which simpler alternative was tested first?

An architecture deserves to grow when it answers those questions with measurements, not arrows. Graph engineering is not the craft of populating a diagram. It is the craft of justifying every context boundary, every additional expense, and every point of responsibility. If an edge buys no measurable improvement, it is not architecture; it is FOMO drawn on a page.