Agent graphs: why serious orchestration is a graph problem

Every time a model ships a bigger context window, someone tells me agent orchestration just got solved. Dump the whole repo in, ask for the result, done. I have watched that movie across three generations of technology, and it always ends the same way.

I spent two decades building enterprise search before Arvor — Solr, Lucene, billion-document indexes. The lesson is boring and universal: raw capacity never fixed bad modeling. A bigger index never fixed a bad schema. A bigger context window does not fix badly decomposed work.

In 2026, serious agent orchestration is a graph problem. Teams that see it stop fighting the model and start fighting the right thing.

A single agent is a graph with one node

When you hand everything to one agent with a huge context, you did not remove the graph. You collapsed it into a single node and threw away everything the structure was giving you.

A single agent does not remove the graph — it collapses it into one node. The graph gives back isolation, parallelism and an explicit verification point.

You lost isolation: one bad step contaminates every step after it, because the flawed reasoning stays in the window. You lost parallelism: ten independent checks become ten sequential ones. You lost granular retry: when it fails, you redo the whole thing instead of the piece that broke. And you lost observability — “the agent went wrong somewhere in these 400k tokens” is not a diagnosis, it is a complaint.

There is a subtler cost too: inside one big window everything competes for attention, and you do not win that fight with prompt wording — you win it by deciding what gets into each node in the first place.

Nodes, edges, and the boring part nobody wants to do

A node is a unit of work with a declared input and a verifiable output. If you cannot write the node’s acceptance criterion in one sentence, it is not a node. It is a wish.

An edge is a real dependency: B runs after A because B consumes A’s output. And here is the boring part almost nobody does — most edges teams draw are not dependencies at all. They are just the order in which someone happened to think of the tasks. Accidental sequence promoted to architecture.

Telling real dependency apart from writing habit is what turns a to-do list into a graph. That is where the payoff lives: everything that depends on nothing can run at the same time.

Fan-out, fan-in, pipelines, and barriers

Four patterns cover almost everything:

Fan-out sends the same input to several nodes with different objectives, in parallel. Each one gets a small context and a narrow mission.

Fan-in aggregates. It is the pattern teams get wrong most often, because they treat aggregation as summarization. A fan-in node needs a conflict rule: what happens when two verifiers disagree? Without an explicit rule, the aggregator picks the best-written answer rather than the correct one.

Pipelines chain steps in series. Latency adds up and, worse, errors propagate. Do the honest arithmetic: twelve steps at 95% each give you a bit over 54% odds of coming out clean. Teams build twelve-step pipelines because they are easier to write, then blame the model for the coin flip.

Barriers are the opposite: nothing moves forward until everything arrives. They cost latency and buy consistency. A barrier is what stops a migration from merging before build, tests, type check, and lint have all come back green.

In a pipeline each check moves on the moment it finishes; at a barrier, nothing advances until all of them arrive.

Adversarial verification is a node, not an adjective

“Double-check your work” at the end of a prompt is not verification. It is the same model, with the same context and the same bias, asked whether it likes itself. The answer is always yes.

Real verification is a separate node in the graph: its own context, an inverted objective (find the defect, do not confirm the win), and access to the artifact only — never to the generator’s reasoning. A verifier that reads the generator’s chain of thought gets captured by it. Only what survives the attempt to knock it down moves forward.

And your best verifier is usually not an LLM. Compilers, tests, type checkers, linters, schema validation: cheap, deterministic, and utterly without opinions. Spend model tokens on what machines cannot check — intent, business rules, implicit contracts — and leave the rest to tools that never hallucinate.

Three graphs that earn the design effort

Code review with parallel verifiers. Fan the diff out to specialized nodes: security, regression risk, API contract, test coverage. Each one gets a small context and a single criterion. Fan in to a node that dedupes and ranks by severity, with a defined precedence rule. One agent reading the entire diff finds the obvious issues and runs out of steam before the rest.

Migration with isolated worktrees. One git worktree per module. Isolation stops being a promise and becomes a property of the system: two nodes cannot write to the same file because they cannot even see the same working directory. Put a barrier before the merge, and rollback becomes throwing a worktree away. This is the pattern we run with Relentless.

Multi-modal research. Fan out by source — internal docs, code, web, spreadsheets — with the right tool per node, then fan in with an explicit precedence rule for when sources disagree. Without it, the aggregator trusts the most eloquent source. It is what we learned building governance into BRAIN MAKER: provenance is not decoration, it is the tiebreaker.

When a deterministic graph wins — and when it loses

The graph wins when work is decomposable, acceptance is machine-verifiable, you need to audit the result, you need the same output again tomorrow, or cost matters — because a small node runs fine on a smaller model.

The graph loses when the problem is exploratory and you do not yet know the steps. Drawing a graph for a problem you have not understood is guessing with a diagram. That is where a single agent with good tools is the right instrument.

My working rule: a single agent to discover the graph, the graph to run in production. Confusing the two is expensive in both directions — a premature graph freezes exploration, a lone agent in production neither scales nor audits.

Tools, without the fake review

The ecosystem already converged on this vocabulary. LangGraph, from LangChain, is the most explicit example: nodes, static and conditional edges, shared state, fan-out and fan-in as primitives. If you want a library that already thinks in graphs, start there.

I will not pretend we use one library for everything — a lot of what we run is a hand-rolled graph with git as the state layer. The point is not which library you pick. It is that the graph exists either way: if you do not draw it, it lives implicitly inside a two-thousand-word prompt, unowned and unverified.

The graph is the map. The engine that walks it is a different subject, and I wrote about it in agent loops. If you want to stop betting on prompts and start designing architecture, talk to us or take a look at our agentic consulting.

Trees do not grow in a straight line. They grow in branches — and every branch knows where it came from.