From Harness to Graph: The Fourth Era of Working With AI¶
A few months ago I wrote about harness engineering: the discipline of building constraints and feedback loops around an agent so it stops making the same mistake twice. I closed that post with a line I meant sincerely: harness engineering is early, and it's just getting started. I didn't expect "started" to mean four months.
Here's what actually happened. Teams that got good at harnessing one agent did the obvious next thing: they ran three. A coding agent, a review agent, a deploy-gate agent, each one solid on its own, each one running its own loop. And then they hit a wall the harness was never built for. Nobody told the review agent it wasn't the one deciding whether to merge. Two agents grabbed the same file at the same time, and each one thought it owned the fix. The harness caught every mistake it was designed to catch. It caught none of these, because these aren't reliability problems. They're coordination problems.
The line that's going around
A post from July 2026 put it in one sentence that stuck: "Loop engineering was the last unlock. Graph engineering is the next one. Agents are graduating from while-loops to org charts." Anthropic's own multi-agent research architecture backs it with a number: a lead agent delegating to parallel sub-agents beat a single agent by 90.2% on their internal research eval.
If prompt, context, and harness were the first three eras of working with AI, this is the fourth one: graph engineering.
Why the Harness Wasn't the End of the Story¶
Go back to the harness post and there's a line I tossed off almost as a footnote: agents running in parallel need to understand what they own, and the harness manages that through file locks and task ownership so agents don't collide. At the time that felt like a detail. It's not. It's the whole next problem.
A harness makes one agent trustworthy. It tells that agent what it can't do, checks its work before the next step runs, and stops the same mistake from happening twice. None of that tells you which of your five agents should be running right now, what each one is allowed to see, or what happens when the "fix the bug" agent and the "write the migration" agent each decide, correctly by their own rules, to touch the same file. That's not a harness failing. That's a harness doing exactly what it was built for, on a problem it was never built for.
This isn't a replacement for the harness
Every agent in a graph or behind a supervisor still needs its own harness, its own constraints, its own feedback loops. Graph engineering sits on top of that layer. It doesn't remove the need for it.
The Three Shapes: Loop, Boss, and Graph¶
Most agent systems in production right now are still running the first shape: the loop. One agent, ReAct-style (observe, think, act, repeat) until the task is done. This is what your harness was built around, and it's still the right shape for a huge share of work. If the task is genuinely one agent's job, don't reach for anything fancier.
The second shape is the supervisor pattern, and people have started calling it "the boss" because that's exactly what it is. A dispatcher agent looks at an incoming request and routes it to a specialist sub-agent with its own tools and its own rubric. This isn't exotic — it's already running at real scale. One production example: a triage agent classifying roughly 2,000 alerts a day across Splunk, Datadog, and PagerDuty, routing critical ones to on-call specialists at around 94% accuracy. That's a boss pattern doing unglamorous, high-volume work, and it's probably the shape most "multi-agent" systems you've heard about actually are.
The third shape is graph engineering, and it's the explicit version of what the supervisor pattern does implicitly. Instead of a dispatcher making a routing call at runtime, you declare the topology up front: named nodes (agents and deterministic steps alike) connected by named edges, with a shared state schema flowing between them. Cycles and conditional branches are part of the design, not something that emerges from a pile of function calls after the fact. The org chart exists before anyone shows up for work.
# placeholder — a graph definition sketch: named nodes (agent or
# deterministic), edges with routing conditions, and the state
# schema that travels along them
nodes:
- id: intake
type: agent
role: classify-request
- id: fix-bug
type: agent
role: implement-fix
- id: run-tests
type: deterministic
role: verify
- id: human-review
type: human
edges:
- from: intake
to: fix-bug
when: classification == "bug"
- from: fix-bug
to: run-tests
- from: run-tests
to: human-review
when: tests == "pass"
- from: run-tests
to: fix-bug
when: tests == "fail"
state:
schema: { request_id: string, classification: string, diff: string, test_result: string }
The tell that you don't actually have a graph
If you can't draw your multi-agent system as a diagram before it runs — nodes, edges, conditions, all of it — you don't have graph engineering. You have a loop with extra steps and a routing function nobody's written down.
The intake -> fix-bug -> run-tests -> human-review graph above, including the capped retry edge, isn't just a YAML sketch. It's a runnable example.
See it running
Three dependency-free Python scripts in the ai-capabilities repo show the same request handled as a loop, a supervisor, and a graph, plus a GRAPH.md-style declared-topology artifact with a topology change review table.
What Changes When You Design the Graph Instead of Discovering It¶
The practical shift is bigger than the diagram. When the topology is declared instead of emergent, it becomes something you can review in a pull request the same way you'd review a Terraform plan or an ArgoCD Application manifest, before it runs instead of after it breaks something in production. State that travels along an edge needs a schema, the same discipline you'd already apply to an event payload passed between two services.
Failure modes shift too, and this is the part platform teams will appreciate fastest. Instead of "the agents went back and forth for ten minutes and I have no idea why," you get "node fix-bug threw on the third pass through the retry edge, here's the state it was carrying." That's debuggable in the same way a stuck Argo Workflow is debuggable: you look at the node, you look at the edge it took, you look at what it was holding when it failed. Compare that to debugging a loop-based agent by reading a wall of transcript and guessing where it went sideways.
Apply this to your next multi-agent build
Before you write a single agent prompt, draw the graph. Name every node. Name every edge and the condition that triggers it. Define the state schema that crosses each edge. If you can't do that on a whiteboard in fifteen minutes, the system isn't ready to build yet — the ambiguity you'd be encoding into agent behavior is ambiguity you can catch on the whiteboard instead.
Where This Fits Your GitOps Mental Model¶
If you've been doing platform work for a while, none of this should feel foreign. You already think in declared topology — an ArgoCD Application graph, a Crossplane composition, a Gateway API HTTPRoute tree. You declare the shape, you version it, you diff it, you review it before it ships. Graph engineering is asking you to apply exactly that discipline to agents instead of infrastructure.
It also means drift becomes a real concept for agent systems, not just clusters. A node that silently takes a different edge than the graph declares, because a model call resolved differently than expected or because someone hand-patched a running system, is drift in the same sense a cluster silently diverging from its manifest is drift. If you've already built drift detection into your GitOps pipeline, the same instinct applies here: the graph is the source of truth, and anything that deviates from it at runtime should be visible, not silent.
This is also where the harness stops being optional and starts being load-bearing at a different layer. Every node in the graph is still an agent that needs its own constraints and feedback loops. The graph tells you who talks to whom. The harness tells each one how to behave once it's talking.
FAQ¶
Is graph engineering just LangGraph marketing?
LangGraph popularized the graph-as-state-machine framing and it's a legitimate reference implementation, but the idea is bigger than one library. The core claim is simple: declare your topology instead of discovering it at runtime. That applies whether you're using LangGraph, a hand-rolled state machine, or something you built on top of Temporal.
Do I need to throw out my harness to adopt this?
No. The harness and the graph solve different problems and you need both. The harness makes each individual agent reliable. The graph makes the relationships between agents explicit. Neither replaces the other.
Where does the supervisor pattern fit if I already have a graph?
A supervisor is a specific kind of node in a graph, usually the one that does the classification-and-routing work at the top. Graph engineering doesn't retire the boss pattern, it gives it a formal place in a larger, explicitly designed system instead of leaving it as the whole architecture.
Is this only relevant for coding agents?
No — the triage example in this post is an ops/observability system, not a coding agent. Anywhere you have more than one agent working related tasks with any dependency between them, the coordination problem this solves shows up.
How do I know if my team should adopt this now, or focus on the harness first?
If you're still seeing agents make the same category of mistake more than once, fix that first — that's a harness gap, and a graph won't paper over it. Reach for graph engineering once your individual agents are reliable enough that the failures you're seeing are about coordination, not competence.
Harness engineering taught us to stop trusting an agent to behave and start engineering the environment that makes good behavior the only option. Graph engineering is the same move, one layer up: stop trusting a pile of agents to sort out who does what, and design the org chart on purpose. Prompt, context, harness, graph — four eras in about three years. I wouldn't bet on graph being the last one either.
The July 2026 "loop engineering was the last unlock" framing and the supervisor-as-"boss" naming are both credited to posts and threads cited in the sources below; treat this as an emerging vocabulary, not a settled standard — it'll keep shifting.
For more on the layer underneath this one, see From Prompt to Harness: The Three Eras of Working With AI. For the GitOps-side analogy to drift in agent graphs, see GitOps AI Drift Detection.