Graph Engineering

Image source: The AI Operator, Eugeniu Ghelbur.

The Agent space has had a familiar pace these past two weeks.

Last month, everyone was discussing Loop Engineering: stop treating Agents as one-off conversations; make them capable of triggering, executing, verifying, retrying, and knowing when to stop.

Not long after, OpenClaw founder Peter Steinberger dropped a teasing remark on X: "Are we still talking loops or did we shift to graphs yet?" Soon after, Hamel Husain titled his article "Loop Engineering Is Dead. Enter Graph Engineering."

A new buzzword has arrived. But this time, behind the hype lies a very concrete engineering problem: When a single Agent can already complete tasks autonomously in a loop, how do multiple Agents work together without causing chaos for each other?

I'm reluctant to call Graph Engineering the "next generation of Loop." It's not a replacement. A more accurate description is: Loop solves how a single role repeatedly gets things done; Graph solves how tasks should be handed off, verified, paused, and resumed among many roles, tools, and human approvals.

From "It Can Do Things" to "They Can Collaborate"

A single Agent loop is easy to understand.

It receives a task, calls a tool, sees the result, decides whether to continue; retries on failure, ends on completion. Writing code, handling fixed-type tickets, daily log checks—all can start with a small loop.

Problems arise when tasks become complex.

For example, a request like "help me deploy this change" might involve simultaneous needs: requirement understanding, code modification, testing, risk checks, deployment permissions, and human confirmation. You could certainly have the same Agent do it all in one go. But you'll quickly run into some uncomfortable issues:

• Why should a pile of materials found during the research phase be passed unchanged to the deployment phase?
• When a test fails, should it go back to code modification or be escalated to a human?
• Who has the authority to trigger the actual production deployment?
• If there's a network timeout, will a retry send the same email or execute the same operation twice?

These are no longer questions of "is the prompt written well enough." They are questions of collaboration dynamics.

Image source: Anthropic · Building Effective AI Agents.

Graph Engineering is precisely about bringing these implicit relationships into the open.

Its concern isn't "drawing a more complex flowchart," but turning responsibilities within the system into executable contracts: what a node can do, what it needs to read, what evidence it leaves behind; what results can proceed to the next step; what situations require a stop; what actions must go through a human.

In this sense, a Graph is more like an organizational chart than an assembly line. Nodes don't all have to be Agents: they can be model calls, deterministic validation scripts, database writes, routers, or human approval points. A Loop can also be nested inside a node, dedicated to a specific type of work.

At this point, you might think: isn't this just a task graph that's existed all along? Indeed. To understand what's genuinely new about Graph Engineering, we first need to recognize the older, more foundational concept behind it: the DAG.

DAG: It Didn't Start with the Agent Era

DAG stands for Directed Acyclic Graph. Directed means arrows have direction: B can only start after A finishes; Acyclic means following the arrows won't lead you back to the starting point.

Placed in an engineering context, it's a task relay chart. Downstream tasks can only start after upstream tasks finish; tasks without dependencies can run in parallel. For example, fetch data, then clean, train, and finally generate reports—dependencies are clear at a glance.

DAG comes from graph theory, not invented for LLMs. It has long been used in dependency management, data pipelines, and task scheduling. Systems like Apache Airflow are built around DAGs: tasks, dependencies, retries, timeouts, and execution frequencies are all organized around it.

The benefit of DAG is predictability. The scheduler doesn't need to understand the business details of each task; it just needs to know the dependencies to decide what runs first, what can run in parallel, and how to retry on failure according to rules. It excels at handling work with clear boundaries and relatively fixed paths.

What Does Graph Add Beyond DAG?

DAG itself is a special case of Graph: it dictates that the entire graph cannot have cycles. Graph is broader; it can contain DAGs but can also allow cycles, feedback, conditional branching, and multiple handoffs.

This isn't to say Graph is inherently more advanced. For fixed data pipelines, DAG is often the clearest choice; forcing cycles into it only complicates the system. The real difference is: when tasks need to reroute based on intermediate results, require repeated validation, or need to incorporate humans into the approval chain, DAG's "forward-only" nature starts to fall short.

Agents amplify this difference. In the past, nodes in a DAG were mostly deterministic programs; now, nodes can be LLMs that read ambiguous tasks, choose tools, and decide the next step on the fly. They need more than just dependency order; they need clear states, permissions, budgets, evidence, and stopping conditions.

Therefore, I prefer to understand it as: DAG solves how tasks queue up; Graph Engineering solves how a group of autonomous actors collaborate within boundaries—not "more advanced," but with fewer constraints. An Agent's loop can execute repeatedly inside a node; Graph manages how these loops hand off, branch, and pause.

Why the Sudden Hype Now?

It's not because graph theory suddenly had a new discovery, nor did a brand-new framework emerge overnight. It's more like everyone got individual Agents running first, only to realize the bottleneck shifted from "can it do the task" to "how do they collaborate."

A single loop enables one role to observe, execute, verify, and retry; but put ten independently running loops together, and someone still has to design who assigns tasks, who merges results, where failures go back to, and who has final authority. Peter Steinberger's teasing remark spread precisely because it hit this collective experience.

What's Truly New Isn't the "Graph," but Control

Frameworks like LangGraph have long described such systems with three things: State is the task ledger, recording what's happening now; Nodes are the various work units; Edges dictate who a result can be passed to next.

The fresh part is that today, many nodes are occupied by LLMs. The more autonomous the nodes, the less the system can leave critical boundaries to "it should understand."

Thus, what Graph Engineering truly needs to design are usually these five things:

First, State. Which information is the factual record of the entire task, and which belongs only to a node's temporary context? An ever-growing chat history is not the same as a resumable task state.

Second, Routing. When the model says "I'm done," who decides the next step? Does it go to testing, to another expert, back for more information, or end directly? The more this edge affects cost, permissions, or risk, the less it should be ambiguous.

Third, Validation. Having another model say "looks good" can be helpful, but shouldn't be the final evidence. Test results, database receipts, payment statuses, user confirmations—these are the real feedback from outside the system.

Fourth, Replay. It's normal for a node to re-execute after a timeout; it's not normal to send the same external email or deduct the same payment twice. Actions with side effects need "idempotency protection"—running the same request twice results in the effect happening only once.

Fifth, Authorization. When should the Agent decide for itself, and when should it stop and ask a human? Deleting data, changing production configurations, making payments, sending external messages—these actions shouldn't rely on "the model is smart enough" as a safety net.

If these aren't clearly defined, so-called "multi-Agent collaboration" can easily become a group of models forwarding the same context to each other, confidently making mistakes together.

Why is the Community Both Excited and Rolling Its Eyes?

Reddit already has people experimenting along these lines. The original poster broke down a type of work into a DAG: research, implementation, testing, and approval each occupy a node, and this graph determines where the result is handed off.

Within each node, there can still be its own loops, as well as tool interfaces, necessary context for the moment, long-term records, and reusable operational guidelines. In plain language: the researcher can look up information, the tester only runs tests, and the deployer only gets deployment permissions when conditions are met.

One point that's easy to confuse here: the DAG describes how these roles hand off work; whether to retry or loop internally within a node is a separate matter. Graph Engineering doesn't always have to be drawn as a DAG, but a DAG is the form that most clearly reveals responsibility boundaries.

A comment later popped the bubble with one sentence: "Isn't this just a DAG?" This critique isn't wrong. Orchestration, state machines, and task graphs are all mature software engineering concepts; Graph Engineering didn't suddenly invent them.

Its value persists because many boundaries were previously given naturally by deterministic code; now, with LLMs placed in the middle, boundaries become soft. A model might interpret the same input as different tasks, or take initiative when information is insufficient. Either you write constraints into the system, or you continue to have someone monitor every single run.

Therefore, the most valuable aspect of Graph Engineering is not making a system "look like an AI company," but making the system's control visible again.

When to Use a Graph, When to Use a Loop

Having more Agents doesn't automatically necessitate a graph.

If a task is a fixed three-step process, retries are fixed upon failure, and all actions are within the same risk level, a clear loop or a few ordinary code segments are often more reliable. Anthropic also repeatedly emphasizes in engineering practice: start with the simplest solution that solves the problem, and only add complexity when it genuinely improves the outcome.

The moments truly worth explicitly building a graph are often these: tasks require parallel division of labor, results need to converge somewhere; different branches have different permissions; there are multiple ways to handle failure; state needs to be saved and replayed across steps; or you need to be able to answer "why did this task end up here?"

If, after drawing it, you still can't clearly say who is responsible for which outcome, which outcome can bypass verification checkpoints, or who can terminate the run, then it's just a pretty picture, not engineering design.

How to Start

If I were to refactor a mature Agent task towards a Graph tomorrow, I wouldn't start by setting up a multi-agent framework. I'd do three things first.

First, write out the failure paths. Everyone can think of the success path; what truly consumes manpower are timeouts, empty results, conflicting results, and unauthorized actions.

Next, write the task state as structured records: task ID, input summary, current phase, external evidence, retry count, budget, approval status. This way, whether restarting, escalating to a human, or replaying, there's a clear record.

Finally, separate verification from side effects. What can be confirmed by code, tests, or receipts shouldn't be left to the model for self-evaluation; for actions with irreversible consequences, give them idempotency keys, budget caps, and human approval thresholds.

This doesn't sound flashy, but it's the part that moves an Agent from a demo to a real system.

Conclusion: Don't Rush to Adopt a New Buzzword

From Prompt to Context, Harness, Loop, and now Graph, what's changing isn't "engineers having to memorize one more concept." The change is that after giving Agents a larger scope of action, we are finally forced to seriously design their boundaries.

Loops give a single role the chance to complete a task; Graphs require multiple roles to collaborate in an orderly fashion amidst uncertainty.

If this wave of hype ultimately leads to less discussion about "adding one more Agent" and more discussion about state, verification, permissions, recovery, and human oversight, then this term won't have trended in vain.

References

1. Peter Steinberger's X post — "Are we still talking loops or did we shift to graphs yet?" The original tweet, the ignition point for the Graph Engineering topic referenced at the beginning of this article.
2. Reddit: Wtf are graph engineered agents — The original post for the "community is both excited and rolling its eyes" discussion in the article, containing the classic "Isn't this just a DAG?" critique.
3. LangGraph Official Documentation: State Reducers — Framework documentation for the three elements (State/Nodes/Edges) and the state ledger mechanism mentioned in the article.
4. Apache Airflow Official Documentation: DAGs — Authoritative source for the DAG concept in data orchestration, providing background for understanding "graph orchestration predates the Agent era."