Engineer the graph, not just the loop

There's a new phrase picking up right where loop engineering left off: graph engineering. If loop engineering was about designing the cycle a single agent runs — plan, execute, review, repeat until done — graph engineering is about what happens when one loop isn't enough, and you have to wire several specialized agents into a shape. Tools like ORCA now make that shape something you can actually build and run. And it raises the same question the loop did: a graph has to be a graph of something.

When one loop isn't enough

Loop engineering has a tidy structure: a trigger fires — a schedule, a new email, an opened PR — the agent plans, executes, and checks the result against an exit condition; if it's not met, it loops back, usually with a cap so it can't spin forever. That's the whole engine behind a lot of useful autonomy, and for a single well-scoped job it's plenty.

But plenty of work doesn't fit in one loop. It wants different agents doing different things — one that searches, five that summarize in parallel, one that merges, one that writes, one that checks — and it wants them to happen in a particular order, with results handed from one to the next. The moment you have more than one specialized agent and a dependency between them, you're no longer tuning a loop. You're drawing a graph.

Graph engineering, defined

Graph engineering is designing the topology of a multi-agent system: which nodes exist (agents, deterministic functions, routers, human checkpoints), which transitions between them are allowed, and how work flows through the whole thing. Loop engineering designs how a single node executes; graph engineering designs how the nodes connect. It's the layer up.

Two things make the idea click. First, a graph can contain loops — some nodes repeat until a condition holds, others (a summary, a cleanup) run exactly once, and that's fine; not every node is a loop. Second, the edges carry the interesting decisions: a node can branch to different children based on state, or route back to an earlier node when a check fails. The craft isn't the individual agents so much as the relationships and routing between them — which is why it's the same idea whether you draw it in LangGraph, AutoGen, Google's ADK, or a coding-agent orchestrator.

What ORCA makes concrete

The clearest hands-on version of this I've seen is ORCA, an environment for running a fleet of coding agents together. Your main session becomes an orchestrator, and it hands nodes of work to agent workers — Codex, Claude Code, Kimi — passing each result along to the next node. A recent walkthrough builds exactly this: five Codex terminals summarize five articles in parallel; a sixth node reads all five summaries and drafts a post about the most interesting one; a seventh node is a human review. Reject the draft and the feedback routes back through the orchestrator to the writing node; it revises, you re-review, and on approval the graph completes.

That little diagram has every primitive worth naming: parallel fan-out, a merge, a conditional loop-back on a failed check, and a human gate. It's a real org chart for agents. ORCA is the tool that makes drawing it feel routine — the way Addy Osmani's framing made the loop feel like the unit worth optimizing.

A graph is a plan you can execute

Now look at everything you had to decide before ORCA could run a single node. Which nodes exist and what each one owns. Which node feeds which. Where a human gets to say yes or no. What “approved” even means at the review node, and what happens on a reject. That set of decisions — the decomposition, the dependencies, the checkpoints, the definition of done at each step — isn't a byproduct of the graph. It is the graph. And it's also, exactly, a plan.

A plan has always been a dependency graph of work with human decision points in it: do these things, in this order, and here's where someone checks. Graph engineering just makes that plan executable — hands it to an orchestrator instead of to a team. The loop post argued the plan is the loop's memory and exit conditions. One level up, the plan is the graph's topology: the source of its nodes and its edges. The orchestrator is the runtime. The plan is the program.

An orchestrator runs the graph. Only a plan says what the graph should be.

The most important node is the human one

Notice which node did the real work in that demo: not any single summarizer, but the review checkpoint — the one place a person looked at the draft, said “make it clearer for non-experts,” and sent that judgment back into the graph. That is precisely the loop inplan is built around — the agent drafts and raises its open questions, a human answers the ones that need answering, the agent revises — only now it's a single node inside a much larger topology.

As graphs get deeper, the scarce resource stops being agents; you can spawn those by the dozen. What stays scarce is the shared artifact every node builds against, and the handful of points where a human's judgment actually enters. Both of those are the plan. Wire ten agents around a vague one and you've built a fast, parallel way to produce the wrong thing; wire them around a resolved plan and the topology finally has something true to run on.

Draw the graph in the plan first

So the move is the same one we always argue for, just scaled up. Before you wire five agents together, resolve the plan: the nodes (what each worker owns), the edges (what feeds what), the checkpoints (where you decide), and the exit (what “done” is). Then hand the orchestrator a decided graph instead of letting it discover the topology at runtime and hope it converges. In inplan that resolution looks the way it always has — the agent drafts the plan and flags its open questions inline, you answer the ones that need a human, and the work gets built against your answers. The only difference now is that the “work” on the far side is a whole fleet.

The loop was the unit. The graph is the org. The plan is both.

Graph engineering is a genuinely useful step up from the loop, and orchestrators like ORCA make it real work you can do today. But “better orchestration” and “better plan” were never competing answers. An orchestrator without a plan just runs faster in a direction nobody chose. Draw the graph where it belongs first — in a plan you and your agents actually share — and let the fleet execute the thing you meant.