Graph Engineering: Don't Let One Agent Be Both Player and Referee

Posted on 2026-07-27 In AI Applications Views: Word count in article: 3.2k Reading time ≈ 12 mins.

Graph Engineering does not replace the agent loop. It separates execution, validation, and direction so one agent does not judge its own work.

If the same loop produces a result, checks it, and decides what happens next, it easily becomes athlete, referee, and scorekeeper all at once. Graph Engineering is about how multiple loops divide work, hand it off, correct course, and stop.

Over the last few days, Graph Engineering has been everywhere. Some people treat it as a multi-agent workflow. Others stress generating tasks at runtime. Still others talk about “letting a loop inspect a loop.”

The term does not yet have a widely accepted definition, but one point is already clear: the loop has not been replaced by the graph. Only when a single loop can no longer shoulder execution, validation, and direction-setting does the engineering problem move from within one loop to the relationships among many loops.

Banner contrasting one overloaded agent loop with a graph of divided roles

How did Graph Engineering enter the conversation?

It started with a short question. On July 18, OpenClaw author Peter Steinberger asked: “Are we still talking loops or did we shift to graphs yet?”

Peter Steinberger tweet asking whether the industry shifted from loops to graphs

That nine-word tweet[1] has already been viewed nearly 3 million times.

A few hours later, Hamel Husain posted a clickbait title: Loop Engineering Is Dead. Enter Graph Engineering.[2] The post itself was only a GIF.

Animated GIF used in Hamel Husain's Loop Engineering Is Dead post

He later replied, bluntly: “Nobody knows what it is.”[3]

A term without a shared definition already has attention, competing camps, architecture diagrams, and tutorials. The AI coding community is not so different from show business these days.

Meme comparing AI coding discourse to entertainment-industry hype cycles

Follow the OceanBase community WeChat account “老纪的技术唠嗑局” for ongoing writing on AI and data.

First, a few words about Loop Engineering

Why hadn’t we written a dedicated WeChat article about Loop Engineering before?

First, before Loop Engineering suddenly went viral, we had already talked about the harness (see A Deep “Dissection” of the AI Agent Harness).

In that article, LangChain put it plainly: Agent = model + harness. “Since you did not build the model, everything you do is harness work.”

Diagram showing an agent as a model plus harness of surrounding engineering

So harness engineering already includes:

Prompt Engineering: a single-argument function. How to write a high-quality prompt so the model produces a better result.
Context Engineering: a multi-argument function. Which context the model should see so it produces a better result.
Loop Engineering: a cyclic program with stateful feedback. How to keep the model running autonomously for an extended period and help it complete the task more effectively.
…and many other components, which we will not list one by one here.

Second, the loop has always been the foundation of an agent. It is not a new idea. An AI agent operates as follows: perceive → reason → act → observe → reason again (the ReAct pattern, Reasoning + Acting). The biggest difference between an agent and a chatbot is that an agent can operate in a loop. It iterates instead of producing a single response, as in a traditional AI conversation.

If we insist on distinguishing Loop Engineering from ReAct, my reading is that Loop Engineering simply wraps another loop around ReAct: a parent loop around child loops, reducing human intervention and allowing the agent to detect changes in its environment and continue until it meets the goal. In practice, there is usually no need to draw a hard line between Loop Engineering and ReAct.

Until recently, the more common discussion was which loop form fits which scenario: turn-based, goal-based, time-based, or proactive. That is not the focus of this article, so we will not go further. One recommended piece is Akshay Pachaar’s The four types of agent loops[4].

What is the AI community talking about when it says Graph Engineering?

My interpretation

Following the same pattern, if Loop Engineering is a cyclic program with stateful feedback, I would read Graph Engineering as a distributed program made of multiple program nodes.

In real work you may need several agents running in parallel, with dependencies between them. That is more than a while loop. The matching computer-science idea is a graph.

Directed graph of interdependent agents instead of a single while loop

This graph is a directed graph. When one agent finishes, its result may need to go to another agent, so the edges need a direction.

Note: this is not a DAG (directed acyclic graph). Real cases can contain cycles: after a node finishes, work may return to an earlier node.

It is closer to an FSM (finite-state machine), which is also a graph: the model switches among states until it reaches the goal.

Many large tasks, when examined closely, essentially involve building an FSM. An earlier agent hands work to a later one; if the later agent finds a problem, it may send the work back.

Finite-state machine view of agents handing work forward and looping back

So Graph Engineering, like Loop Engineering, is not an entirely new concept. Engineering practice has simply arrived at a stage where we need graphs to describe and solve real problems.

Illustration that graph engineering is a stage of practice rather than a new invention

If you put the high-engagement threads together, the rough consensus looks like this:

The loop still exists. An agent still has to act on results, verify, and correct. That remains the foundation of an agent.
The graph organizes multiple execution units. It describes who goes first, who can run in parallel, where to go back when a check fails, and when a human should step in.
Not every node is an agent. A node can be a tool, a deterministic program, a verifier, or a person. Each agent node may still run its own loop.
Checkpoints and failure paths matter more than the number of boxes. If every arrow only says “continue,” you just drew a more complicated pipeline.

Community consensus that graphs organize loops, checkpoints, and failure paths

LangGraph, AutoGen, and traditional workflow systems have long handled nodes, state, branches, and retries. What changed in this round is that agent nodes are more autonomous and more uncertain: they may change the plan on the fly, call tools that alter the real environment, and keep splitting tasks while they run.

LangGraph-style diagram of autonomous agent nodes with branches and retries

Some questions are still open

The community is still splitting around a few clusters of questions:

Focus	Relatively clear	Still unresolved
How Graph and Loop relate	In most accounts, a graph contains multiple loops that continue to run	At what point a collection of loops should be called a graph
Whether the graph is drawn in advance	Stable steps, permissions, and checkpoints usually need prior constraints	How dynamic the concrete tasks, branches, and even roles can be
How multiple agents collaborate	Division of labor, parallelism, and handoff are the mainstream focus	Whether this is only a relay, or one loop should calibrate another
What a Work Graph is	It can describe tasks and dependencies that form during one run	It is not a unified term, and not a settled conclusion
Whether more agents are better	Tasks suited to parallel exploration may benefit	For sequential tasks, coordination costs may exceed the gains

The third row is the one most worth chasing.

If a graph is only “the research agent finishes and hands off to the writing agent,” it looks like a traditional workflow with smarter nodes. Another line is already in the discussion: one agent implements, an independent agent reviews, another hunts for counterexamples, and yet another rechecks whether the original goal has drifted. They do not only relay work. They inspect, challenge, and if needed block one another. “You need loops watching loops”[5] is exactly this layer.

There are already many frameworks and established practices for orchestrating multiple loops. There is still no shared method for letting one loop inspect, calibrate, or even halt another. That second problem determines whether the graph is merely a collaboration diagram or a system that can actually correct course.

How should we understand Graph Engineering?

Start with the loop: how an executor runs on feedback

A loop is not only a while in code. An executor sees a result, decides the next step, acts, verifies, and then adjusts with new information. That is a loop.

Executor loop of deciding, acting, verifying, and adjusting from feedback

It answers a concrete question: how does one executor keep pushing the work forward? Goal, context, tools, verification methods, exit conditions, and human confirmation are all part of that cycle.

Loop components including goal, tools, verification, exit, and human confirmation

A single loop is simple, flexible, and fast to react. The problem comes from the same place: if producing the result, checking the result, and judging direction all live in one loop, it easily becomes athlete, referee, and scorekeeper at once.

Execution, validation, and direction cannot all sit in one loop

When one loop can no longer shoulder every responsibility, you split them: someone does the work, someone validates it independently, and someone periodically reassesses the direction.

Three responsibilities split across doing, checking, and direction-setting loops

The doing loop cares about moving the work in front of it: search, write code, generate content, fix issues.
The validation loop does not continue doing the first loop’s job. It uses tests, constraints, and counterexamples to judge whether the work is correct.
The direction loop takes a slower, longer-term view: why does the same problem keep returning? Is the cost worth it? Do users actually accept the result? Is the original goal still reasonable?

Doing, checking, and direction loops as advance, correct, and redirect

These three loops do not have to map to three agents, and they do not have to run at every step. They name three responsibilities: advance, correct, and redirect.

You can treat a loop as a work unit that keeps adjusting from feedback, and a graph as the division of labor, handoff, inspection, and control among those units.

How multiple loops work together: clear handoffs, enforceable checks, and a way to stop

If a loop is an executor that finds its own path, the graph is not about how you arrange desks. It is about who hands what to whom, who accepts the work, whether a bad result can be sent back, and who calls a halt when the direction is wrong.

Handoff, acceptance, rollback, and stop relations among cooperating loops

Layer	What must be clear	What happens if it is not
How work flows	Who owns what; which artifacts, evidence, current state, and open questions the upstream must deliver	The arrow collapses into “I’m done,” and the downstream has to guess again
How results are validated	Who checks independently; after a failed check, whether to retry, roll back, change path, or change owner	Review can only comment and cannot change the outcome
How the system stops or changes direction	Who can block further execution; who can adjust goals and rules from longer-term results	Every node only moves forward, and the whole system cannot stop even when it drifts together

When you design failure paths, also write down who receives the rollback, how many retries are allowed, when to escalate to a person, and how much budget has already been spent. Once a node can call tools or change the real environment, permissions must tighten with role and stage. A node that is “responsible for checking” must not casually rewrite the result it is checking.

For example, the implementation loop hands over code and test evidence. The validation loop does not rely on the first loop’s account of its own work; it runs the tests, checks the constraints, and looks for counterexamples. After a failed check, the work is actually sent back. If the original goal itself is wrong, the direction loop or a human reassesses it. A check is meaningful only if it can change the subsequent path.

Traditional workflows mainly decide which step runs next. In Graph Engineering, nodes may find their own paths, change the plan, call tools, and even modify the real environment. You therefore also have to decide who is allowed to judge, what evidence is handed over, who can veto, and when work returns to a person.

How a graph can evolve: set the outer boundary first, then adapt within it

The community has proposed both predefined routes and task graphs that agents generate at runtime, along with approaches that add or remove roles as difficulty changes. In practice, the answer is more likely this: permissions, acceptance criteria, and a few mandatory stop points are set first; the number of tasks created during a run and the branches taken can be adjusted along the way.

Stable outer boundary of permissions, acceptance, budget, and human gates

Permissions, acceptance, budget, and human gates form a relatively stable outer layer. How this task is split, whether it runs in parallel, and when to add a check can be adjusted inside that boundary.

Some people call the tasks and dependencies that form during a run a Work Graph. The phrase can help understanding, but it is not a unified term, and it is not a validated conclusion. Asana has also long used Work Graph® for a different work-data model.

Seen as program structure, a state machine helps

From a programmer’s perspective, the ideas line up: Prompt Engineering is like a single-argument function that takes only a prompt; Context Engineering is like a function that receives several context parameters; Harness Engineering then wires in tools, permissions, and the runtime. Loop Engineering lets the program read state and feedback and keep adjusting.

With Graph Engineering, several stateful execution nodes are wired into a graph. Work can branch, join, roll back, and stop when needed.

If a failed check rolls work back, replans, or re-enters a node that already ran, the path can contain a cycle. A finite-state machine (FSM) is a useful analogy: the system switches among states according to results until an exit condition is met.

State-machine analogy for branching, joining, rolling back, and stopping

This is only an analogy for control relationships. It is not a technical definition of Graph Engineering. Graph theory and state machines are not new. What changed is the agent node itself: it starts splitting tasks, changing plans, calling tools, and modifying the real environment. Control methods that used to live in workflows and distributed systems now have to be brought back for nodes that are more autonomous and more uncertain.

When a graph is worth it: only if the task actually needs it

A graph does not mean “the more agents, the better.” It suits tasks that can be split into relatively independent parts, where different parts need different information, tools, or permissions, intermediate results can be checked independently, and only a local piece needs to be redone after a failure.

If the task is small, every step strictly depends on the previous one, and every agent keeps editing the same artifact, one clear loop is often better. Anthropic’s multi-agent research system[6] is well suited to broad search and parallel exploration, but its official engineering write-up also notes that the multi-agent system uses about 15× the tokens of ordinary chat. Experiments from Google Research, Google DeepMind, and MIT[7] found that multi-agent setups may improve performance on parallelizable tasks but perform worse on strictly sequential ones.

When a multi-agent graph helps versus when one clear loop is better

The next time you see a graph, ask three questions:

What relationship does it solve that one loop cannot?
Can a check actually roll work back, change the path, or halt it?
Is the added coordination cost smaller than the independent judgment and local recovery it brings?

Start from one clear loop. A graph is more likely to pay off only when the task can be split, intermediate results can be accepted on their own, and you truly need different information, tools, or permissions.

Closing: the loop is not dead

Graph Engineering still has no widely accepted definition, and there is no need to force a precise boundary yet.

The loop still moves local work forward. The graph starts to matter only when execution, validation, and direction-setting need to be split apart.

Closing illustration that loops still drive work while graphs split responsibilities

What you actually have to design is whether those relationships are enforceable: whether a handoff carries artifacts and evidence, whether a check can change the subsequent path, and who reassesses the work when its direction is wrong.

If you cannot do that, a graph is only a more complicated and more expensive flowchart. If you can, the engineering problem shifts from “how one agent keeps doing the work” to “how multiple loops collaborate, and how they avoid drifting together.”

Takeaway that a graph only matters when checks can change the later path