Summary of Key Points
Recently, in the AI Agent community, the focus of discussion has shifted from “Loop (a single-agent closed-loop process)” to “Graph Engineering (multi-role collaboration diagrams).” This isn’t about one new concept replacing the old one; rather, it’s about addressing different challenges. Loop enables a single AI to repeatedly attempt to complete a task (such as writing code or processing fixed work orders), while Graph addresses how multiple AIs, tools, and humans should collaborate effectively. For example, when launching a new feature, Graph ensures that steps like requirement understanding, code modification, testing, and approval are properly handed over, with clear responsibilities for verification and decision-making points. The key issue is that once individual AIs can perform tasks independently, the boundaries of collaboration (permissions, status, validation) become new bottlenecks. Graph Engineering aims to transform these vague rules into actionable agreements, allowing multiple parties to work together smoothly even in uncertain situations.
I. Loop and Graph: From “One Person Working” to “Multiple People Collaborating”
Loop is like one person completing a task independently: receiving the task → using tools → checking the results → retrying if necessary → until completion. For instance, if an AI is asked to write code, it will keep debugging until the code works properly. However, when tasks become more complex (like launching a feature), involving multiple steps like requirement analysis, code modification, testing, risk assessment, and human approval, having one AI handle everything from start to finish can lead to problems:
- All the research materials from the initial phase don’t need to be passed on to the deployment team.
- If the test fails, should the AI fix the code or should a human engineer be involved?
- Who has the authority to click the “production and deployment” button?
Graph Engineering solves these collaboration issues by representing each step (AI, tool, human) as a “node” and using “edges” to define how steps are linked (e.g., testing must pass before moving on to deployment), under what conditions actions must stop (e.g., if risks exceed limits, manual confirmation is required), and what data each node can access. In short, Loop is about one person completing a task in a closed loop, while Graph is about multiple roles collaborating according to established rules.
II. Why Is Graph Becoming Popular Now? The Bottlenecks of Single-Agents Have Become Obvious
It’s not because there have been sudden breakthroughs in graph theory; rather, after making individual AIs capable of working independently, new problems emerged: How do you allocate tasks among multiple AIs? Which step should be revisited if something goes wrong? Who has the final say? These issues cannot be resolved by simply improving the wording of instructions; they are related to the underlying collaboration rules.
Peter Steinberger’s joke, “Are we still talking about Loop, or have we already moved on to Graph?” hits the nail on the head—single AIs can perform tasks, but multiple AIs working together often lead to chaos. Therefore, Graph Engineering has gained popularity as the industry progresses from enabling AIs to do things independently to enabling them to collaborate effectively.
III. Graph and DAG: New Uses for an Old Concept
Graph doesn’t emerge out of nowhere; it’s based on DAG (Directed Acyclic Graphs), a concept from software engineering, such as data processing flows (data collection → cleaning → training → reporting), where each step has a specific order and cannot be reversed. The advantage of DAGs is their predictability and fixed structure, but the downside is their lack of flexibility in looping or branching.
Graphs are more flexible than DAGs because they allow loops (e.g., returning to code modification if a test fails), conditional branching (e.g., automatic deployment if risks are low, manual intervention if risks are high), and the inclusion of human nodes (e.g., approval). Thus, Graphs aren’t “more advanced versions of DAGs”; they’re simply graphs that remove the restrictions of DAGs, making them more suitable for AI collaboration tasks that require flexibility.
IV. The Core of Graph Engineering: Clearly Defining Control to Prevent Chaos
The essence of Graph Engineering is to clearly define the rules of collaboration. Five key aspects need to be designed:
1. Status Recording: Identify which information is shared globally (e.g., task ID, current phase) and which is temporary (e.g., draft research results). Avoid having AIs exchanging messy chat records.
2. Routing Rules: After completing a step, determine who should receive the results. For example, after writing code, send it to the testing node; if the test passes, move it to the deployment node; if it fails, send it back to the coding node.
3. Validation Standards: Don’t rely on AIs claiming they did a good job; use concrete evidence (e.g., test reports, database acknowledgments) for verification.
4. Idempotency Protection: Prevent duplicate actions (e.g., sending an email twice or deducting money twice). Ensure that the same operation always produces the same result.
5. Authorization Boundaries: Define which actions require human confirmation (e.g., data deletion, production and deployment, payment).
If these aspects are not clearly defined, multiple AIs working together can end up simply passing information back and forth, leading to errors.
V. Don’t Use Graph Indiscriminately: Only Use It in Specific Situations
Not all tasks require Graphs. Simple, three-step tasks (e.g., generating daily reports) can be handled more reliably with Loop or regular code. Graphs are needed for scenarios where:
- Tasks need to be divided among multiple parties simultaneously (e.g., simultaneous requirement analysis and data preparation).
- Different steps have different levels of authorization (e.g., deployment requires manager approval).
- There are various ways to handle failures (e.g., retrying for minor errors, seeking human intervention for major issues).
- The task state needs to be preserved (e.g., resuming after interruption).
- The task process needs to be traceable (e.g., understanding why a deployment failed).
How to start implementing Graph Engineering:
1. Identify Failure Paths: List the steps to take in case of errors (e.g., retrying three times after a timeout, then escalating to humans).
2. Structured Status Recording: Maintain a standardized format for task IDs, inputs, current phases, evidence (e.g., test reports), and retry counts for easy tracing.
3. Separate Verification from Side Effects: Use code or system acknowledgments where possible; for irreversible actions (e.g., sending emails), implement idempotency protection and require human intervention.
Conclusion: Don’t Let New Terms Confuse You—the Core is “Designing Clear Boundaries”
The shift from Loop to Graph means that after giving AIs more capabilities, we need to carefully design the boundaries of their collaboration. Loop ensures that AIs can complete tasks, while Graph enables them to work together in an orderly manner. If this trend leads to more discussions about status, validation, and authorization rather than just adding more AIs, then the new term “Graph Engineering” will have been well-deserved.