Graph Engineering · AI Agents · 2026
The term was born from a 12-word tweet. The pattern is years old. And I already had it recorded, running: the 5 waves of AI engineering, what an agent graph is without the hype, and three live demos with real systems.
The honest verdict
Nobody launched a product, nobody published a framework: one question on X and overnight everyone was talking about graphs. But the name being hype doesn't mean there's nothing underneath. I had this pattern recorded before the word existed — and in this video it's working: three agents routing live, a node failing for lack of state, and seven building a complete IDP on their own.
Over the last few years you were sold five waves, one after another. Three grew roots as a discipline. Two exploded as new names for patterns that already existed. And none killed the previous one: they coexist.
2020-21 → Prompt Engineering ✓ grew roots (absorbed today)
jun 2025 → Context Engineering ✓ grew roots (tweet → discipline)
2025-26 → Harness Engineering ✓ grew roots (the one that matters)
2026 → Loop Engineering ✗ new name, same old bash loop
jul 2026 → "Graph Engineering" ← new name, same old graph2020-2021 · Prompt Engineering
How to write prompts so the model does what you want. It was real — it has academic studies — though today it's been absorbed by the waves that followed. It grew roots.
June 2025 · Context Engineering
Born from a tweet by Tobi Lütke (Shopify's CEO), amplified by Karpathy days later. But this one did grow real roots: managing what enters the model's window ended up with academic review and its own guide from Anthropic. New name, new craft.
2025-2026 · Harness Engineering
The one that makes the difference. Anthropic published its harness work in late 2025, OpenAI in early 2026, and there's a formal taxonomy on MartinFowler.com written by Birgitta Böckeler (Thoughtworks). Three separate fronts pointing at the same place: the environment and controls you build around the agent so it works reliably.
2026 · Loop Engineering
Do you know what's underneath? A bash loop: a cycle that repeats a task and verifies — something that has existed for decades. I made a whole video about it and my verdict was clear: the name is hype, the change underneath is real.
July 2026 · "Graph Engineering"
Born from a 12-word tweet by Peter Steinberger: "are we still talking loops or did we shift to graphs yet?". Nobody launched a product, nobody published a framework. Underneath: execution graphs with nodes, edges and state — LangGraph has been building them since January 2024, cyclic graphs included.
The right bar
The question that actually matters isn't whether the name is new: it's whether that name puts its finger on an engineering problem we didn't know how to separate before. Context, yes. Harness, largely. Loop, less so. And graph, highly debatable: topology, routing, state and orchestration have existed for decades. But the name being hype doesn't mean there's nothing real underneath.
Three pieces. Nothing more.
The units of work. In my demos every node is an agent, though technically it could be a function or even another graph.
The rules that decide which node runs next. They can be fixed (a chain) or decided live based on the task (dynamic routing).
What the system knows while it walks the graph. The most important decision: how one node's output reaches the next.
LOOP → the REPETITION policy
(when something repeats and when it stops)
GRAPH → the TOPOLOGY
(which units exist, how they connect,
which path execution takes)
They're not levels stacked on top of each other: they're
two different things about the same system. A graph can
have loops inside it, and a loop can walk through nodes.This is almost exactly where everyone gets tangled. That's why saying the graph replaced the loop makes no sense: LangGraph put loops inside graphs over two years ago. Watch Loop Engineering ›
If you ever connected two processes so they passed work to each other, you already did some of this. You didn't have the name, but you had the pattern.
Two nodes and an edge. The smallest structure you can already draw as a graph.
Fires a process and leaves a file for the next one. That's state traveling along an edge.
Several connected steps: nodes, edges, state. A graph with a pretty interface.
And notice that this proves the point: if connecting two processes were already graph engineering, then Jenkins, Airflow and every workflow engine have been doing it for decades. The pattern is old, the name is new. The difference is that now you have the name and the map to do it on purpose, not by accident.
When the graph starts doing real work, the key question appears: how does one node's output reach the next? There's no single correct way — the video shows both.
Strategy 1 · A2A demo
The orchestrator sends the task to a node, the node responds, and the orchestrator hands that response to the next one. Node to node, no shared filesystem. That's how the 7 agents run on Cloud Run.
Strategy 2 · IDP demo
Each node writes a file and the next one reads it from disk, like internal APIs. The infrastructure agent doesn't receive parameters: it actively reads what the architect saved.
The rule
What matters isn't where state lives — messages, files or a database: both strategies are graphs. What matters is that each node receives what it needs. Designing what each node needs, who produces it, and what happens if it never arrives: that's the real engineering problem under the name. And no tweet invented it — it's software architecture as it's always been, applied to agents.
Everyone explains graph engineering with drawings. Here there are real agents, talking to each other, without me touching anything. Recorded before the word existed.
An orchestrator with not a single tool of its own: it just reads each agent's card and decides who to delegate to. I ask for DNS records and it routes to the DNS node, which hits the Cloudflare API directly. I ask for a health check and it routes to monitoring. I changed the task and the route changed — the graph picks the path live. That's what a static diagram can never teach you.
I called the security node alone, skipping the chain, without the decisions the previous nodes should have handed it. It was left with its hands tied. And look at why: it didn't fail because of a bug or a bad model — I broke the chain, and with it the condition that node needed to start. That's the real engineering problem under the name: designing what each node needs, who produces it, and what happens if it never arrives.
The easiest graph to reason about: a chain. Architect, infrastructure, security, CI/CD, observability, DevEx and portal. Each node writes a file and the next one reads it from disk — state propagates down the chain without anyone passing variables by hand. Seven nodes, zero clicks. And a confession: with the wrong model, the nodes just kept chatting with each other without executing anything. A graph isn't magic, it's engineering.
The piece almost nobody mentions. The graph decides who works next — but what that node does when its turn comes, that's another layer entirely.
It says who to call: which node is next, along which edge, with what state. The topology of the work.
It decides what that node can do when its turn comes: its tools, its permissions, its sandbox. Its limits.
Why it matters
Because it will execute perfectly logical tasks you never authorized: deleting a table because it was duplicated, rewriting a file because it had an error. The DNS node not being able to delete isn't a polite instruction like "please don't delete" — it's that the delete tool literally doesn't exist. A node's real capability isn't enforced with a prompt: it's enforced in the tools, the permissions and the sandbox. And that — the third wave — is the one that actually changed my work.
I took the full harness apart in another video. Watch Harness Engineering › — and tool-level enforcement, in Agent Skills ›
Is graph engineering the end of the loop, as the viral question suggested? This is the line you take with you — the one you can now say yourself.
LOOP → governs REPETITION (when something repeats)
GRAPH → governs RELATIONSHIPS (and the execution path)
HARNESS → governs the ENVIRONMENT (the controls that make it reliable)
They're not three generations replacing each other.
They're three dimensions of the same system — and all
three can live at once: a graph with loops inside
and a harness around it.The term is hype
Topology, routing, state and orchestration have existed for decades. If someone tells you this was invented this week, they're selling you something.
What's underneath is real
If you know how to build, there's something real: specialized nodes, edges that route, and state that flows. You just saw it running. My bar is the same for everything: I don't sell you the word, I show you the system.
The video's primary sources, verified.
Peter Steinberger · July 18, 2026
The 12-word tweet that made the term explode: 575K views in hours. No product, no framework — just the question.
LangGraph (LangChain) · January 2024
Nodes, edges and state in production long before the tweet — including cyclic graphs: loops inside the graph from day one.
Data Science Dojo · 2026
The article that puts the list on the table: LangGraph, Google ADK, Microsoft Agent Framework — years building nodes, edges and state.
Anthropic · November 2025
Anthropic's harness work: the layer that decides what each node can do when its turn comes. The wave that did grow roots.
Birgitta Böckeler (Thoughtworks) · April 2026
The formalization of the harness: three institutional fronts (Anthropic, OpenAI, Thoughtworks) converging on the same discipline.
Tobi Lütke + Andrej Karpathy · June 2025
Proof that "it came from a tweet" doesn't disqualify: context was born the same way — and grew roots with academic review and an Anthropic guide. The bar is elsewhere.
Every piece of this graph was already shown running in another video. These are the ones in the clips.
The direct prequel: the loop is the repetition policy that lives inside this graph's nodes. My verdict on the previous wave.
The wave that actually matters: the harness decides what each node can do when its turn comes. The graph coordinates, the harness enforces.
The 7 nodes in production: each agent with its own URL and state traveling in messages, node to node.
The demo's IDP: the architect decides the stack and 7 agents build it in a chain, communicating through shared files.
Node enforcement: the delete tool not existing isn't a polite instruction — it's a capability cut out.
Another real graph: 4 Claude instances debate and 3 subagents execute scoped tasks. Team topology.
The essentials on graph engineering.
It's designing the graph your agents run in: which specialized nodes exist, which edges route the work, and what state travels along those edges. The term exploded because of a Peter Steinberger tweet in July 2026, but the pattern — nodes, edges and state — has existed for years: LangGraph has built it since January 2024, and any workflow engine has been doing it for decades.
No, and the question itself is the mistake. The loop is the repetition policy: when an agent repeats something and when it stops. The graph is the topology: which units exist, how they connect, and which path execution takes. They're not levels stacked on top of each other — they're two different things about the same system, so different that a graph can have loops inside it and a loop can walk through several nodes. LangGraph put loops inside graphs over two years ago.
The loop governs repetition: when something repeats. The graph governs relationships and the execution path. And the harness governs the environment and the controls that make all of it reliable. They're not three generations replacing each other: they're three dimensions of the same system, and all three can live at once — a graph with loops inside and a harness around it.
Nobody launched a product or published a framework. On July 18, 2026, Peter Steinberger tweeted "are we still talking loops or did we shift to graphs yet?" — 12 words that amplified a term for an old pattern. The real substrate has been around for years: LangGraph (January 2024), Google ADK and Microsoft Agent Framework were already building agent graphs with nodes, edges and state long before the name.
It's what the system knows while it walks the graph — what each node needs to receive in order to work. And there's no single correct way: it can travel in the messages between agents (like in the A2A demo), live in shared files each node reads and writes (like in the 7-agent IDP), or sit in a database. What matters isn't where it lives: it's that each node receives what it needs. In the video you see a node fail live for exactly that reason.
Structurally, yes: nodes, edges and state you can draw. A cron that leaves a file for the next process is already a graph. And that proves the point: if connecting two processes were graph engineering, workflow engines have been doing it for decades. The difference with an agent graph is that the nodes reason — routing can be decided live based on the task, not just follow a fixed diagram.
It's when the graph picks the path live: the orchestrator looks at the task, reads each available node's card and chooses who to delegate to. The edges already exist; what changes is which one gets taken, and that's decided by the task. In the video's demo, an orchestrator with no tools of its own delegates DNS to the DNS node and health checks to monitoring — change the task and the route changes.
Community
The 7 agents that build the IDP on their own (Google ADK + A2A protocol) and the full pattern so you can run it yourself — step by step, with real repos. Free access to the community; full courses live in the Premium tier.
Join Agentic Engineers →YouTube channel
@NicolasNeiraGarcia
ADK · A2A · Claude Code · Automation · Infrastructure