FORGET Loop Engineering. Graph Engineering is about THIS
Graph engineering is about designing the relationships between those processes. The name is new. But most of the hard problems are not.
As AI agents become more complex, simply repeating the same process will no longer be enough to automate tasks.
Real-world work involves multiple people, dependencies, approvals, conditional branching, and exception handling.
The idea of designing such complex tasks not as a simple linear process but as a structured system of interconnected relationships is gaining attention.
In July 2026, the term “Graph Engineering” began to spread rapidly around the field of AI agent development.
One of the triggers was a short post by Peter Steinberger of OpenClaw that essentially asked, “Are we still talking about loops, or have we moved on to graphs?”
Just a few weeks ago, the hot topic was “Loop Engineering.” This concept involves designing an iterative system where AI discovers, executes, verifies, records, and moves on to the next task, rather than humans having to input excellent prompts each time.
However, after running the loop many times, new problems arose.
It’s not that the agents aren’t smart enough, but rather that the organizational structure isn’t clear enough.
An agent can loop through a single task. However, when tasks span product, architecture, data, security, testing, release, cost, and compliance, the real challenge is no longer “getting an agent to try a few more times,” but rather “getting multiple agents with boundaries to work together in an observable, auditable, and recoverable manner.”
Then, a graph appeared.
So, are loops outdated? Should all AI agents be complex graphs of multiple agents?
Graph engineering is about designing the relationships between those processes. The name is new. But most of the hard problems are not.
In other words, graph engineering didn’t invent anything new; rather, it gave a new name to “those long-standing problems in agent orchestration.” These old problems include: how to break down tasks, how to express dependencies, which tasks can be parallelized, how to recover from failures, and where to store state.
What happened after loop engineering?
In loop engineering, we don’t just give instructions to the AI once and then stop there.
Create deliverables, evaluate them, identify problems, fix them and evaluate again.
This iteration continues until a certain quality standard is met.
For example, let’s consider the case where we have AI write articles.
The AI creates articles and reviews its own content. If there are any weak points, it rewrites them, reevaluates them, and continues improving them until they meet the standards.
Here, the only things humans decide are the “purpose” and the “passing criteria.”
On the other hand, the specific steps to reach that point are left to the AI.
This is a loop.
In graphs, humans design the paths.
In graph engineering, humans design not only the objectives and passing criteria, but also the entire path through which the work will proceed.
If the process is the same for article creation, it would follow these steps:
If the quality evaluation does not meet the standards, it will be returned to writing.
If the article’s direction itself is wrong, we’ll go back to the structure creation and research stages.
Unapproved documents cannot proceed to publication.
In other words, in a graph, the AI doesn’t wander around freely, but rather moves within a pre-designed map.
Prompt, Loop, Graph: Three-Tier Engineering
The evolution of Agent engineering can be summarised in three sentences, roughly as follows:
Prompt Engineering makes a single model call more reliable.
Loop engineering makes an agent’s behavior more reliable.
Graph Engineering makes the collaboration of a group of agents more reliable.
The core object of Prompt is an instruction. It cares about what the model sees, in what format it is output, and what it should not do.
The core object of a Loop is the control cycle. You are concerned with triggering conditions, tool calls, state updates, validators, retry strategies, and stopping conditions.
The core object of a Graph is the topology. You are interested in nodes, edges, state, artifacts, permissions, observations, evaluations, and change history.
These three layers are not interchangeable. Graph is not an upgraded wrapper around Loop, and Loop will not disappear because of the introduction of Graph. More precisely:
Each important node may still contain a loop; the graph determines how these loops are organized, constrained, and connected.
If your task only requires a clear loop, such as “scanning repository issues daily, fixing the simplest bugs, running tests, and opening PRs,” then a Loop is sufficient. Adding a Graph too early will only increase complexity.
However, if the task is inherently cross-domain, such as “reconstructing a payment system while ensuring API compatibility, migrating data, updating the front end, completing tests, assessing security risks, and generating release instructions,” a single loop will become a complete mess.
At this point, what you really need to model is not “what the agent will do next”, but rather:
What migration evidence does the data node output?
How API nodes declare compatibility
When can front-end nodes run in parallel?
Which artifacts does the Review node check?
What prerequisites must the release node wait for?
This is already a graph problem.
What makes graph engineering Unique?
Traditional business systems have primarily been built around tabular data.
This method organizes information using rows and columns, such as customer lists, product lists, and sales lists.
Tabular databases are extremely powerful for aggregation and routine processing.
However, the process becomes more complex when dealing with questions like the following.
Who is indirectly connected to this person?
Are there any common patterns that lead to fraudulent transactions?
How far will the impact of a certain failure spread?
How are the pieces of information scattered across multiple documents related?
If this task fails, to what stage should we return to?
These are not issues that can be addressed by looking at a single data point.
This problem involves tracing multiple objects and investigating the meaning of their relationships.
The importance of this relationship is increasing even further with the proliferation of AI agents.
Simply feeding AI a large amount of information does not guarantee that it will be able to make correct decisions.
“Which information is based on which other information?”
“Who approved it, and which steps did it go through?”
“If it fails, where do we go back to?”
By explicitly defining this structure, it becomes easier to control the AI’s decisions.
Don’t graph everything.
When a new concept emerges, there’s a natural urge to apply it to everything.
However, graphs do not solve complexity for free.
OpenAI’s agent building guide also notes that while declarative graphs can visualize branches and loops, they can become cumbersome in dynamic workflows, requiring a dedicated description method.
As an alternative, the OpenAI Agents SDK adopts a code-centric, flexible architecture.
The next task can be handled with a simple loop.
There is one objective.
I use few tools.
There are almost no branches.
No need to resume midway.
If you fail, just go back to the same place.
Humans can verify this in a short amount of time.
On the other hand, when multiple departments, multiple agents, long execution times, parallel processing, approvals, and audits are required, graphing becomes beneficial.
Graph engineering isn’t about creating complex diagrams. Design involves clearly indicating only the necessary relationships and discarding unnecessary automation.
How can current tools achieve this?
This approach already has mature engineering implementations; I’ll pick a few mainstream ones to discuss.
LangGraph
Developed by the LangChain team, it is one of the most mainstream graph engineering frameworks currently available. Its core abstractions are three: Node, Edge, and State.
AI Code Explanation
from langgraph.graph import StateGraph, END
from typing import TypedDict
# Define the global state structure
class AgentState(TypedDict):
task: str
context: list[str]
draft: str
quality_score: float
retry_count: int
# Define each node (each node is a function)
def agent_a_understand(state: AgentState) -> AgentState:
“”“Task understanding: convert user input into a structured task”“”
structured_task = llm.invoke(f”Structure the following task: {state[’task’]}”)
return {”task”: structured_task}
def agent_b_retrieve(state: AgentState) -> AgentState:
“”“Information retrieval: build a context package”“”
context = rag.search(state[”task”], top_k=5)
return {”context”: context, “retry_count”: state.get(”retry_count”, 0)}
def agent_c_generate(state: AgentState) -> AgentState:
“”“Core generation: produce a draft based on the context”“”
draft = llm.invoke(build_prompt(state[”task”], state[”context”]))
return {”draft”: draft}
def agent_d_judge(state: AgentState) -> AgentState:
“”“Quality evaluator: score the draft and determine whether it passes”“”
score = evaluator.score(state[”draft”], state[”task”])
return {
“quality_score”: score,
“retry_count”: state[”retry_count”] + 1
}
# Conditional edge: D’s result determines the next path
def should_retry(state: AgentState) -> str:
if state[”quality_score”] >= 0.85:
return “end” # Passed, finish
if state[”retry_count”] >= 3:
return “end” # Exceeded maximum retries, force stop
return “retry” # Failed, send back for another attempt
# Build the graph
graph = StateGraph(AgentState)
graph.add_node(”understand”, agent_a_understand)
graph.add_node(”retrieve”, agent_b_retrieve)
graph.add_node(”generate”, agent_c_generate)
graph.add_node(”judge”, agent_d_judge)
# Add edges
graph.set_entry_point(”understand”)
graph.add_edge(”understand”, “retrieve”)
graph.add_edge(”retrieve”, “generate”)
graph.add_edge(”generate”, “judge”)
# Conditional edge: judge decides whether to end or retry
# (retry loops back to retrieve)
graph.add_conditional_edges(
“judge”,
should_retry,
{
“end”: END,
“retry”: “retrieve” # Loop back to retrieve on retry
}
)
app = graph.compile()
result = app.invoke({
“task”: “Analyze the risk clauses in this contract”,
“retry_count”: 0
})Several key design features deserve attention:
The global state is the core of the graph. All nodes share the same state object, and the input and output of a node are reading and writing to the state, which solves the problem of data transfer between nodes.
Conditional edges implement branching
add_conditional_edgesby receiving a function that returns the next node to proceed to based on the current state—this is the state transition condition in FSM.The loop is achieved through conditional edges
"retry": "retrieve". This row is the back edge, which allows the graph to return from judge to retrieve, forming a loop.The exit conditions must
retry_count >= 3be clearly defined and be mandatory to prevent a vicious cycle. This is not optional; it must be designed.
My Impression :
Let me be honest about the conclusion regarding the new term itself. It’s only been three days, so no one knows if the term “graph engineering” will survive.
However, the underlying concepts — dividing tasks, running them in parallel, and adding decision checks — have outlived the name, and I’ve seen their effectiveness in my own experience.
Even if the term disappears in a month, the latter half of this article should still be useful. That’s the intention behind writing it.
Source: https://drive.google.com/file/d/1OdGtGSpD2KnR6vrqvFohj0n5gqhH03f5/view
🧙♂️ I am an AI Generative expert! If you want to collaborate on a project, drop an inquiry here or Book a 1-on-1 Consulting Call With Me.