On 18 July, Peter Steinberger posted eleven words: "Are we still talking loops or did we shift to graphs yet?" Nothing shipped that day. No framework, no model, no capability. The post passed three million views inside a week and by the following morning "graph engineering" was circulating as the successor to loop engineering, a term that had itself only held the room since June. A week later Steinberger asked, with what reads as amusement, whether he was a graph engineer now. The term did not name a new thing. It named the discourse that formed around a question, and the question landed because the person asking it had done the same thing six weeks earlier with loops. Steinberger built OpenClaw; when he asks what the next layer is, a large audience assumes he has seen it.
What the term means when used seriously
Building an agent system as an explicit graph: nodes that do discrete work, edges that decide what runs next, a shared state object that travels the edges and collects what each node produced. Instead of one large prompt, or one agent looping until it declares itself done, you draw the topology and a runtime walks it. Loop engineering, which grew out of Geoffrey Huntley's Ralph method, was about keeping a single agent cycling past its context limit. Graph engineering is about what happens when several of those cycles need to be wired together with dependencies, branches, and gates between them.
Why now, and why the heat? Partly because the practice had outgrown the previous word. A loop with a validator node, a repair path, and a human approval step is not a loop any more, and people building such systems in June had no name for what they were drawing. Partly because naming is how this field allocates attention: prompt, context, harness, loop, graph, four renamings of the same reliability problem in eighteen months. Some of those renamings marked a change in the problem. Others marked a change in who was talking.
The four-part is it graph-engineered test
The test doing the rounds this year for separating the two has four parts. A system is graph-engineered when (1) you can enumerate its steps and transitions without running it, when (2) that structure lives apart from the prompts it drives, when (3) a runtime executes the structure rather than imperative code with control flow buried inside it, and when (4) the structure persists across runs as something you can version. The test comes from trade press, not from a standard, and the most cited academic framing is a preprint. The people defining the term are, for the most part, the people selling it.
Execution graphs, not knowledge graphs
Two things get called graphs in this space and they have nothing to do with each other. A knowledge graph, and the GraphRAG systems built on it, models data: entities, relations, what connects to what. An execution graph models who runs next, under what condition, carrying what state. Graph engineering in the 2026 sense means the second one. Nodes do work, whether that work is a model call, a tool invocation, a parser, or a human approving something. Edges say what happens after. A shared state object rides along the edges and accumulates what each node produced. If someone says graph engineering and means retrieval, they mean something else.
Each layer gets named when the one below stops being the bottleneck
The genealogy of the term is more interesting than its definition. Prompt engineering optimised the single turn: what the model is asked. Context engineering optimised the window: what the model sees. Loop engineering optimised the cycle: plan, act, reflect, revise, again. Graph engineering optimises the transitions between cycles: which loop runs, when it hands off, and what gate sits between them. Each layer got a name when the layer below stopped being the bottleneck. Nobody needed a word for transitions while a single loop could still absorb the whole task.
The Ralph Loop is the degenerate case: one node, one edge, the edge pointing back at the node. It passes the four-part test trivially, which is a useful sanity check on the test. A bash loop that re-reads a prompt file on every iteration has structure that can be enumerated without running it, structure separated from the prompt content, a runtime executing the structure, and a structure that persists. The graph is small. It is still a graph.
Converge, Not Fork is the fan-out and fan-in motif with the state object made physical. Parallel workers are nodes. The shared SQLite bus is the state that every node reads and writes. The convergence rule is the fan-in edge. When that piece argued for a shared bus over forked contexts, it was arguing about edge semantics: whether the graph merges by passing state or by passing transcripts.
The three-loop topology in the clive series is a graph with one slow edge, and the slow edge is a person. Two fast inner loops cycle without supervision. One outer loop advances only when a human transitions it. Drawn as a diagram, that is a conditional edge whose condition is an approval, which is exactly the human checkpoint node the graph frameworks describe. The Guest House isolation method adds a boundary around a subgraph; the production path across that boundary remains unverified, and the graph notation makes that gap easier to see, not harder.
Harness engineering, in the earlier sense, was the prompt side of this same separation. The harness was everything wrapped around the model call: instructions, tools, retries, verification. Graph engineering is what you get when you stop treating the wrapping as one thing and start drawing the transitions between the wrapped calls. The harness governs a node. The graph governs the edges. Same discipline, one level up, and the diff is the point.
The topology is the schema
The right structural analogy is a database schema against its queries. You migrate the schema deliberately, with review, and the migration is the artifact you keep. Queries are written against the schema and thrown away when they stop being useful. Under graph engineering, the topology is the schema. Prompts are queries. You review a change to an edge the way you review a migration, and you replace a prompt the way you rewrite a query when a faster model arrives. LangGraph and its peers are the reference implementations of this split: the framework holds the edges and the state, and the prompt strings are just data the nodes happen to carry.
Frameworks make this concrete in a way that is easy to mistake for the whole story. The guides walk through plan, decompose, execute in parallel, aggregate, validate, repair on failure. They show router nodes dispatching to specialists and evaluator nodes gating progress. All of that is real. All of it is also something a single strong model can now decide for itself at runtime, given the tools and a clear objective. The guides do not dwell on that.
Every edge is a decision the model no longer makes
A conditional branch that says "if validation fails, go to the repair node" is a routing judgement fixed at design time. A router node that dispatches on intent has replaced the model's own reading of the intent with a classifier you wrote. Each of these is defensible in isolation. Together they amount to a bet: that the topology you drew is a better router than the model would be, unsupervised, on the same inputs. In early 2025 that bet was usually right. The capability improvements since then have been improvements in exactly the judgement the edges take away, and the bet has a shelf life that shortens with each model generation. None of this argues against drawing the graph. It argues for knowing which edges are there because the model cannot be trusted with the decision, and which are there because a framework tutorial had a branch at that spot. The first kind is governance and should stay. The second kind is scaffolding and will become drag.
Governance edges and scaffolding edges
There is a way to tell them apart. A governance edge encodes a constraint that holds regardless of how capable the node behind it becomes: a deploy needs a human, a spend needs a ceiling, a merge needs a passing test. A scaffolding edge encodes a workaround for a capability the model lacked when the graph was drawn: decompose because the model could not hold the whole task, validate separately because the model could not check its own work. Governance edges belong in the schema. Scaffolding edges belong in the queries, where they can be deleted.
Legibility and capability are moving apart
Auditability lives in the edges, because the edges are the only part of the system you can read without running it. Capability lives in the nodes, because the nodes are where the models are. Those two are moving in opposite directions: the edges get more legible as the tooling improves and the nodes get less legible as the models improve. Graph engineering is the practice of holding those apart on purpose. Whether the graph or the model should own control flow is not a question with one answer. It has a different answer for a deploy gate than for a research loop, and the discipline that matters is not drawing the graph but deciding, edge by edge, which of the two you are looking at.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.