When an agent's memory misbehaves, the reflex is almost always the same: reach for a better embedding model. Recall is bad? Swap text-embedding-3-small for something larger. It feels like the universal knob.

It isn't. Across the GRAFOMEM benchmark, "memory quality" is not one knob — it's four independent levers, and the embedder only moves one of them. Pull the wrong lever and you'll spend a model upgrade fixing a problem the model was never touching.

One capability, two workloads, opposite results

The cleanest way to see this is to take a single lever and measure it on two different problems.

The lever is SUPERSESSION_CHAIN — the ability to retire an outdated version of a fact so a current query stops competing with stale history. The embedder is held byte-for-byte identical in both runs; the only thing that changes is whether the store can supersede.

The same capability, measured the same way, nearly triples recall on one workload and does literally nothing on the other. That is not a knob with a weak setting — it's a knob wired to a different circuit. Drift is a representation problem; you fix it by being able to represent that a fact was replaced. Distractor confusion is a discrimination problem; supersession has nothing to reshape there, because there's no stale version to retire.

So what does move W3? The embedder — and only the embedder

On the distractor workload, swapping the embedder is the entire game. A real sentence model over a weak lexical baseline recovers +0.510 recall at the same 32-character budget (0.685 vs 0.175). Meanwhile the capability flags — supersession, bi-temporal, deletion — sit flat at +0.000, because the difficulty was never representational. It was: can you tell the right fact apart from three that look almost the same?

This is the counterpoint that makes the point. Capability and embedding quality are complementary, not substitutable: one moves while the other is pinned, and vice versa. If you'd run only W3 — which is what a distractor-style retrieval benchmark effectively does — you'd conclude "memory = embedding quality" and you'd be right about a quarter of the surface and wrong about the rest.

And a third lever the embedder can't touch at all: retention

There's a failure mode where no embedder helps, because the fact you need is no longer in the store. Bound a memory at K entries with FIFO eviction, run a long horizon, and recall falls off a cliff at exactly the moment the needed fact was the (K+1)-th-oldest write. In the benchmark that cliff lands precisely at d = K = 64: perfect recall up to dependency depth 63, zero at 64.

That cliff is structural. It's a property of the eviction policy and how far back the query reaches — not of retrieval quality. A better embedder cannot return a record the store has already discarded. We confirm this by re-running with a deliberately weak lexical embedder: the cliff reproduces at the identical depth. Retention sits upstream of retrieval entirely.

The practical reading: diagnose before you fix

Put the four levers together and you get a decision tree, not a dial:

• Stale or contradictory answers? That's drift. Add a capability — supersession, valid-time — not a bigger model.
• Confusing the right fact with plausible look-alikes? That's discrimination. Now a better embedder is exactly right.
• Running out of room / unaffordable footprint? That's a retention-policy choice, upstream of both.
• Returning data it shouldn't, or hiding data it should? That's an enforcement question — untouched by all three.

Each failure has its own fix, and the fixes don't substitute for each other. The reason this matters commercially: the most common agent-memory comparison varies a single axis and reports an aggregate score. Such a benchmark sees at most a quarter of the surface — and routinely prescribes the wrong remedy with total confidence. "Upgrade the embedder" is the right advice exactly once in four, and the other three times it's a model bill that buys nothing.

Why we can state this so flatly

Two of these separations aren't just observed, they're provable. Retention and privacy outcomes depend only on which records the store admits as candidates — tombstones, tenant tags, capacity — not on how a retriever ranks within that candidate set. So they hold under any embedding function, by construction. The representation-vs-embedding split is empirical but tested the hard way: every structural finding is re-run under both a real sentence model and a bag-of-words stub, and the ones that are byte-identical under both are, by that fact, properties of the store rather than the retriever.

That's the whole argument for treating these as separate axes a system must name separately — and why "make memory better" is not a coherent instruction until you've said which lever.

---

This is the orthogonality result from the GRAFOMEM benchmark. The full paper, the per-budget sweeps, and the reproducible corpus are at grafomem.com; the code is on GitHub.