Three articles ago I set aside the second meaning of “agent graph” with a promise to come back to it. This is that, and it’s the one where I have to describe something we haven’t finished.
An orchestration graph answers what runs next. A memory graph answers what is connected to what: nodes are entities, meaningpeople, commitments, documents and threads, and edges are typed relations between them. It’s the knowledge-graph-as-agent-memory pattern, and it has become the fashionable answer to the limits of flat retrieval.
The case for it is sound, and it rests on one operation. “Walk from this person to everything two hops out” is a query flat retrieval cannot answer. Not slowly; at all. Vector search finds text that looks similar. A graph finds facts that are related. Those are different operations, and the difference shows up precisely when a question requires connecting two things that never appeared in the same document. Which, in client work, is most of the interesting questions.
Here is the trap. It is easy to build the write half of a memory graph and much harder to build the read half. Typed nodes, an edge table, a linking primitive, a write path that populates it as work happens: that’s a sprint, maybe two. And it feels like progress, because the schema looks like a graph, the entity counts go up, and the diagram you can draw of it is genuinely a diagram of a graph.
Then you need the read half, and the read half is a quarter. You need a traversal primitive, ranking across hops, cycle handling, depth defaults, and a retrieval path an agent will actually reach for instead of falling back to grep. Until that exists, what you have is an annotation scheme wearing a graph’s clothes: a well-structured record of relationships that nothing queries relationally.
I know this because we’re in the middle of that exact gap on an internal system right now. The write half is done and has been for a while. The read half is unfinished. I’m naming it because the failure is neither exotic nor ours alone. It is the default outcome of building a memory graph, and it stays invisible until someone asks a question that needs two hops and gets an answer that only used one.
If you’re building one, four things belong in the read half, and none of them are storage. A traversal primitive exposed as a tool the agent can call, not a query you write by hand when someone asks, because a capability that requires you to be in the room isn’t a capability. A ranking rule for what a two-hop result is worth against a one-hop result, because without one, distance and relevance get conflated and the graph confidently returns the far thing. A default depth, because unbounded traversal returns the whole graph and the whole graph is not an answer. And an eval that proves multi-hop retrieval beats flat retrieval on your actual questions, because if you can’t demonstrate the graph earns its complexity on the queries you really get, you’ve taken on a maintenance burden for a benchmark result.
That last one is the discipline I’d hold hardest, and it’s the same discipline as the QA checklists in the last article. The structure is not the value. The structure is what makes the value verifiable, and if you never run the comparison, you don’t know which side of that you’re on.
Which is where the series lands. Four articles, one argument, three restatements of it. The executable runtime is not the value in an orchestration graph; declared edges, typed gates, and a versioned ledger are, and none of them need a framework. Structure doesn’t buy accuracy. The literature is clear that it sometimes costs accuracy. What it buys is legibility, and legibility is what regulated delivery is actually short of. And a memory graph you can’t traverse is a schema, in the same way that an orchestration engine without a contract is a faster way to produce unverifiable work.
There is one phrase in all of that doing more work than it looks. “Your actual questions” is not a rhetorical flourish. It is the list nobody wrote down. You cannot prove a traversal earns its complexity, or decide which gate is load-bearing, or sequence what to build first, until someone has written down the decisions a function actually makes and the questions those decisions depend on. That inventory is what CDQ produces, and it is why the demand side comes first. The contract is downstream of the questions.
The engine is the part vendors can sell you. The contract is the part you have to write. It has been the whole time.