Graph Engineering Is Just Team Management for AI Agents
On July 18, Peter Steinberger, the author of OpenClaw, asked on X: Is everyone still talking about Loop, or have they already moved on to Graph?
Two days later, Codez wrote a long tutorial, providing a 14-step roadmap for learning Graph Engineering from scratch.
I believe many people's reaction is the same as mine: I haven't even figured out Loop yet, and now we're drawing graphs?
First, a quick note on what Loop is: Loop is a mechanism that lets a single Agent repeatedly self-check and self-correct until the result meets the standard—write it once, check it once, redo it if it's not right, and keep going until it's qualified. It will be used repeatedly as a comparison below.
Image source: Codez's original post
So, I won't go through the 14 terms one by one in this article—the Nodes, Edges, Schema, Router, Fan-out/Fan-in that appear in those 14 steps will all be covered in plain language later. I'll put it in a way that an ordinary person can understand:
Graph Engineering is about dividing work among a group of Agents, specifying how work is handed over, where to check, and when to stop.
First, think of an Agent as a new employee
Suppose you hire a new employee and ask them to write an AI news briefing for you every day.
The simplest approach is to give them all the tasks: find news, read the original articles, verify facts, pick the key points, write the article, and correct typos.
This is the familiar single Agent.
The Prompt is equivalent to the job requirements you give them. Loop is equivalent to them checking after writing, redoing it if they find errors, and continuing until it's qualified.
Simple tasks are no problem, but when things pile up, this employee starts to get overwhelmed. They need to look up materials, remember numbers, and consider the article structure simultaneously. The context they can hold gets fuller and fuller, and they forget earlier things faster and faster.
Graph Engineering does something that everyone should intuitively know how to optimize: Don't let one person do so many things; form a team.
Someone finds materials, someone verifies facts, someone writes the draft, and someone is responsible for finding errors. With a clear division of labor, a finished article is ultimately produced.
Let me clarify a term that's easy to confuse: the Graph Reasoning shown in the diagram is not the same thing as the Graph Engineering discussed in this article. Graph Reasoning leans towards the internal reasoning structure of the model, while Graph Engineering leans towards multi-Agent orchestration at the engineering level. This article is about the latter.
This diagram looks very complex. In fact, most of those small circles and squares below can be understood as different employees and different tasks.
Nodes are employees, Edges are handover slips
The two most important words in a Graph are Node and Edge.
A Node is a node. You can understand it as a position: researcher, translator, fact-checker, writer, reviewer.
An Edge is an edge. It represents the work being handed from one person to another, and what is being handed over.
There's a very easy pitfall here: tasks having a sequence doesn't mean they have a dependency relationship.
For example, if I ask an Agent to summarize this document and then check the weather in Beijing. The weather check doesn't need to wait for the summary to finish; the two tasks can start simultaneously.
Many Agents are slow precisely because of this. All work is written as A → B → C → D, and the next task never starts until the previous one is finished.
Let's take a more intuitive example: B and C both only need the materials provided by A; C does not need B's result. So, after A is done, B and C can be started simultaneously; there's no need for C to wait behind B.
Therefore, the most fundamental capability of Graph Engineering is to see the true dependency relationships between tasks: which tasks need to wait, and which tasks can start simultaneously.
Once tasks can be parallelized, the problem shifts from who waits for whom to how the results are handed over to the next Agent.
For example, after the researcher Agent finishes looking up materials, it only hands back a large block of text. The writing Agent can neither find the original link nor distinguish between facts and conclusions, and has to guess again.
The solution is to specify a fixed format for each handover. For instance, the researcher must return three items: title, original link, and importance level. If one item is missing, the handover is unqualified; only when all are complete does the writing Agent continue working.
Technically, this format rule is called a Schema. You can think of it as a unified handover slip.
Now it's easier to understand Node and Edge: the Node specifies what this Agent is responsible for, and the Edge specifies what data it must hand over to whom. The clearer the handover format, the easier it is for the next Agent to understand.
So, the real difficulty with multi-Agent is writing out in advance the deliverables for each step, how to check them, and what to do if errors occur.
If these rules aren't well-defined, the more Agents there are, the more rework they cause.
The most common graph is actually just a diamond
The most common Graph shape isn't complex.
First, split the task, let several people work on it simultaneously; after they finish, collect the results back, deduplicate, filter; finally, hand it over to one person to produce a unified result.
Take writing this article as an example.
One Agent reads the original X post, one Agent checks the official Anthropic documentation, another Agent looks at how people are recently discussing Graph Engineering. All three sides can start simultaneously.
After the materials come back, duplicate content is removed first, then handed over to the final drafter and reviewer (which is me). So, I don't have to work with a dozen web pages in my head; I just need to get the organized results.
This is Fan-out and Fan-in.
Fan-out is distributing the work out, and Fan-in is collecting the results back. These two actions connected together form the diamond shape below.
It's easy to understand when applied to writing an article: first, let several Agents search for materials simultaneously, then let the program automatically deduplicate and categorize, and finally hand the organized materials to one Agent to form the final conclusion.
The previous Agents have already found the materials simultaneously, and the program has completed deduplication and categorization. But these materials can't be used to write the article directly yet, because they might cite outdated information or treat someone else's retelling as an official conclusion.
So, after the last Agent receives the materials, it needs to do a round of acceptance checks: can the links be opened, do the numbers and dates match up, are there contradictions between different sources? Only after judging can it start writing.
Technically, this role responsible for finding errors is called a Reviewer or Verifier. Its job is not to write another answer, but to check whether the previous answer can be trusted.
But "checking" is not a fixed action; the intensity depends on the importance of the matter.
For an ordinary opinion, letting one Agent do a quick check is enough; when it involves important data, security issues, or product conclusions, several Agents need to be arranged to cross-check from different angles. The role that decides "which checking process this matter should go through" is called a Router. It's like a triage desk, directing tasks to different edges based on their importance.
If the Agent responsible for finding materials says the official source has confirmed it, the verification Agent must find the official original text; if it can only find media retellings, this conclusion must be downgraded, or even sent back for re-investigation. Only content that withstands checking will enter the article.
If the Agent is not searching for materials but modifying code, one more step of isolation is needed: give each Agent an independent workspace. Otherwise, if two people modify the same file simultaneously, the one who saves later might directly overwrite the previous person's work.
If a problem is found during checking and needs to be sent back to the previous Agent for supplementary materials, and then checked again, this forms a loop.
But the loop must specify when to end. For example, stop if no new problems are found for two consecutive rounds; otherwise, it's like a boss constantly shouting "check again," and the Agent will work non-stop, burning tokens continuously.
The whole process, to put it plainly, is: Someone finds materials, someone organizes materials, and someone specifically checks the materials. If the check fails, it's sent back for rework; only after passing is a final conclusion made.
We've been talking about distributing tasks to multiple Agents, but one thing cannot be ignored: every time an Agent is started, it needs to read materials, think, and output an answer independently; these operations all consume tokens.
For example, to write an article, calling ten of the strongest models simultaneously to find materials might indeed be more comprehensive than one model, but it's also equivalent to paying ten times the price to hire ten experts. Parallelism saves waiting time, but it doesn't make these ten people work for free.
The way to save money is not to assign all work to the most expensive model. Extracting titles, organizing formats, and simple classifications can be done by cheaper models; judging the truth of news, handling conflicts, and forming final conclusions should be handed over to more capable models.
This is like an editorial department: organizing materials doesn't always require the editor-in-chief to do it personally; go to them when a real decision is needed.
Besides choosing which model, how tasks are scheduled also affects speed.
For example, if ten pieces of material need to be deduplicated together, you must wait for all ten Agents to return before starting, like a meeting where everyone must be present to move to the next step.
But if each piece of material can be processed individually, you don't need to wait for everyone. Process the first one as soon as it returns, then the second one when it returns, like an assembly line.
So, designing an Agent Graph essentially requires calculating three accounts: how many Agents to start, what model each Agent uses, and which steps must wait for each other.
A well-designed Graph completes tasks faster with less money; a poorly designed one just lets more models burn tokens faster together.
At this point, you might have noticed a problem: a Graph can indeed let multiple Agents work together, but this graph itself still needs someone to design it.
Who searches for materials, who is responsible for verification, which tasks can start simultaneously, which step must wait, and who makes the final conclusion—previously, these rules usually had to be written in advance by the developer.
Claude Code's Dynamic Workflows aim to hand this part of the work over to Claude as well.
Regarding Claude Dynamic Workflows, you can read this article.
You just need to tell it the final goal. Claude will first analyze the task, then generate a JavaScript orchestration script.
Taking writing an article as an example again, it can arrange several Agents to search for original texts, official documents, and external discussions separately; after the materials come back, let the program deduplicate; then call the verification Agent to check sources, and finally hand it over to the writing Agent to output the article.
In Claude Code, you can directly ask it to use a Workflow, or you can run /deep-research. After turning on ultracode, Claude will also first judge whether the current task is complex enough and truly worth starting a group of Agents.
Image source: Anthropic Dynamic Workflows official introduction
There's a very easily misunderstood statement here: the orchestration script can achieve zero model tokens.
What it really means is that management actions like distributing tasks, waiting for results, and merging data are done by ordinary JavaScript, without needing to call the model again. But each Agent that actually goes out to do the work will still consume tokens normally.
To put it bluntly, the scheduler doesn't get a salary, but that doesn't mean the employees on the schedule don't get paid either.
As of July 2026, the upper limit given by Claude's official documentation is running 16 Agents simultaneously, with a single Workflow capable of starting up to 1,000 Agents (see Claude Code Docs). This represents the system's capacity for large tasks, not that ordinary tasks should also max out the headcount.
The diagram below is the complete process assembled at the end of the original text.
At first glance, it looks densely packed, but when broken down, it's still the few things mentioned earlier: first determine the task scope, then search for materials separately; hand over using a fixed format, organize using a program; arrange Agents for verification, and finally form a conclusion; the entire process must also control stop conditions and costs.
Claude can now automatically generate this process, but three questions still need to be checked: whether the task breakdown is reasonable, whether verification is in place where it should be, and whether starting so many Agents is worth it. In other words, we don't necessarily have to draw every node ourselves, but we still need to judge whether the division of labor arranged by Claude can truly complete the task.
Seeing this, a beginner doesn't need to immediately install a Graph framework, let alone arrange a dozen Agents for every task.
If it's just summarizing a PDF or modifying a title, handing it to one Agent to do from start to finish is usually faster and cheaper. Forcing a breakdown into a graph just to look advanced only increases waiting, handover, and the chance of errors.
A Graph becomes truly useful when a task starts showing these signs: several pieces of work can be done simultaneously; one Agent can no longer keep track of everything; results must undergo independent checking; the entire process will be executed repeatedly many times.
If you really want to start, you can begin with the simplest step. First, let one Agent complete the entire task, find the slowest or most error-prone link; then break out a branch that can be parallelized; when you're genuinely worried the answer is unreliable, add a verification Agent. After the process stabilizes, finally consider frameworks and automatic orchestration.
Ultimately, Loop solves how one Agent works repeatedly until the job is done; Graph solves how multiple Agents divide work, hand over, check, and avoid burning tokens for nothing.
The Graph is not the point. Why each arrow in the Graph exists is the real problem Graph Engineering aims to solve.