OpenClaw's Peter really knows how to mock. He was the one who previously proposed that Prompt Engineering is a thing of the past and we are entering the era of Loop Engineering. Recently, he discovered that people have already started hyping Graph Engineering. It feels just like the design patterns back in the day—MVC, MVP, MVVM, MVI—emerging one after another.

Even Turing Award winner Yann LeCun retweeted the discussion on Graph Engineering. So what exactly is driving AI to hype yet another new term? In my view, strictly speaking, this isn't actually a new term; it's just a concept that has been repackaged to give you a sense of FOMO.

In the related discussions, Loop is just the starting point. While workflows implemented through Loops support self-improvement, in real-world scenarios, business workflows should more often be a network (graph) where multiple loops monitor, constrain, and correct each other.

What is a Loop?

We've discussed this before. The purpose of Loop Engineering is to enable task workflows to self-improve through cyclic iteration. This process can essentially be abstracted into the same four-step engine:

• Choose something to control (metric / capability)
• Set a target value (reference / setpoint)
• Measure the gap between the current value and the target
• Take action to close the gap, then repeat

In other words, a Loop is about setting a goal, setting up tests, and then working cyclically. After a weekly evaluation, you adjust the prompt. As long as the business can be measured, it can get better and better within the loop.

Essentially, the shift from Prompt Engineering to Loop Engineering is about programming the 'person who constantly urges the Agent to work,' which is very similar to current long-running tasks or goals.

That is, in terms of engineering, users no longer need to study how to write the perfect prompt in one go. The core shifts to studying what mechanisms can continuously invoke, verify, correct, and stop the Agent.

However, in the current discussion, Loop has four unavoidable problems:

Failure Mode	Essence	Typical Manifestation
Goodhart's Law	When a metric is over-optimized, it eventually ceases to measure what it originally represented, and the loop can only see its metric.	A customer service bot boosts its 'resolution rate' by actually persuading users to leave or marking them as resolved.
Upward Blindness	The loop cannot question whether its own goal is correct.	A thermostat won't doubt if 20°C is a reasonable temperature; an eval loop won't question if a benchmark truly represents user experience.
Loop Conflict	Multiple independent loops fight each other.	Speed loop vs. Quality loop; Growth loop vs. Culture loop.
Measurement Corruption	No one is monitoring the measurement process.	Sensor drift, data pipeline decay, numbers turning into self-congratulatory 'report-to-report' cycles.

You've probably all encountered tasks that drift further off course the longer they run, right? A Loop can judge whether it is approaching a reference value, but it cannot judge whether that reference value is worth pursuing.

That is, when these problems occur, the Loop business flow itself can still appear to be 'running perfectly.' This is why the discussion moves on to Graph.

Graph

So in this discussion, the feeling is that rather than tuning a single Loop, what's needed is a topological structure of loops.

The 'Graph' here refers to analogizing work to a flowchart. You can also think of Graphs as something like n8n, but connecting engines you've developed yourself, such as Codex, Claude Code, etc., allowing you to create 'graphs' or reusable workflows that can be used to execute various tasks.

For example, under a Graph, a relatively complete Agent system might be:

                    Product Goal / Human Owner
                             ↓
                      Task Planning Loop
                     ↙                ↘
            Code Execution Loop      Retrieval Loop
                             ↓
                  Compilation & Test Loop
                             ↓
             Code Review / Security Verification Loop
                ↙                           ↘
         Return for Revision          Human Confirmation
                ↓
          Release & Deployment Loop
                ↓
          Online Monitoring Loop
                ↓
       Product Feedback & Goal Revision Loop

Here, each node is still a Loop internally, but there need to be directed relationships between each Loop:

• Who provides feedback to whom
• Who can veto whom
• Who is responsible for updating goals
• Who is responsible for detecting metric distortion
• Who rolls back after a failure
• Who decides to continue, stop, or escalate to a human
• Which Loops can run in parallel, and which must wait for dependencies to complete

Isn't it clear once put this way? To put it bluntly, it's just a method for multi-Agent orchestration and organization. So this is not a new concept at all; it's just another layer of high-level packaging.

Simply put, the upper-level Graph makes organizational relationships orchestratable and cyclical:

• Nodes represent roles, capabilities, or tasks
• Edges represent handoffs, dependencies, and control relationships

Moreover, in a Graph, different Loops should not run at the same speed. For instance, an Agent system can have four time scales:

• Second-level Loop: Calling tools, reading results, correcting parameters
• Minute-level Loop: Executing tasks, running tests, generating patches
• Hourly or Daily Loop: Batch evaluation, quality analysis, failure attribution
• Weekly or Monthly Loop: Modifying goals, updating metrics, adjusting permissions and system architecture

Fast Loops are responsible for execution, and slow Loops are responsible for judging direction. If you put everything into a single high-speed cycle, the Agent can easily change its strategy based on short-term feedback, ultimately destroying long-term goals.

So a long-running Graph Loop setup should be something like:

• Fast Loop: Increase the number of PR merges
• Slow Loop: Evaluate code quality, online failure rate, and maintenance cost

So in this evaluation system:

• Metrics cannot exist in isolation; they must have counterbalancing metrics
• Goals must have an owner; the execution Loop cannot rewrite them arbitrarily
• Different time scales must be isolated; a fast Loop cannot directly rewrite long-term goals

So strictly speaking, this can no longer be simply called Agent orchestration; it's more about the separation of the control plane and the execution plane in business design.

Therefore, in this discussion, drawing a LangGraph or organizing a very complex workflow diagram is not the main goal. The core lies in business design:

• Who checks if the metrics are trustworthy?
• Who handles conflicts between different goals?
• Who can modify the goals?
• Who has the final veto power?

What the Graph itself can solve is only the structure. The correctness of the goal is the focus of this discussion. How to make goals flow, then undergo sustainable interactive verification, and enable mutual judgment across different time dimensions—that is the key point of the discussion:

The loops are all looking at each other's reports. The audit loop checks the numbers from the operational system, and the operational numbers come from the same system. Ultimately, you still can't escape false metrics.

So a Graph must have anchor points, such as:

• Immutable Reference Values: Money actually received, tests actually passed, customers who actually renewed, physical inventory counts.
• Frozen Nodes: Certain rule optimization loops can never touch, just like a training loop can never touch the held-out set.
• Judgment from Outside the System: The most fundamental question of what 'better' means cannot be generated by the loop network itself. Humans must supply references and judgments through real failure scenarios.

So this is not a technological revolution. Graph is just exploring, on the basis of the past, how to orchestrate business loops and how to make the goals of business loops flow and iterate:

• Which loops can see each other?
• Which evaluations must be strictly isolated from the optimization loop?
• Where do rules need to be frozen?
• Ultimately, how is 'what is good' defined, and can it be modified by the agent itself?

Looking back, none of this is new. It's just packaged with new rhetoric, potentially encompassing:

• Cybernetics and feedback control
• State machines and workflow engines
• CI/CD and automated testing
• Multi-Agent systems
• Hierarchical control systems
• Data plane and control plane
• Organizational management and KPI governance

None of this is new. Or perhaps what you are already doing is Graph Engineering. So there's no need for FOMO. At the current pace, there might be a new term next month. Just treat it as entertainment.