9 min read

Graph Engineering: A New Ring or a Bigger Loop?

Picture of Emmanuel Sciara Emmanuel Sciara : Updated on November 6, 2026

AI SDLC Coding Agents AI SDLC
Graph Engineering: A New Ring or a Bigger Loop?

This article is part of a series on AI coding agents' "XXX engineering" terms. Its thesis: each new term (prompt, context, harness, loop, graph) adds a ring around the last one instead of replacing it, and each article asks where the human sits. Find the other articles in the series:

  1. “AI Coding Agents: From Writing Prompts to Designing Systems”

  2. “Harness Engineering, or Agent = Model + Harness” [coming soon, working title]

  3. “Loop Engineering, or Sit on the Loop, Not in It” [coming soon, working title]

  4. “After Loop Engineering: Is Graph Engineering the Next Ring?” (this article)

  5. “Who Coined What: The Origins of the Agent-Engineering Terms” (companion article)

In the first article in this series, we introduced the diagram above with a ring dubbed "Graph? (July 2026, contested)", contested because in July the word "graph" still meant four different things and nothing showed it was a ring of its own. This article explores that question mark: is graph engineering the next ring around the loop, or did the ladder stop at loops... for now?

Beyond one loop: what a graph adds

What a loop does

A loop keeps one line of work going until its stop condition holds

Each turn's result decides the next turn, and no human prompts in between. One turn can chain several stages: at Mergify, Rémy Duthu gives each issue a single goal, and the agent chains every stage, from plan and spec through to tests and push; Rémy then reviews the result.

A loop can also work down a list, one task per turn, as Geoffrey Huntley's Ralph loop does with its plan file, fix_plan.md. Each stage can have its own check; the loop ends on one done-condition.

What a graph does

A graph engineers what happens between loops

That includes:

  • Which loop runs when;

  • Which waits for which;

  • How results pass from one to the next;

  • How their changes merge.

A loop that is the only writer on its branch can merge its own pull request, as OpenAI's Codex agents do; once several loops write changes that must be integrated into the same target, merging becomes integration of others' work, which, for instance, Cursor hands to a separate merge agent.

The checks, the retries and the stop rule inside each loop remain loop engineering. To tell them apart from graphs, count the writers:

  • One line of work writing at a time, however many stages or sequential tasks, is a loop;

  • Several agents writing, in parallel, changes headed for the same target (a branch, a shared trunk), so that their changes must be integrated, is the next level (graph), provided that coordination is designed in advance, by a script or a graph of tasks, rather than improvised by the model, because someone must then decide what runs in parallel, what waits for what and how the changes merge. Read-only helpers, such as a reviewer subagent or a goal evaluator, don't count, and independent PRs merged one by one by the usual CI and merge queue remain loops.

Two recent preprints define the graph by its structure rather than by counting writers: in a literature review, Yuyuan Feng and 34 co-authors build it from explicit graphs of tasks, agents and system states, and Sandeco Macedo's definition requires neither several models nor several agents, but excludes a plain chain of calls with no explicit representation of the graph.

In the approach taken here, a structure with one writer stays a loop, because one check still decides the outcome.

Others put parallel agents inside the loop, such as Addy Osmani (now at Anthropic, formerly Google Cloud AI), who lists worktrees for parallel agents among its parts. This post keeps the definition of "loop" for one line of work, because that is where the check lives.

Graph of control and graph of work

Coding-agent tools ship two forms of graph:

Graph of control

Each node is a task worked by its own agent, in one run or in a loop, and a script decides what runs next and passes results along.

In Claude Code's dynamic workflows, Claude writes that script and a runtime executes it: one agent per file across a 500-file migration, each working in its own isolated copy. Bringing the copies back together is left to the script or to an agent.

A script that only retries one task (keep fixing until the type check passes) is a loop written as code; it becomes a graph of control when it runs several writers and decides their order and how their changes come back together.

Graph of work

Each node is a task taken by its own agent or loop, and each edge says which task blocks which. Agents claim whatever is unblocked.

Beads, built by veteran engineer Steve Yegge (formerly at Amazon and Google), works this way. A list worked through one task at a time is not a graph of work: it is that loop's plan.

Claude Code's agent teams (experimental, off by default) are a hybrid with a lead agent:

Most products ship neither: a lead agent splits the work and spawns subagents (Codex, Cursor, Devin, Amp), which it coordinates itself. These subagents can write in parallel, but the model improvises the coordination on every run: no one designs it, so it is not graph engineering. It is exactly this coordination that the Stanford preprint and Cognition find fault with.

Where a team designs the hierarchy of responsibilities (roles, hand-offs, a merge step), those parts between loops are graph engineering too. Otherwise a human coordinates by hand, as with GitHub Copilot's coding agent, where someone assigns every issue.

Graph is the next ring only if coordination is the bottleneck

Each ring in this series added to the previous when the latter was good enough and the bottleneck moved outward. The same test applies here, in two halves:

  • Has the main bottleneck moved between loops?

  • Has the human's job moved to designing what happens there?

Graph is the next ring only if both answers are yes.

If most of a team's time still goes into getting one loop to finish reliably, a graph only arranges unreliable loops in a more elaborate order.

The evidence to support this, below, dates from June 2026 or later and comes from four kinds of sources:

  • Coding-agent vendors describing their own products and use: Anthropic (Claude Code), Cursor and Cognition (the maker of Devin). They support that, at scale, the bottleneck and the human have moved between loops (Cursor), that coordination left to a lead agent costs accuracy (Cognition), and what the two graph forms look like in shipped tools (Anthropic);

  • Engineers describing their own practice: Mergify, a company that sells merge queues to customers including Mozilla, Elastic and Back Market, and so has an interest in review and merging becoming the bottleneck. It supports that the bottleneck moves even in a small team running many agents, from writing code to reviewing it, at the end of each loop rather than between them;

  • Surveys and telemetry: GitKraken, the maker of a Git client, polling 554 people from its own community; and Jellyfish, an engineering analytics platform reporting on its customers' data. They suggest that the bottleneck has not moved for most teams, since few run agents autonomously (GitKraken) and nearly all still have a human review every pull request (Jellyfish);

  • Research: a preprint from Azalia Mirhoseini's group at Stanford, not yet peer-reviewed. It supports that coordination left to an agent's default subagents costs accuracy, and that coordination designed for the work can pay.

Most of these sources have a stake in what they report, and none is a controlled study of the trade.

Has the bottleneck moved?

Yes, for teams at scale:

Probably not, for most teams:

GitKraken's survey counts agents working autonomously, and Jellyfish's data counts merges without human review, not how many agents write in parallel. Yet a developer who steers five interactive sessions themselves, each in its own worktree, already has several agents writing at once; they would show up neither in GitKraken's 28% nor in Jellyfish's 0.6%.

Has the human moved?

Yes when at scale, where they focus on what happens between loops:

  • Cursor's engineers designed what sits between their agents: planners that split the work, a merge agent that resolves conflicts for all the others, and their own version control.

  • For a 500-file migration, Claude Code's dynamic workflows run one agent per file, each in its own isolated copy, then bring the changes back together: a graph of control.

At Cursor, a person writes the spec, no one steps in during the run, and the code is reviewed afterwards. That already holds for one loop: at Mergify, an engineer reviews each pushed pull request himself. The spec and the review don't tell graph from loop.

No elsewhere, particularly where teams keep using the default settings:

A plausible ring, not yet a proven one

Surveys suggest that most teams are not yet running enough loops to need coordinating them: their work still happens in one loop.

Teams that run many agents have hit limits in two places:

Only the first is graph engineering, and Cursor's engineers now design what happens between their agents. For teams at that scale, graph is a plausible next ring: their bottleneck has moved, and so has the human.

What they build depends on the form:

In each case, teams added structure rather than removing it. Designed for the work, coordination can pay: the same Stanford study found that agents sharing one work queue and one context beat the single agent, at 88%.

Yegge plays another game altogether. He wrote in August that his first orchestrator, Gas Town, "fell apart at the seams with Opus 4.7": the new model kept tinkering with the orchestrator instead of doing the work. Its successor, Wheelhouse, runs more than 40 agents around the clock on top of beads, lands 120 to 150 commits at once and keeps more than 700 designed tasks queued for overnight work. It adds far more structure than Cursor: role agents, written rules, a merge queue. Wheelhouse shows where coordination can go at the far frontier, not where most teams are, and it is built for one application, not as a layer others can reuse.

The next ring may also arrive under another name. "Graph" meant four different things in the July debate, as Turing Post counted. Outside coding, declared graphs are common: LangGraph, Microsoft Agent Framework and Google ADK 2.0 model agent workflows as graphs, mostly for business processes. The coding-agent tools call their versions subagents, task lists, workflows, missions or teams. Whatever the name, the test stays the same: does coordination limit you more than any single loop does?

If graph engineering is the next ring, the human sits between the loops, designing what runs when and what blocks what.

Graph may stick, or the next buzzword may arrive before this series ends. When it does, don't ask what it's called. Ask where it puts the human.

Coming next in the series: “Harness Engineering, or Agent = Model + Harness”, on how the environment became the lever [article to be published], and “Loop Engineering, or Sit on the Loop, Not in It”, on where the harness ends and the loop begins [article to be published].

Sources
Who Coined What: The Origins of the Agent-Engineering Terms

Who Coined What: The Origins of the Agent-Engineering Terms

Picture of Emmanuel Sciara Emmanuel Sciara : Oct 19, 2026, 11:30:44 PM

This article is part of a series on AI coding agents' "XXX engineering" terms. Its thesis: each new term (prompt, context, harness, loop, graph) adds...

AI SDLC Coding Agents AI SDLC
Read More
AI Coding Agents: From Writing Prompts to Designing Systems

4 min read

AI Coding Agents: From Writing Prompts to Designing Systems

Picture of Emmanuel Sciara Emmanuel Sciara : Oct 19, 2026, 11:57:20 PM

This article is part of a series on AI coding agents "XXX engineering" terms. Its thesis: each new term (prompt, context, harness, loop, graph) adds...

AI SDLC Coding Agents AI SDLC
Read More