An agent that can answer questions is one thing. An agent that can answer questions about itself is another.
That distinction became obvious the moment an AI assistant stopped forgetting. Before the change, every conversation started from a flat memory file. After it, the assistant could answer "which standards does this project depend on?" or "what hasn't been updated in 30 days?" — questions that require traversing structure, not searching text.
This is what it actually takes to get there. Not the polished marketing version. The version with the three mistakes that had to happen first.
The setup that didn't work
The assistant already had memory. A flat file with key-value facts. A nightly cron that refreshed it. A search index over past conversations. On paper, this looked like a complete memory system.
It wasn't. The model was fine — the substrate it had to reason over was not. Two concepts appeared in the same memory entry only because someone had typed them in the same paragraph. There were no typed relations between them. There was no way to query a relationship that wasn't explicitly written down.
The pattern that failed: adding more memory. Adding more cron jobs. Adding more search. None of it worked, because the problem wasn't insufficient memory. The problem was no structure in the memory that existed.
The three layers, visualized
Anthropic's 2026 agent materials describe something specific — not a feature, not a product, but an architectural discipline with three layers:
| Layer | What it does | What failure mode it solves |
|---|---|---|
| Harness Engineering | Builds the environment around the model | "The agent can't operate at all" |
| Loop Engineering | Designs work-and-feedback cycles | "The agent is unreliable" |
| Graph Engineering | Makes workflow topology explicit | "The process itself is complex" |
These layers are not interchangeable. A perfect graph won't rescue a weak harness. A strong harness still wastes money without good loops. Clean loops become unmanageable when branching and approvals stay hidden in ad hoc code. All three need to be designed intentionally.
The third layer is the one that's talked about least and matters most.
What graph engineering actually answers
Graph engineering answers a different question from the other two. It doesn't ask what should the agent do?. It asks what is allowed to happen next? The graph becomes the control map.
In a graph-engineered system:
- Steps are nodes
- Transitions are edges
- Branching is explicit
- Parallel work is explicit
- Joins are explicit
- Retries are explicit
- Human interrupts are explicit
A node boundary becomes a design decision: what belongs in a deterministic function, what belongs in a model call, what belongs in a specialist agent, what needs a human review step. A routing condition becomes a contract: what evidence moves the job forward, backward, sideways, or to escalation. Concurrency becomes explicit: what runs in parallel and what must wait.
The hardest part isn't drawing the graph. The hardest part is deciding when not to draw one. Too much structure too early makes a system brittle. The graph earns its cost when the process actually has meaningful branching, approvals, specialist handoffs, parallel paths, or recovery routes. For a single agent with a few tools, a solid harness plus a couple of loops is plenty.
A concrete pattern: the diamond
The workhorse topology for serious agent work is the diamond:
┌──→ Node A ──┐
Split ──┼──→ Node B ──┼──→ Merge
└──→ Node C ──┘
One node splits the work. Many nodes do it in parallel. One node merges the results. The same shape adapts to a market scan, a dependency audit, a code review, a research report. The specifics change. The skeleton holds.
Two details make it robust. First, the fan-out is a barrier — it waits for every parallel task before the merge starts, because the merge genuinely needs the whole set. Second, a task that fails resolves to null instead of poisoning the batch — one flaky execution doesn't sink the run. The merge step filters out the nulls before consolidating.
Why typed edges matter more than the graph itself
A graph where every edge is "mentions" is barely better than a tag system. The real value comes from typed, explicit relations:
entity-A uses entity-Bentity-X is part of entity-Yentity-P supersedes entity-Qentity-R produced entity-S
When edges carry predicates, the graph becomes queryable in a way that flat memory never is. "What depends on this standard?" becomes a traversal, not a grep. "Which findings descend from this experiment?" becomes a query, not a manual trace.
Provenance matters as much as the relation itself. Every edge should know where it came from. A relation with no source is just an assertion. A relation with a source — a document, a run, an evaluation — is auditable. This is what separates a knowledge graph from a fancy string-matching system.
Cycles must converge or they don't run
A counterintuitive lesson: a cycle that doesn't converge is an infinite loop that spends budget until the account is empty. The pattern that converges is loop-until-dry: keep spawning workers until K consecutive rounds surface nothing new, then stop.
The single detail that makes or breaks this — and the mistake almost everyone makes on the first attempt — is what to dedupe against. Dedupe against everything seen, not just against confirmed results. Otherwise rejected findings reappear every round, the loop never dries up, and the system pays to rediscover the same dead ends forever.
This is graph engineering's version of the ratchet loop: every iteration either improves the metric or reverts, and the metric is the only thing that decides.
Routing lives in code, not in prompts
Anthropic's Dynamic Workflows make this explicit: routing decisions live in JavaScript, not in model calls. The model classifies. The code routes. This gives the system Claude's judgment at the node and the script's reliability at the edge.
The benefit is determinism at the boundary. A classifier might be nondeterministic, but the routing that follows is code that runs the same way every time for the same classification. No emergent "the agent decided to skip the audit" surprises — because the skip would have to be written into the graph, and it isn't.
This is also where model tiering becomes free. Routing logic decides which sub-agent runs which model. Repetitive extraction on a cheap model. Synthesis on the expensive one. The shape of the graph doesn't change. The cost does.
The other two layers, briefly
Graph engineering is the layer that's talked about least. The other two matter too.
Harness engineering is the combination of tools the model can use and how well those tools are defined. Two systems with the same model can produce completely different outcomes based on what tools they expose and how narrow those tools are. A harness is not a junk drawer. More tools doesn't mean better agents — it means more selection mistakes, more noisy context, and more ways to fail silently.
Loop engineering designs the work-and-feedback cycles. The most important principle: don't loop on confidence, loop on evidence. "The agent says it's done" is not a stop condition. A real stop condition looks like a test passing, a schema validating, a citation resolving, a reviewer approving. Prompting improves a response. A loop improves a process. Those are different engineering problems.
What broke before it worked
Three failures, in order.
1. Building the graph too early. First attempt: model the entire world upfront — every relevant entity, every relation, every type. The graph became bloated. Most entries were never queried. The interesting ones got buried under noise. Fix: start with a small set of high-value entities, give them explicit relations, and let the graph grow organically from there. Archive anything that goes untouched for 30 days.
2. Letting the same model write and grade. First evaluator: ask the model to introspect on its own graph. It would confidently report "everything looks good" even when entities were stale and backlinks were missing. Self-review shares the same blind spots. Fix: deterministic checks where possible — literal file timestamps, schema validation, grep on expected fields — and separate reviewer context for anything that needs judgment.
3. Treating "keep trying" as a loop. First self-sync pipeline retried failed operations without limits. A flaky network condition could trigger the same retry ten times. Fix: every loop gets a measurable goal, real evidence for success, a retry limit, and an explicit escalation rule. When the budget runs out, return the best current state plus a list of unresolved issues plus a reason for stopping. Never hide partial failure behind a fluent final answer.
What actually changed
Before the graph layer, the assistant could answer questions about the present. After, it could answer questions that require traversing a structure it maintains about its own state.
That's the practical test. If the system can answer "what changed in this graph since last week?", it's operating on the graph, not on cached text. If it can answer "which of these entities haven't been touched recently?", the graph has become a first-class artifact, not a derived afterthought.
The deeper change is philosophical. The agent forgets. The graph does not. Persistence is what separates an assistant that handles a conversation from an assistant that handles a practice — a body of work that accumulates.
The frame worth keeping
If only one thing sticks, let it be this:
Harness engineering makes the model operational. Loop engineering makes the work iterative and verifiable. Graph engineering makes the execution path explicit and controllable.
None replaces the others. All three, designed intentionally, is what turns toy agents into real systems. The graph is the most expensive to build and the most expensive to skip. It's also the layer that, once it's there, makes every other layer better.
The bottleneck is rarely the next model call. It's almost always the placement of memory and evaluation. The graph is what remembering turned out to require.