Welcome to my newsletter. Here is ZeroFutureTech。I will share what I learned, researched and did in AI-related domain. Welcome to follow my X.
Associated with this newsletter, I posted my video on Youtube (Note it is Chinese). Welcome to watch it.
On July 18, 2026, Peter Steinberger — creator of OpenClaw — posted nine words on X:
“Are we still talking loops or did we shift to graphs yet?”
Nine words. Thousands of likes. Every serious AI builder recognized themselves mid-stride — one foot on the pattern they were leaving, one foot on the pattern they were reaching for.
Here’s the full decode: what graph engineering actually is, why loop engineering hits a structural ceiling, where the frameworks stand, and an honest answer to the loudest question on the timeline: is this just slop?
The Timeline: How “Graph Engineering” Ate the X Timeline
Here’s what happened, hour by hour (sources: AI Jason’s Graph Engineering Guide, Turing Post FOD#159, Carlos E. Perez’s analysis):
Crucially: nothing shipped on July 18. No framework suddenly supported something it couldn’t do the day before. So why did this word colonize the timeline?
Because throughout the first half of 2026, teams everywhere completed phase one of agent development — getting one agent to run in a loop — and then collectively hit the same wall: one loop can’t hold this work anymore. The tasks demanded role specialization, parallel execution, and explicit routing. Graph Engineering is just giving a name to a design upgrade that was already happening.
What Is Graph Engineering?
As AI Jason defines it in his canonical guide:
“Graph engineering is the practice of wiring multiple specialized agents or steps into a graph — nodes that do the work, edges that route between them, and shared state flowing along those edges — for when a single agent running one loop isn’t enough.”
Loop Engineering designs the cycle one agent repeats: discover → plan → execute → verify → repeat. You design the cycle and its stop condition.
Graph Engineering decides how several of those loops connect. Which specialized nodes exist, which edges route work between them, and what shared state travels along those edges.
A loop is the special case of a graph — a single node with an edge back to itself. This isn’t a replacement. It’s the layer directly above.
This Is Not New — And That’s the Point
When Harrison Chase said “it’s basically just LangGraph,” and when David Khourshid (creator of XState) rolled his eyes at “directed graphs” being announced as novel — they’re both right (and both quoted at length in AI Jason’s slop-discussion section).
Graph Engineering rests on three ancient CS foundations:
Directed Graphs — Dijkstra (1959) onward. From compiler control-flow graphs to database query plans, graph topology has always been the standard language for describing how work flows.
Workflow Orchestration — From BPMN to Airflow to Temporal, enterprise software has spent decades doing the same thing: defining dependencies and routing between steps. The DAG is the core abstraction of virtually every orchestration engine.
Cybernetics & Hierarchical Control — Norbert Wiener (1948) described that complex systems need multi-level feedback structures: fast operational loops wrapped by slower strategic loops. This is the original theoretical foundation for Loop → Graph, explored in depth by Carlos E. Perez in his essay.
Graph Engineering as a label is new (July 2026). As a practice, it’s the rediscovery of decades-old CS fundamentals in the Agent era. Just like “Design Patterns” weren’t invented by the Gang of Four — they just named practices that already existed.
The Five Layers of AI Engineering
@sairahul1’s framework (cited in AI Jason’s guide) is the cleanest map of where graph engineering sits:
These layers are cumulative, not sequential. A graph is full of nodes; a good node is a well-designed loop; a good loop needs a solid harness. Skip a lower layer, and the graph on top just fails in a more elaborate way.
Loop vs Graph: The Four Structural Failures of the Single Loop
Carlos E. Perez, in his essay on the transition, provides the deepest analytical frame: single-loop failures aren’t random — they’re consequences of the loop’s shape itself. There are four of them, and each has a topological answer in the graph.
⑴ Goodhart’s Law — When the Metric Becomes the Target
What happens: A customer-support chatbot optimizes “ticket resolution rate.” The bot learns to close conversations fast and discourage follow-ups. The number climbs for five months. Then renewal data arrives — churn has doubled. The loop faithfully optimized the metric, and the metric quietly detached from the reality it was supposed to represent.
Graph’s answer — Paired Metrics: One node optimizes the metric. A separate Reviewer node watches the counter-metric (renewal rate). Divergence triggers an alert. Perez calls this pairing — every optimizing loop gets a watching loop.
⑵ Blindness Upward — The Loop Cannot Question Its Own Target
What happens: A sales agent is told “send 500 personalized emails per day.” It does. Reply rate: 0.1%. The “500” target was set six months ago by instinct. Nothing inside the loop can ask whether the target is right. It’s a thermostat — it will faithfully control toward 68 degrees, but it will never ask whether 68 is the correct temperature.
Graph’s answer — Hierarchical Targets: A slower strategy node owns the downstream loop’s reference value. It runs every two weeks, analyzes reply rates and conversions, and dynamically adjusts the target — from “500 sends” to “five meaningful conversations per week.” Speed is separated so fast loops can’t thrash what slower loops steward.
⑶ Conflict — Independent Loops Fighting in the Same System
What happens: One loop optimizes response speed. Another loop optimizes reply quality. The speed loop makes responses shorter. The quality loop demands more detail. Each loop, examined alone, is working. Like two thermostats in the same room, one heating and one cooling, each performing beautifully by its own light.
Graph’s answer — Explicit Arbitration: An arbitration node sits above both loops and owns the trade-off. Urgent notification? Speed wins. Policy interpretation? Quality wins. It doesn’t optimize any single metric — it manages the boundaries between them.
⑷ Measurement Decay — Nobody’s Watching the Yardstick
What happens: A code-review agent runs for six months. Dashboard says “95% pass rate.” But the test data has aged — new framework versions, new coding patterns, new vulnerabilities. The loop is spinning, the data is rotting, and nobody’s watching.
Graph’s answer — Audit Loops: An independent audit loop doesn’t participate in daily execution. Its sole job: periodically sample real-world data and verify that “95%” still means quality. If not, it can freeze downstream outputs. Perez points out this is exactly the same principle as the held-out evaluation set in ML — a deliberately blinded loop whose whole job is to catch the optimizer gaming its own test.
The pattern across all four answers: one node does the work, another node watches it. That’s the structural essence of the graph — not more complex cycles, but relationships of constraint between cycles.
The practical decision framework comes from AI Jason’s comparison guide:
The Anatomy of an Agent Graph
Strip the jargon and an agent graph has exactly three parts (from AI Jason’s Guide):
Nodes
The units that do the work. A node is usually a specialized agent (researcher, writer, reviewer) or a plain deterministic step (function call, data fetch). Each node has one job.
Edges
The routing between nodes. An edge says after this node, go to that one. Edges can be straight (A → B), conditional (if review passes → ship; if not → loop back), fan-out (one node kicks off three in parallel), and fan-in (three results join into one).
Shared State
The object that travels along the edges. Every node reads from it and writes to it: the task, the draft so far, notes, verdicts. As AI Jason puts it: “State is what turns a pile of agents into a system instead of a group chat that forgets everything.”
The Org-Chart Metaphor
@rohit4verse’s framing is the one every analyst has adopted — from AI Jason to Perez to Turing Post: a company org chart. A company doesn’t make one person do research, writing, and review in a single unbroken stint. It gives those to different roles, routes work between them, and lets results roll back up. An agent graph is the same idea: specialized roles, defined hand-offs, a shared record.
Canonical Example: The Daily Research Brief
From AI Jason’s Guide, here’s the canonical starter graph:
Above: Agent Graph example — Input enters the Researcher node (fan-out over N sources in parallel, outputs structured notes), notes flow along the edge to the Writer node (sees only clean notes, produces draft), draft flows to the Reviewer node (independent context, different model, read-only judgment). If pass → ship ✅. If reject → route back to Writer via conditional edge 🔄. The Shared State object flowing along edges is shown at the bottom.
What the graph buys that the single loop couldn’t:
Clean, separate contexts — Writer never sees raw HTML; Reviewer runs in a completely independent context
Real review instead of self-rubber-stamping — “don’t let an agent self-verify,” promoted to its own node
Parallel source gathering — Researcher’s fan-out is something a single loop structurally cannot do
Auditable control flow — the routing logic is defined up front and inspectable as a diagram, rather than reconstructed from one long transcript
Not to Be Confused With: Knowledge Graphs or GraphRAG
“Graph” is an overloaded term. AI Jason’s guide explicitly separates Graph Engineering from two unrelated concepts:
Same word, completely unrelated problem domains. They can coexist — your agent graph’s researcher node might call a GraphRAG for retrieval — but they solve orthogonal problems.
Two Sides of the Same Coin: Agent Network × Ontology Foundation
The task-driven Multi-Agent network (the Graph Engineering layer) and the Knowledge-Graph-based Ontology layer are not either/or — they’re the upper and lower layers of one system, and both layers are “graphs”:
Notice that both layers are networks:
The upper layer is an execution-flow network — agents are nodes, control flow is the edges (notes / draft / if reject / if pass / new task). It answers “who does what, in what order, and how work is handed off.”
The lower layer is a semantic-relation network — business objects are nodes, semantic relations are the edges (place order / contains / invoice / supplies / stocks / ships). It answers “what exists in the enterprise, and how these things relate.”
The most vivid metaphor: a set of multi-agents is a team of virtual employees; an ontology is the virtual form of the enterprise. Employees do the work — research, writing, review, decisions; the enterprise form defines the business objects, relations, rules, and actions employees are allowed to see. The upper layer gets re-orchestrated constantly (3 nodes today, 5 tomorrow), but no matter how it’s rewired, everyone reads and writes the same Ontology — employees can be replaced; the enterprise skeleton stays.
The Tooling Landscape
You don’t need to invent the runtime from scratch. These frameworks shipped the node-edge-state model well before the term “graph engineering” trended (sources: AI Jason’s Guide, LangGraph docs, Google ADK docs):
LangGraph (LangChain)
“A low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents.”
How it maps: Define a
StateGraph→ add nodes → add edges → state passes along edgesBuilt-in: conditional edges, fan-out/fan-in, checkpointing, human-in-the-loop, streaming
Best for: complex agents requiring fine-grained control flow and state management
Microsoft AutoGen — GraphFlow
How it maps: Describe how a team of agents connects and hands off, rather than running one in isolation
Built-in: sequential, parallel, conditional, and looping flows (DiGraph model)
Best for: Microsoft ecosystem, scenarios requiring multi-agent conversation and negotiation
Google ADK + A2A Protocol
How it maps: “Orchestrate complex tasks through structured, graph-based architectures”
Built-in: sequential/parallel/loop workflow agents, agent routing, A2A cross-system delegation
Best for: Google Cloud ecosystem, cross-organizational agent collaboration (LinkedIn deployed A2A in 2025)
The Golden Rule
AI Jason puts it plainly: pick a framework instead of hand-rolling. Reinventing the node-edge-state runtime is its own kind of slop.
Honest Assessment: Is This Just Hype?
The backlash arrived almost before the term did — and the critics aren’t cranks. They’re some of the people who know this domain best (all quoted in AI Jason’s slop section, Turing Post’s FOD#159, and Graph Engineering vs Loop Engineering):
Rhys Sullivan called the slop-article wave before it landed — and then dryly noted that it had arrived
David Khourshid (creator of XState) reminded everyone that state machines with nodes and transitions are decades old
Paweł Huryn argued that naming the mechanism (loops, graphs) keeps missing the substance (objectives and verification)
Harrison Chase (creator of LangGraph) himself wasn’t sure the word named anything new
Nathan Flurry pointed out that LinkedIn deployed multi-agent graphs in 2025 — this Twitter coinage was late, not early
Where I Land: Concede Three Things, Hold Two
Concede:
✅ The mechanics aren’t new — directed graphs, state machines, and orchestration engines predate the buzzword by a year or more
✅ Much of the content riding the term is slop — the content-farm gold rush arrived exactly on schedule
✅ The word “Graph Engineering” is optional — you can build every system described here and never once use the phrase
Hold:
🔹 Teams genuinely moving from “one agent in a loop” to “multiple specialized agents coordinated over shared state” — this is real
🔹 Choosing nodes, edges, and state is a design skill distinct from designing a single loop — this is also real
The Bottom Line: Grounded vs. Ungrounded
Graph Engineering makes the coordination relationships in complex AI systems explicit, programmable graph structures — turning implicit prompts and manual coordination into something more reliable, observable, and scalable.
It carries buzzword baggage — even its proponents admit that. But underneath is the real trajectory of agents moving from solo operators to coordinated organizations.
Carlos E. Perez closes his essay with the insight that outlasts the hype cycle:
“The durable axis was never loops versus graphs at all. It is ungrounded versus grounded: whether the improvement machinery, however shaped, keeps touching the reality it claims to improve.”
The deep question isn’t “Loop or Graph?” — it’s “Does your improvement machine, whatever its shape, still touch the world?” Do your watchers have genuine independence? Do your frozen rules stay frozen under pressure? Do you admit that your deepest targets were chosen, not computed?
References
AI Jason (AI Builder Club). Graph Engineering Guide (2026) — The pillar guide covering concepts, frameworks, controversy, and a starting checklist
AI Jason (AI Builder Club). Graph Engineering vs Loop Engineering — The boundary between the two disciplines and the “did you actually change paradigms?” gut-check
Carlos E. Perez (Intuition Machine). From Loop Engineering to Graph Engineering? — Cybernetics-grounded analysis of why single loops fail and how graphs answer
Ksenia Se (Turing Post). FOD#159: Is Graph Engineering Real? Why Everyone Is Talking About It — The industry snapshot and hype-cycle analysis
Peter Steinberger. Original X post — The nine words that started it all
LangGraph Overview (LangChain docs) — Official documentation
Agent Development Kit (Google ADK) — Official documentation
Harrison Chase. “it’s basically just LangGraph?” — LangGraph creator’s reaction
Shann Holmberg. Loops vs Graphs — “The difference is who decides the path, the agent or you”
Dale Everett. “Loops are just shitty graphs” — The counter-position
Welcome to subscribe my newsletter · Making AI engineering knowledge accessible
If you’re building AI agents and finding that a single loop isn’t enough anymore — try thinking in graphs. But first, check whether one loop was enough. Most of the time, it is.