Graph Engineering: The Layer After Loop Engineering

A few months back, I wrote about Loop Engineering: The Layer After Prompt, Context, and Harness Engineering, arguing that once your prompts are tuned, your context is assembled, and your harness is wired up, the thing that actually determines whether an agent works is the loop it runs in: how it decides to keep going, stop, retry, or hand off. A few readers asked a fair follow-up after that piece: loops over what, exactly? What happens when one job stops being one loop's worth of work?

That question turned out to have an answer that was already forming across the AI engineering world by the time I went looking for it. Mid-July 2026 saw a fast, noisy round of debate on X about exactly this, kicked off by a question from OpenClaw creator Peter Steinberger about whether the conversation had already moved past loops into graphs. Within a couple of days it had a name: graph engineering. I want to walk through what it actually means, where it overlaps with loop engineering, and where I think the skeptics in that debate had a fair point.

What Graph Engineering Actually Means

Here's the definition that held up best once I filtered out the hype: graph engineering is the practice of designing how multiple specialized agents or steps connect, not the internal cycle any one of them runs. A loop engineering designs the repeat-check-stop cycle a single agent goes through. Graph engineering designs how several of those loops hand off to each other.

Three parts make up that structure:

• Nodes – the units doing the work. Usually a specialized agent (researcher, writer, reviewer) or a plain deterministic step like a tool call or data fetch.
• Edges – the routing between nodes. Can be a straight handoff, a conditional branch, a fan-out to several nodes at once, or a fan-in that joins parallel results back together.
• Shared state – the object that travels along the edges. It's what turns a pile of agents into an actual system instead of a group of assistants that forget everything the moment they hand off.

One clarification I should make since I muddied this in my own earlier writing on the topic: this isn't the same thing as a knowledge graph or GraphRAG. Those model data, entities, and the relationships between them, for retrieval. Agent graph engineering models execution, which node runs next and what state it's handed. Same word, genuinely different problem, and it's an easy mix-up if you come at this from the infrastructure side as I do.

Where I'd Already Been Doing a Version of This

I didn't arrive at graphs from a whiteboard exercise. I got there from Terraform and service meshes. Years ago I wrote about visualizing Terraform plans and the tooling built around the terraform graph command, because a plan diff tells you what's changing, but a graph tells you what depends on what. Around the same time, I wrote about using Istio and its add-ons to visualize service meshes, where Kiali and Weave Scope turn a tangle of microservice calls into an actual picture of who talks to whom.

Those are dependency graphs, not agent orchestration graphs, and I want to be precise about that distinction now rather than blur it the way I did before. But the design instinct is the same one: decide what counts as a node, what counts as an edge, and don't let the structure stay implicit just because it's inconvenient to draw. That instinct is exactly what's being renamed and re-applied to multi-agent systems right now.

Graph and Loop, Side by Side

The cleanest way I've found to hold both concepts at once: the graph is the map, the loop is the walk. The graph defines what's reachable and who talks to whom. It doesn't say how many times a node should retry, when it should give up, or what counts as good enough before advancing. That's still the loop's job, running inside each node.

Every node in that diagram is its own loop underneath: the researcher discovers, plans, executes, and verifies its own search before handing off. The graph is only the outer wiring, deciding the researcher goes before the writer, and the reviewer's conditional edge decides whether the writer gets another pass. A single agent working alone is just the smallest possible version of this same shape: one node, with an edge that points back to itself.

The Layer Stack, Extended

My original loop engineering piece described a stack that ran from prompt to context to harness to loop. Graph is the next rung, and it's useful to see the whole climb at once.

The stack is cumulative, not a ladder you climb away from. A graph is made of nodes; a good node is a well-designed loop, and a good loop still needs the harness underneath it doing its job. Skip a lower layer and the graph on top just fails in a more elaborate, harder-to-debug way. If the individual nodes are weak agents, wiring them into an org chart just gives you a weak org.

When a Graph Actually Earns Its Keep

This is the part worth being disciplined about, because the honest default answer is that most tasks don't need one. A single well-scoped agent with a clear stopping condition is a loop, and reaching for a graph before the work demands it is how a two-hour task turns into a two-week framework project.

None of these signals need to be unanimous. But if most of the honest answers land in the left column, you're describing a loop that someone talked you into over-architecting.

Isn't This Just LangGraph?

Worth addressing directly, because it's the most common pushback and it's mostly fair. The idea of building agent systems as graphs of nodes and edges over shared state shipped in real frameworks well before the term "graph engineering" started trending. LangGraph has offered exactly this model for a while now. Microsoft's AutoGen added graph-based orchestration through what it calls GraphFlow. Google's Agent Development Kit builds graph-based architecture as a headline feature, with sequential, parallel, and loop workflow agents as first-class building blocks. The Agent2Agent protocol, A2A, tackles the related problem of agents delegating across systems owned by different teams entirely.

So when LangGraph's own creator publicly said he wasn't sure the term named anything beyond his own framework, that's a fair challenge worth taking seriously rather than waving off. My honest read: the technology mostly isn't new. What's newer is a shared vocabulary for a design decision these frameworks always asked of you anyway, which are what your nodes are, what your edges are, and what belongs in shared state. That's a real, useful naming exercise. It's a much smaller claim than "a new paradigm," and I'd rather undersell it than oversell it.

A Quick Comparison of the Framework Options

I made a related point about keeping routing logic and decision logic as separate, inspectable concerns in ToolOrchestra vs Mixture of Experts: Routing Intelligence at Scale, and about explicit versus implicit capability structures in MCP vs Skills vs Agents With Scripts. Both pieces land on the same conclusion this table does: an implicit graph is still a graph; you just can't see it until something breaks, so you're generally better off picking a framework that makes the structure explicit rather than hand-rolling one that hides it.

Where I Land On the Hype Question

The skeptics in this debate aren't wrong about the mechanics: directed graphs, state machines, and multi-agent orchestration predate this month's vocabulary by years, and a fair amount of what got published about it in the past couple of weeks is exactly the kind of hype cycle content you'd expect. I'd rather say that plainly than pretend this is a brand-new capability.

But separate the word from the actual shift, and there's something real underneath it. Teams that spent the past year getting good at running one agent in a loop are increasingly hitting cases where one loop is the wrong shape for the work, and are deliberately splitting it into coordinated, specialized nodes with state flowing between them. That escalation is happening whether or not you call it graph engineering, the same way the underlying shift I wrote about in the loop engineering piece was real whether or not "loop engineering" stuck as a term.

Where This Matters in Practice

Bringing this back to something concrete: in the incident response and SRE tooling I've written about recently, the AI agents that investigate production issues autonomously are, underneath the marketing, graph-and-loop systems. The graph is the set of things the agent is allowed to check: logs, metrics, traces, deploy history, past incidents. The loop is the policy for how it moves through that graph, how many sources to check before proposing a hypothesis, when to backtrack if the evidence doesn't line up, and when to stop and hand off to a human instead of guessing further.

Teams that get frustrated with these tools usually have a graph problem, not a model problem. If the agent's graph has no path to the system that actually caused the issue, no amount of looping finds it. Worth checking before blaming the reasoning quality of whatever model sits underneath.

A Short Checklist Before You Build One

1. Try to keep it a loop first. If a single well-scoped agent with a good verifier can do the job, stop there.
2. Only name a node if it's a genuine specialty, a different model, a different toolset, or a read-only reviewer role. Steps you could inline aren't nodes.
3. Draw the edges before you write code. If you can't sketch the routing on a napkin, it's already too complex.
4. Design the shared state object on purpose, and decide who's allowed to write to it. State drift is the fastest way a graph rots.
5. Give the reviewer node real teeth: a separate agent from the one that produced the work, not the same agent grading its own output.
6. Isolate failure so one bad node can retry without corrupting shared state or poisoning the rest of the run.
7. Reach for an existing framework, LangGraph, AutoGen's GraphFlow, or Google ADK, before hand-rolling your own orchestration runtime.