What the Heck is Graph Engineering?

A few weeks ago, I wrote about loop engineering. The idea that you stop prompting your agent and start building the system that prompts it for you.

Then, my feed told me it was already obsolete.

The trigger was Peter Steinberger, the creator of OpenClaw, asking out loud whether we were still talking loops or had shifted to graphs. It read like a joke about how fast we rename things. It did not stay a joke. Within a day, graph engineering was the thing you were apparently behind on.

So, What Is It?

Graph engineering is designing the network of workers that does the job, and the handoffs between them.

Now, if you have designed or built a loop before, you have already built a graph. You just did not call it one. That means you already know the parts. A worker does a piece of the job. A handoff passes it to whoever goes next. A shared file carries what has been figured out so far, so each worker picks up where the last one left off.

Most of your workers will be agents, but they do not have to be. A worker can also be a human approving something, a plain script, a single model call, an entire loop, or another network entirely.

That is why two networks can have the exact same shape and be nothing alike. In one, every worker is a single agent. In another, every worker is a whole loop, cycling on its own until its piece of the job is done.

Same shape. Far more happening inside.

Two Jobs, Two Shapes

The fastest way to see the difference is to put two jobs from the same repo side by side.

As a loop. Every morning, a scheduled run opens my flaky test list, picks the top one, writes a fix, and runs the suite. If the tests still fail, it tries again. If they pass, it opens a PR, ticks that test off the list, and stops. One agent, one path, repeating until the stop condition is true.

That is loop engineering. A target, a checker, a state file, and a cap on how long it can go.

As a graph. Now take a bigger job in the same repo: a migration that touches dozens of files. One subagent scans the codebase and returns the list of files to change. That list fans out to one worker per file, each in its own worktree so nothing collides.

Each of those workers is not a single agent. It is the same shape as the loop above, pointed at one file: make the change, run the tests, fix what broke, repeat until that file is green. Only then does it hand its diff to a reviewer.

The reviewer decides who goes next. Clean diffs go to the worker that merges. Broken ones go back for another pass. Anything touching auth stops and waits for me to approve.

That is graph engineering. Same tools, different shape. The loop is one agent on repeat. The graph is a scout, a row of loops running side by side, a reviewer, and a human as the last gate.

The Loop Lives Inside the Graph

Graph engineering does not kill loop engineering. It contains it. A loop is the version with a single worker in it.

This is the same pattern I keep seeing. It happened with prompt to context to harness engineering. Each layer wraps the one below it instead of replacing it. Prompting still lives inside context. Context still lives inside the harness. The loop still lives inside the graph.

Each rung moves the work further from the model and deeper into the system you build around it. Graph engineering is just the top rung so far. It will not be the last one.

Nothing died. The frame just moved up a floor.

The One Move a Loop Cannot Make

So, if a loop is one agent cycling, what can a network actually do that it cannot?

The honest answer is one word: branch.

A loop runs one thing at a time, over and over. A graph can split one task into many and run them at once. This is called fan-out and fan-in. You spread work across parallel workers, then join the results back together.

The version I run myself is on pull requests. A PR comes in, and three agents start at once: one reading for security, one for performance, one checking the tests. Nobody waits for anybody. When all three are done, a fourth agent takes the three sets of findings and turns them into one verdict.

A loop would do those checks one after another. A graph does them together, then joins. That is the move a single loop genuinely cannot make.

Two Things to Watch Out For

A graph sounds like all upside. More workers, more checks, more work done at once. Then you build one.

Same Model, Same Harness, Same Blind Spots

Go back to that PR example. There is a catch in it.

Those three review agents run on the same model and inside the same harness. Same tools, same context, same house rules. When all three agree, it feels like three independent confirmations. It is one opinion delivered three times, now with more confidence attached.

Carlos Perez has the best name for the result. A graph of agents checking agents, he warns, can produce extremely organized nonsense. Workers that share a model and a harness share their blind spots, so they end up validating each other's mistakes instead of catching them.

Fan-out multiplies throughput. It does not multiply judgment.

So one of your checks has to be something the network cannot generate on its own. A test suite that really ran. A different model. A human. Anything with an independent reason to disagree.

This is the same trap I wrote about in verification is a bottleneck. A graph makes it worse. Ten workers running at once hand you ten times the output to check, and they finish in the time one worker used to take.

You Pay for Every Worker

When Anthropic built its multi-agent research system, a lead agent spawning parallel subagents outperformed single-agent Claude Opus 4 by 90.2% on their internal eval. It also used about 15 times the tokens of a normal chat, by their own measure. That is the trade in one line. A network buys real capability, and it charges you for every worker whether that worker needed to exist or not.

So my default is still a loop. One well-scoped loop with a good verifier goes further than most people expect, and it is far cheaper to debug when it goes wrong.

Rules I Follow

• Try to keep it a loop. If one agent with a solid checker can do the job, stop there. You are done.
• Draw the handoffs before you write any code. If you cannot sketch who passes what to whom on a napkin, it is too complex to build.
• Every worker should earn its place. Give a task its own worker only if it is a real specialty: a different model, a different toolset, a read-only reviewer, or a human who has to sign off. Not just a step you could have kept inline.
• Watch for the fake graph. Half the times I thought "I need a graph," what I actually had was a weak verifier. A better checker in a simple loop beat a fancy network every time.

Building a Graph Is Building an Org

Read those rules again and they stop sounding like engineering. Keep the team small. Do not hire someone unless the role is real. Never let the person who did the work be the only one who checks it.

That is not a coincidence. An org chart is a graph. People in the boxes, handoffs between them, and someone deciding who picks up the work next. Swap the people for agents and the drawing does not change.

Melvin Conway noticed in 1968 that any organization designing a system ends up producing a design that copies the organization's own communication structure. The shape of your team leaks into whatever your team builds.

Graph engineering runs that backwards. You are not leaking an org chart into the system by accident. You are drawing one on purpose, and the agents follow it exactly.

Which is why the reasons to add a worker are the reasons to make a hire. Anthropic's guidance on multi-agent systems gives three.

Why an org adds a person	Why a graph adds a worker
They know something nobody else does	Specialization. A different model or toolset.
There is more work than one person can do	Parallelization. Run the pieces at once.
Not everyone needs to see everything	Context protection. A clean context each.

One rule runs the other way. Two people who need to talk every ten minutes should not sit on different teams. The same guidance says it about agents: anything that needs constant back-and-forth belongs inside one worker, not spread across several.

Who does what. Who checks whom. Who needs to know. People have been answering those questions for as long as there have been teams. Graph engineering is the same job, with agents in the seats.

Should You Build One?

So, what the heck is graph engineering? It is loop engineering with more than one worker. Agents, whole loops, scripts, and humans that do the job, handoffs that decide who goes next, and a shared file flowing along the way. It shines when the job really needs more than one worker, and it is overkill when it does not.

Do not let the word "dead" fool you. Loop engineering is not gone. It is nested inside this, the same way prompting is nested inside context.

My advice is the same as it was for loops. Start with the simplest thing that works, which is almost always a single loop. Add a worker only when a real problem forces you to. And keep reviewing what the system builds, because a graph that runs unattended is also a graph making mistakes unattended, now in parallel.

Build the graph when the work calls for it. Not because the word is trending.