Graph engineering: draw the shape of the work

Most multi-step agents are a straight line. Step one, step two, step three, each waiting politely for the last to finish before it starts. It runs. It also runs slowly, and it forgets: one head, one context window, one thing at a time, until the window fills and the agent loses the thread of what it was doing.

The tell is that half those steps never needed to wait. They do not route, they do not branch, they do not run at the same time. They queue, because a line is the shape that matches how we type, not the shape of the work.

The work has a shape of its own. What runs before what, what can run together, what has to wait for everything else. That shape is a graph. The move this piece is about is drawing it on purpose, then running it wide.

Be honest about what is new here, because a senior reader will check. Shaping work as a graph of jobs joined by their data dependencies is not an invention. It is dataflow programming from 1974, MapReduce from 2004, and Pregel's round-based graph convergence from 2010. Every DAG workflow engine since, Airflow, Dagster, Prefect, Temporal, is a version of it.

The agent-specific version was named before the current tooling too. Anthropic's "Building Effective Agents" laid out routing, parallelization, orchestrator-workers, and evaluator-optimizer a full year before a model could write the orchestration for you. "Graph engineering" is a newer, louder label, and a contested one. Treat it as a lens, not a discovery.

What is genuinely new is narrow and worth stating precisely. A model now writes the orchestration itself, as a plain, rerunnable script, and the coordination logic in that script is ordinary code. That one shift is what makes the graph cheap to draw and cheaper to change. The rest of this piece is the shapes worth drawing, and the honest cost of running them.

A graph has two things, and getting them straight removes most of the confusion. A node is one unit of work: one agent, one bounded job, one input in and one output out. An edge is a dependency: this node's output feeds that node's input. That is all an edge is.

The mistake is treating "and then" as an edge. "Summarize the file, and then tell me the weather" has no edge between the two, because the weather does not read the summary. Those are two independent nodes a linear script chains for no reason. The edge exists only when data actually moves across it.

So for every "and then" in an agent, ask one question: does the next step read the last step's output? If not, there is no edge, and the wait is wasted. That question is the whole method, and the rest is learning to exploit the independence it finds.

A node you cannot reason about is a node you cannot parallelize. The fix is a contract: bounded input, bounded output, one job. The input is passed in explicitly, never assumed from a shared window. The output is a defined shape, validated, so the next node consumes it without guessing.

In a workflow that contract is a schema. Hand a node a JSON schema and the subagent is forced to return validated structured data. The validation happens at the tool-call layer, so a mismatch is retried, not handed back as free text you have to parse and hope over. That is the line between a node you can wire into a graph and one that only works when a human reads its output.

This is the move that pays for everything. When N nodes are independent, N sources to check, N files to review, N routes to audit, you do not chain them. You fan them out and run them at once, then gather the results. One node splits, many nodes work in parallel, one node merges. That split-work-merge shape is the diamond, and it is the workhorse of every serious agent graph.

Two details make it hold. The gather is a barrier: it waits for every branch before the next stage sees the set, which is what a real merge needs. And a branch that fails resolves to nothing rather than sinking the batch, so one flaky node cannot take down the run. You drop the empty results and keep going.

The merge in between is usually not a node at all. Flatten, dedupe, filter: that is plain code operating on the shapes the nodes returned. A large share of what people spend model tokens on is really an edge, and edges are free. Spend agents on judgment, not on plumbing.

Not every graph is fixed. Sometimes the edge to take depends on what a node found. A router inspects a result and decides which downstream path fires: classify the input, then branch to the right handler; check the size of a change, then either do a quick pass or a full audit.

The classification can be a model's judgment, but the routing is code. So it runs the same way every time for the same classification. You get the model's judgment at the node and the script's determinism at the edge. There is no emergent "it decided to skip the audit", because a skip would have to be written into the graph, and it is not.

The real gain from a graph is not more agents. It is the structure you can wrap around them to earn confidence. A verifier sits on the edge before a result is allowed downstream, and its one job is to try to kill the finding. If it survives, it passes. If not, it never reaches the answer.

Three shapes are worth having in hand. Adversarial verify: for each finding, spawn independent skeptics prompted to refute it, and keep it only if a majority survive. Perspective-diverse verify: give each verifier a different lens, correctness, security, does-it-reproduce, because diversity catches failure modes that identical checks never will. Judge panel: generate several attempts from different angles, score them with parallel judges, and build the answer from the winner while grafting the best of the rest.

This is the same separation of powers I reach for in a grounded RAG system, where an agent proposes and a verifier and a human decide. The research workflow bundled in Claude Code is that shape run wide: it fans out searches, cross-checks the sources, and marks each claim verified, refuted, or unverified, so a claim it could not check is flagged as unchecked rather than quietly passed. A verifier that says "I could not confirm this" is worth more than one that rubber-stamps.

Sometimes you do not know how big the job is until you are in it: a bug sweep where finding one bug reveals three more. That needs a cycle, an edge back to an earlier node. The danger is obvious. A cycle that does not converge is an infinite loop that spawns agents until the budget is gone.

The shape that converges is loop-until-dry: keep spawning finders until a few rounds in a row surface nothing new, then stop. The one detail that makes or breaks it, and the mistake almost everyone makes the first time, is what you dedupe against. Dedupe against everything seen, not just against what survived. Otherwise rejected findings reappear every round, the loop never runs dry, and you have built a machine that pays to rediscover the same dead ends.

Topology is not cosmetic. It is the single biggest lever on both wall-clock time and money. A barrier makes everything wait for the slowest node before the next stage starts. A pipeline streams each item through all its stages independently, so a fast item finishes instead of idling behind a slow one. Default to the pipeline; reach for a barrier only when a stage truly needs the whole set at once.

The other lever is the model. Not every node needs the strongest one. Run the bounded, repetitive nodes, extract this field, classify this input, on a cheap model, and keep the expensive tokens for the judgment nodes that adjudicate a finding or write the synthesis. A graph makes that split obvious in a way a single agent never does.

And the honest part. A graph is not always the answer. Tightly coupled work, where every step needs the last step's full context, belongs in one agent; splitting it turns the phases into a game of telephone that degrades at every handoff. A fleet also costs several times to an order of magnitude more tokens than one conversation doing the same task: Anthropic has reported its own multi-agent research system running roughly fifteen times the tokens of a single chat. Fan-out buys thoroughness, not correctness. When the work is a straight line, the straight line is the right architecture.