Update — July 26, 2026: OpenAI harness eng’s two-step recipe — How to graph-max with Codex + GPT-5.6 Sol (draw any graph → code-mode script). Steinberger: “am I a graph engineer now.”
Update — July 20, 2026: The Zen of Parallel Programming — divide, communicate, synchronize before scaling agent orgs.
Update — July 25, 2026: Same week’s Claude 5 stack — context engineering /doctor (80%+ system-prompt cut) and Opus 5 launch. Graphs still need thin durable context. YC’s Fall 2026 RFS also asks for Multiplayer AI — shared live agent sessions as the product.
On July 18, 2026, Peter Steinberger posted six words that quietly declared loop engineering's era over:
"Are we still talking loops or did we shift to graphs yet?"
The tweet hit 575K views in hours. The replies split between confusion and recognition — the same pattern that Peter's June 2026 loop engineering tweet produced six weeks earlier, before "loop engineering" became the dominant AI-developer topic on X.
This time the concept is graph engineering: designing the multi-agent organization as a programmable structure, not just programming one agent's behavior cycle.
Loops made agent behavior programmable. Graphs make agent organizations programmable.
July 26 sketch language: hatched boxes = resident agents; outlines = ephemeral workers. Full how-to: graph-max with Codex + Sol.
The TL;DR
| Concept | What it controls | Key primitive | When it's enough |
|---|---|---|---|
| Prompt engineering | One model response | Instruction text | Static, one-shot tasks |
| Loop engineering | One agent's behavior cycle | Trigger → Act → Verify → Retry | Single-domain autonomous tasks |
| Graph engineering | The organization of multiple agents | Nodes (agents) + edges (dependencies) | Cross-domain, parallel, or evolving work |
| Dynamic Agent Org | Graph structure itself | Self-rewriting graph | Unknown task shapes at runtime |
What the Tweet Actually Asked
Steinberger was not asking an academic question. He was mapping a progression that has been unfolding in production systems since the loop engineering discourse peaked in June 2026.
The progression looks like this:
2022–2024: You prompt the model. Prompt engineering is the skill.
2025–early 2026: You design the loop that prompts the model. Loop engineering is the skill. Boris Cherny's quote — "I don't prompt Claude anymore. I have loops that are running" — defines this stage.
Mid-2026: You design the graph of loops — the organization of agents, each running its own loop, wired to each other by dependencies. Graph engineering is the emerging skill.
The best reply in the thread came from Luis Catacora (@lucatac0):
"Loops are forgiving. Graphs force you to admit how much of the workflow you haven't actually modeled yet."
That sentence is the sharpest distinction between the two paradigms. A loop lets you defer architecture — one agent handles everything until it can't. A graph requires you to declare the structure upfront: who owns what, what depends on what, and what happens when a branch fails.
Loops vs Graphs: A Precise Distinction
What a Loop Is
A loop is an autonomous cycle for a single agent:
- Trigger fires (cron, event,
/loop,/goal) - Agent acts (reads context, uses tools, writes output)
- Verifier checks (tests pass? spec met? human approves?)
- If not done → retry with updated context
- If done → exit
Every guardrail — max iterations, token budget, no-progress detection — applies to one agent's run. The loop is the agent's behavioral contract with itself.
What a Graph Is
A graph is an organization of agents:
┌─────────────────────────────────────────┐
│ WORK GRAPH │
│ │
│ [Planner] ──► [Research Agent] │
│ │ │ │
│ ▼ ▼ │
│ [Writer] ◄──── [Validator] ──► [?] │
│ │ │
│ ▼ │
│ [Publisher] │
└─────────────────────────────────────────┘
Each node is an agent running its own loop. The edges define data flow and dependency. The graph specifies:
- Who exists: which agents, with what specialization
- What each owns: domain, context, tool access
- How work moves: sequentially, in parallel, or conditionally
- What happens on failure: retry the node, route to fallback, alert upstream
The graph is the organization's operating structure. Loops live inside nodes. The graph connects them.
Two Graphs, Not One
Shubham Saboo (@Saboo_Shubham_) — Senior AI PM at Google, author of the Awesome LLM Apps repo (124K+ GitHub stars) — gave the clearest structural breakdown in the thread:
"I was collapsing two layers into one: the long-lived org graph says who owns each zone and preserves context. The work graph says what needs doing now, and can split, merge, reorder, or disappear as evidence arrives."
This is the key architectural insight. Production multi-agent systems actually have two distinct graphs running simultaneously:
The Org Graph (Structural)
The org graph is stable. It defines the permanent organization:
- Long-lived agents with named roles (Researcher, Writer, Validator, Publisher)
- Zone ownership: each agent owns a domain and accumulates context over time
- Preserved memory: agents remember prior work, past decisions, accumulated knowledge
- Stable edges: the dependency structure doesn't change unless you redeploy
The org graph is your company's org chart, except every box is an agent running a continuous loop.
The Work Graph (Dynamic)
The work graph is ephemeral. It defines what's happening right now:
- Task nodes that exist only as long as the work exists
- Dynamic edges that split when parallel paths open, merge when they converge
- Adaptive structure: tasks can disappear when evidence makes them unnecessary, spawn new tasks when complexity is discovered, or reorder when priorities shift
The work graph is your sprint board, except the board rewrites itself as evidence arrives.
ORG GRAPH (stable) WORK GRAPH (dynamic)
──────────────────── ──────────────────────
[Researcher] Task A → Sub-A1
│ → Sub-A2 (new, discovered at runtime)
[Analyst] Task B (merged into A when scope changed)
│ Task C (cancelled — evidence made it moot)
[Writer]
The org graph answers who. The work graph answers what, right now.
Dynamic Agent Orgs: When the Graph Rewrites Itself
The phrase "Dynamic Agent Org" extends the graph concept one step further: the graph's own structure changes while work is happening.
In a static graph, you define nodes and edges at design time and the system runs. In a dynamic agent org, incoming evidence triggers structural changes:
| Trigger | Graph response |
|---|---|
| Task scope expands unexpectedly | Spawn new agent node, wire to existing graph |
| Parallel branches converge early | Collapse merger point, route output forward |
| Agent fails with unrecoverable error | Route to fallback node, flag upstream |
| New data source becomes available | Add tool access to existing node, rerun dependent branches |
| Priority shifts mid-execution | Reorder work graph edges, pause low-priority nodes |
Preston Holmes (@ptone) captured the practical implication: two graphs matter, and they operate at different timescales. The org graph is designed and deployed. The work graph is generated and discarded per task.
This is precisely how Anthropic's multi-agent managed system works at scale — stable agent roles with dynamic task routing between them.
Why Graphs Are Harder Than Loops
Luis Catacora's observation bears repeating: graphs force you to admit how much of your workflow you haven't modeled yet.
A loop is tolerant of ambiguity. The agent figures it out inside the iteration. A graph is not tolerant — you must declare every node, every edge, every failure mode. The graph is explicit architecture.
This creates real costs:
Design overhead. Loops can be sketched in a CLAUDE.md file and run in minutes. Graphs require mapping agents to domains, defining handoff protocols, and specifying what "done" means for each node before the system runs.
Failure surface. When a loop fails, one agent failed. When a node in a graph fails, you need to trace: did the failure propagate? Which downstream nodes received bad input? Is the work graph now in an inconsistent state?
Context leakage. Each agent in the org graph preserves its own context. But context does not automatically flow between nodes — you design the edges that carry it. Missing an edge means a downstream agent acts without information it needed.
The quote circulating in the thread from John Smathers (@risingtidesdev) was satirical but accurate: "YouTube for the next 3 weeks: 'WHY YOU NEED TO BE RUNNING A GRAPH NOT A LOOP.'"
That content wave is coming. What follows is what will actually matter after it does.
What Graph Engineering Looks Like in Practice
Pattern 1: Advisor-Orchestrator (Fable + Sonnet)
explainx.ai's Fable 5 advisor-orchestrator analysis describes the most cost-efficient production graph pattern today:
- Fable 5 as the planner/orchestrator node — reads the full context, routes tasks, provides strategic guidance
- Sonnet 5 worker nodes — execute individual tasks with lower latency and cost
This achieves ~92% of Fable-solo quality at ~63% of the price on SWE-bench Pro. The graph is simple: one orchestrator, many workers, result aggregation node.
Pattern 2: Zone Defense (Long-Lived Specialists)
The org graph pattern closest to current practice: assign each agent to a stable domain with persistent context.
[Security Agent] owns: auth, permissions, audit logs
[Data Agent] owns: schema, migrations, query patterns
[API Agent] owns: endpoints, rate limits, contracts
[Frontend Agent] owns: components, state, UX patterns
Each agent runs a loop within its zone. Cross-zone requests go through the work graph. No agent bleeds into another zone's context.
This is the zone defense framing Shubham described — and it explains why long-lived agents accumulate value over time. A Security Agent that has reviewed 300 PRs knows the codebase's threat model implicitly.
Pattern 3: Multi-LLM Council Deliberation
Council of High Intelligence is an early public graph implementation: 18 agent personas wired through a deliberation protocol, with anti-groupthink gates before the final verdict node. It is a fixed-topology org graph — the nodes don't change, but the work graph (what each agent deliberates on) is dynamic per session.
The Harness Connection
Harness engineering — the infrastructure that wraps agents — becomes more critical, not less, when you move from loops to graphs.
A loop harness manages: prompt input, context window, token budget, retry logic, output capture.
A graph harness manages all of that plus: inter-agent message routing, node failure isolation, state consistency across the work graph, dynamic node spawning, and graph observability (which nodes ran, in what order, with what latency).
The harness for a loop fits in a bash script. The harness for a graph is closer to a distributed systems runtime — which is why LangGraph, CrewAI, and similar frameworks are gaining traction as the discourse shifts from loops to graphs.
What Graph Engineers Actually Build
If loop engineering was the skill for 2025–mid 2026, graph engineering is shaping up as the next layer. Based on the current discourse, practitioners building graph systems are working on:
1. Agent role definitions. What domain does each agent own? What tools can it access? What context does it preserve? This is closer to writing a job description than writing a prompt.
2. Handoff protocols. What format does Agent A emit that Agent B consumes? How does context translate across node boundaries without being repeated in full each time?
3. Work graph generators. Logic that takes an incoming task and produces the work graph — deciding which nodes to spawn, what order to run them in, where parallelism is safe.
4. Graph observability. Tooling to trace which nodes ran, what they produced, where the graph diverged from the plan, and what the wall-clock and token cost was per node.
5. Failure recovery. Rules for what the graph does when a node fails — retry the node, route to a fallback, escalate to a human checkpoint, or abort the branch.
Agent skills become the unit of installation in a graph org — not individual prompts, but packaged capabilities that slot into node slots in the graph.
The Honest Assessment
Karan Singh put it plainly in the thread:
"Sub-agents with a defined purpose is a Graph. But yeah lets confuse everyone and call it a net new thing."
He's not wrong that the underlying concept isn't new — multi-agent systems predate the current discourse by decades. What is new is the accessibility layer: models capable enough to run reliably as autonomous nodes, frameworks mature enough to wire them together, and a practitioner community large enough to develop shared vocabulary.
The "graph engineering" label will almost certainly evolve. But the underlying architectural shift — from programming one agent's behavior to programming the organization of many agents — is real, and it produces systems that single-agent loops cannot replicate.
Loops are subroutines. Graphs are programs.
Related on explainx.ai
July 26 how-to:
Loop engineering (the prior wave):
- What Is Loop Engineering? Beyond Prompt Engineering
- Loop Engineering: How to Design Coding Agent Loops That Run While You Sleep
- Loop Engineering Is Now the Most-Discussed AI Skill on Developer Twitter
- AI Agent Loop Architecture: Triggers, Retries, Checkpoints
Multi-agent systems:
- Zen of parallel programming — sync before scaling agents (Jul 20)
- Anthropic Claude Managed Agents: Multi-Agent Orchestration 2026
- Fable 5 Advisor and Orchestrator Patterns: 92% Quality at 63% Cost
- Council of High Intelligence: 18 AI Personas Deliberate Your Hardest Decisions
- Agent Harness Engineering: Terminal Bench, LangChain Guide 2026
Agent fundamentals:
Specifications and discourse references reflect the state of the conversation on July 18, 2026. Graph engineering tooling and terminology are evolving quickly — check the linked GitHub repos and X threads for updates beyond this publication date.