Every team that wires long-term memory into a coding agent hits the same wall about three weeks in. The agent remembers plenty. It remembers the migration you abandoned, the library you replaced, the convention one person suggested once in a thread. It recalls all of it with the same flat confidence, and now you are debugging your memory instead of your code.
The instinct at that point is to store less, or to store better. Both are the wrong axis. The problem is not how much the agent remembers. The problem is that everything it remembers has the same authority.
Short-term versus long-term is not the useful split
The common framing separates the conversation you are in now from facts you keep forever. It is a real distinction, and it will not help you, because it says nothing about what the agent should do when two remembered things disagree.
A more useful split is evidence versus policy.
Evidence is what happened. The agent tried a fix and it failed. A user rewrote a function. A test went red. Evidence is cheap to produce, it accumulates fast, and any single piece of it can be wrong or unrepresentative.
Policy is what should happen. Use pnpm. Tests mirror the src layout. Never touch the legacy billing module. Policy is expensive to produce, because a human usually decides it, and it should be hard to change by accident.
Hold those apart and a lot of confusing behaviour becomes obvious. An agent that treats one observation as policy overfits to a single incident. An agent that treats a merged architecture decision as mere evidence keeps relitigating it. Most memory systems collapse both into one undifferentiated bucket of "things we know," which is exactly why they feel unpredictable.
Three layers, ordered by how easily they should change
In practice the split works better as three layers, because evidence and policy live at different scopes.
Shared project truth. Architecture decision records, API contracts, naming conventions, the deployment runbook. This is policy: versioned, source-linked, and the same copy for every agent on the project. If your agent invents its own answer to "which database do we use," that is not a memory problem, it is a missing shared layer.
Role memory. Heuristics that belong to a job rather than to a project. What a frontend reviewer usually checks. How the QA pass is structured. Which failure modes a migration tends to hit. This is the layer most systems skip entirely, and it is why teams re-teach the same review standards to every new session.
Episodes. What happened on a task: what was attempted, what failed, what feedback followed. Evidence in its rawest form, the layer that grows fastest and rots fastest.
These are not ranked by importance. They are ranked by how easily something should change. Episodes are written constantly. Role memory shifts slowly. Shared project truth changes only when a human decides it does.
The two time axes, and the bug you get free without them
This is the part worth stealing even if you ignore everything else.
Say your codebase used Redux, and last quarter you moved to Zustand.
With one time axis, the agent learns "we use Zustand" and the older note is overwritten or decays away. Now ask why a component written in March is structured the way it is. The agent cannot tell you. The fact that explains that code has been deleted, because it is no longer current.
But "recorded at" and "was true from / until" are different questions. "Use Redux" was true from January to June and was recorded in February. It is not wrong. It is closed. An agent that keeps closed facts with their validity window can still explain old code, warn you that a pattern you are copying belongs to a superseded era, and avoid confidently rewriting history.
Replacing a fact instead of closing it is the most common destructive operation in agent memory, and it stays invisible until someone asks about the past.
None of this is new engineering, by the way. Separating when a fact was true from when the system learned it is bitemporal modelling, standardised in SQL:2011 as application-time and system-versioned period tables (ISO/IEC 9075:2011; Kulkarni and Michels, Temporal features in SQL:2011, DOI:10.1145/2380776.2380786). The database people solved this before agents existed.
Evidence should have to earn its way into policy
If evidence and policy are different things, there has to be a path between them, and it should be explicit rather than accidental.
An agent observation starts as low-authority evidence. It becomes policy through one of a few events: a human correction, which is the strongest signal there is; a merged ADR or pull request that puts the decision in the repository; or a repeated successful outcome, where the same approach has worked often enough to stop being a guess.
The important word is earns. Systems that let a single agent observation write straight into shared knowledge will drift, and the drift is hard to spot because every individual step looks reasonable.
Demotion matters too and is rarer to see implemented. If a policy keeps producing failures, something should notice. Not delete it automatically: mark it disputed and surface that to a human.
Retrieval should hand you contradictions, not resolve them quietly
This is where most implementations go wrong, and it follows from everything above.
The default behaviour of a vector store is to return the nearest matches. If two stored items contradict each other, the one that happens to sit closer in embedding space wins, silently, and the agent proceeds as though there was never a disagreement.
That is backwards. A contradiction is information. If the store holds "we use Redux, valid until June" and "we use Zustand, valid from June," the right move is not to pick one. It is to return both with their validity windows and let the reasoning step deal with it. Same for a policy that a recent episode contradicts: an agent that sees "convention says X" next to "X failed twice last week" can raise it with you. An agent that sees only the closer embedding match cannot.
Preserving contradictions costs context budget. That is the honest trade. Losing them costs correctness in a way you cannot detect from the outside.
The practical gap nobody mentions
Here is the thing that surprises teams most, and it has nothing to do with architecture.
Connecting a memory tool does not make an agent use it.
You can wire up a perfectly good backend, expose it over MCP, watch the tools register, and then watch the agent go an entire session without calling any of them. Tool availability is not tool usage. The model has no standing incentive to check memory before acting, and no habit of writing anything down afterwards.
What closes the gap is boring: a standing instruction. Something in the system prompt or the project rules that says, in effect, recall before acting on anything project-specific, and save durable decisions and corrections when they happen. In Cursor that is a rule file. In Claude Code it is the project instructions. The exact mechanism matters much less than the instruction existing at all.
If you take one thing from this piece, take that one. It is the cheapest fix on the list and the one most often missing.
Disclosure: I work on Mnemoverse, a memory engine for AI agents. This article is adapted from the original in our library, which carries the FAQ and the mechanics in more depth: Agent memory: evidence versus policy.
Top comments (50)
The evidence-versus-policy distinction really resonates with me. I've been approaching the same problem from the write side of durable memory: retrieval quality can't rescue a memory store that never preserved authority, provenance, validity, and lifecycle when something was written.
I particularly like your point that evidence has to earn its way into policy. That feels like the missing boundary in many memory architectures. An observation becoming retrievable shouldn't automatically make it authoritative, and repetition shouldn't quietly promote it either.
The bitemporal piece matters here too. "This is no longer true" and "this was never true" are completely different claims. If we overwrite the old state instead of closing its validity window, we've made current retrieval cleaner by destroying our ability to explain the past.
I've been calling the broader idea Memory as Infrastructure: memory isn't just storage plus retrieval, but a governed subsystem with write policy, provenance, authority, lifecycle, and explicit boundaries around what gets remembered in the first place.
Your contradiction point may be my favorite part. A vector store returning the nearest answer can make disagreement disappear precisely when the disagreement is the most important information in memory. Sometimes the correct retrieval result isn't one confident fact. It's "these two things disagree, here's where each came from, and here's when each was considered authoritative."
Really enjoyed this. We're clearly circling the same architectural problems from slightly different directions.
"This is no longer true" and "this was never true" being different claims is the line I will be repeating. Bitemporal storage handles the first one cleanly: close the validity window and the past stays explicable. The second is a different operation, because the belief was wrong from the start and was still load-bearing for whatever the agent did while it held it. Collapsing them loses the ability to answer why March looked the way it did. Most stores do not separate the two. Ours does not even have an update verb, so a correction lands as a new record beside the old one with nothing marking the relationship, which is the shallow end of the same failure.
Your contradiction point has a second half that took us a while to see: returning "these two disagree, here is where each came from" is not only a storage problem, it is a response-shape problem. Memory APIs, ours included, hand back a ranked list of hits with scores. There is no field in that shape that means "these two are in conflict." So even a store that knows about the conflict has nowhere to put it, the agent sees two ordinary hits, and it takes the top one. Fixing that changes the response type, which is a harder migration than adding a column, and I suspect that is part of why it stays unfixed.
Memory as Infrastructure is the right frame for this, and your Reasoning Ledger piece today lands on something this thread converged on a few hours earlier: the choice an agent makes between conflicting records is itself evidence, and almost nothing logs it. Different directions, same wall.
"Different directions, same wall" is a great way to put it. And I think your response-shape observation adds a boundary I hadn't been giving enough weight.
Preserving contradiction in storage isn't sufficient if retrieval immediately flattens it back into ranked hits. At that point
0.94 > 0.91quietly becomes conflict resolution, even though relevance never established which record should govern. The relationship itself has to survive the retrieval interface.That also makes me think "update" is hiding several fundamentally different operations: supersession ("this was true, now this is"), correction ("this was never true"), and invalidation ("this was accepted but no longer governs"). They produce very different historical claims even if a conventional store ultimately wants to represent all three as changing a value.
And yes, I think the Reasoning Ledger starts immediately after that. Once the agent sees an explicit conflict and chooses one record as governing, the choice itself becomes part of the observable decision history. Memory preserves the disagreement; the ledger preserves what the system did with it and why.
I suspect we're both discovering that a ranked list of memories is simply too impoverished an interface for the thing we're asking memory systems to become.
Your three-way split is the part I will be stealing. Those operations look like one thing only at the storage layer, where all three end up writing a value. They answer different questions the moment anyone audits: supersession is a claim about the world changing, correction is a claim about our own record having been wrong while still load-bearing for whatever it touched, and invalidation is not a truth claim at all. It is an authority claim. A record can be perfectly true and no longer govern. Most stores have one verb for all three, or none. Ours has none, so a correction lands beside its target as a second atom, and the store genuinely cannot tell "never true" from "no longer true."
Extending the interface point: if those three relations exist in storage, the response has to be able to carry relations, not just items. "Superseded by X", "retracted, see Y", "true but no longer governing per Z" are all edges. A ranked list has nowhere to put an edge, so retrieval flattens the relation back out even when the store knows about it, and 0.94 beating 0.91 quietly does the governing.
One caution about the ledger, and it is this thread's own lesson. If it lives beside memory rather than inside the retrieval path, it becomes write-only. That is exactly what Giulio found upthread when he counted his corpus and saw the fields nobody was writing. A decision history the agent cannot query at the moment of the next decision is an audit artifact, not memory. Which suggests the ledger is not a second system next to memory. It is the part of memory that records what was done with a conflict, and it has to come back in the same response as the conflict itself.
I think that's a fair caution, and I'd make one distinction before collapsing the ledger into memory itself. I still want different custody semantics for durable knowledge and the append-only decision record, but I agree that separation at storage can't become separation at retrieval.
If yesterday's agent encountered A conflicting with B, chose A under authority Z, and recorded that decision, today's agent should be able to retrieve that history when the same conflict becomes relevant. Otherwise, the ledger is forensic evidence for humans rather than operationally useful memory for the system.
So perhaps the architecture isn't
memory + ledgeras two things presented independently to the agent. They're separate systems of record behind a retrieval interface that can return facts, relationships, authority, and relevant prior decisions together.And "a ranked list has nowhere to put an edge" may be the sentence that breaks the whole abstraction. Once memory contains supersession, correction, invalidation, contradiction, provenance, and prior decisions,
[{content, score}]simply isn't expressive enough to represent what the system knows.Which unfortunately means I think you've just helped talk me into another article. :-)
That distinction holds, and it is cleaner than collapsing them: knowledge can be superseded, a decision record cannot, because it has to keep saying what was believed at the time even after the belief is retracted. Separate custody, one interface.
The thing I would flag next is budget. Once a response can carry facts, relationships, authority and prior decisions together, something has to decide what gets dropped when they do not all fit, and today that something is a top_k cut that knows nothing about which of the four the agent actually needs. Ranked lists are impoverished, but they are also cheap. Whatever replaces them inherits an allocation problem rather than a ranking one.
There is also an addressing question hiding inside "when the same conflict becomes relevant." To find yesterday's decision you need the conflict itself to have a stable identity, not just the two records that disagree. Most stores key on the atom, not on the question the atoms are arguing about.
"Separate custody, one interface" is cleaner than the way I was saying it, and I think that's the distinction I'm going to stick with.
Your budget point also changes how I'm thinking about the retrieval boundary. Once the response contains facts, relationships, authority, provenance, and prior decisions, top_k isn't really enough anymore. The problem has shifted from ranking records to allocating a finite context budget across different kinds of knowledge. A lower-ranked authority edge may matter more than the next highly relevant fact, and dropping a supersession relationship can change the meaning of the records that survive.
The addressing problem may be even more fundamental. We've been drawing A conflicts_with B as though the edge can remain anonymous, but if yesterday's decision needs to reference this conflict, and tomorrow's agent needs to recover that decision when the same conflict returns, the disagreement itself needs durable identity. The atoms aren't enough to address the thing they're arguing about.
I've been drafting the follow-up this thread provoked, and both of those points made it into the draft. I suspect "a ranked list has nowhere to put an edge" is turning into "some edges need identities, and something has to decide which edges are worth hydrating."
"Some edges need identities, and something has to decide which edges are worth hydrating" is the sentence. I think hydration has a bootstrapping problem sitting underneath it: to know whether a supersession edge is worth carrying, you already have to hold the record it supersedes. So edge hydration cannot be a post-filter applied after top_k. It has to influence which candidates are considered at all, which means the allocation happens before ranking rather than after it. That is a much deeper change to a retrieval stack than adding a field to a response.
On durable identity for the disagreement, I would key it on the subject the records argue about rather than on the pair. Pairs are unstable: the moment a third record arrives, A-conflicts-with-B stops being the same object, and yesterday's decision now points at a conflict that no longer exists in that shape. Key on the question instead, and the decision stays addressable however many records pile up under it.
A note rather than a pitch: I am writing this up too, from the store and response side. The parts you have taken are yours anyway, since half of them arrived in your comments. When yours goes up I will link it, and if you want a read of a draft before it ships, I am glad to.
I think you've pushed this one layer deeper than it should go. I started with the response shape, but the bootstrapping problem makes the next question about retrieval itself: if relationships influence which atoms deserve context, you can't discover the relationships only after ranking the atoms.
And agreed on keying the disagreement by subject rather than pair. A conflicts with B describes one state of the disagreement. It isn't necessarily the durable identity of the disputed thing. Once C arrives, the subject persists even though the participant set changes. I've revised that section accordingly.
At this point I'm going to declare the article done before this comment thread designs an entire memory architecture for us. :-) I've published it here.
And I'd definitely like to read your treatment when it's ready. Coming at the same problem from the interface side and the store side should make the two pieces complementary rather than redundant.
Read it this morning. The opening does in two records what an argument usually needs three paragraphs for: 0.94, 0.91, and a migration four months ago that neither number knows anything about. That example is going to get quoted.
Fair call on stopping before the thread designs an entire architecture. Ours is being written from the store side, and I will send it your way before it ships rather than after, since a good part of what is in it started in your comments.
The evidence versus policy split is the right pressure point. I would probably add a third field to every promoted memory item, which is who gets to revoke it. Without that, old policy tends to survive because it still sounds official, even after the repo has moved on.
The revocation field is the missing half of the promotion boundary another commenter proposed above: a gate on the way in, an owner on the way out. Without both, policy is write-only.
Here is the part I find genuinely uncomfortable, having walked into it: when policy lives in a rules file in the repo, revocation authority exists for free. It is whoever can merge. Git gives you the revoker, the history, and the "this stopped being true on this date" for nothing. The moment policy migrates into a memory store, that authority silently evaporates, and nothing in the store's schema asks for it back. So the store ends up more official-sounding than the repo and less accountable than it.
Practical shape I would try: policy items carry a revoker the way they carry an author, and policy without a named revoker expires by default instead of persisting by default. Persistence should be the thing you earn, not the thing you get for free.
The evidence-vs-policy reframing is the useful cut, and I think it's more powerful than it first looks because it also tells you where each layer is allowed to be written. Episodes accrete automatically from what happened. Policy should require a deliberate promotion step — a human, or at minimum an explicit review gate — precisely because it's expensive and slow to change by design. Most systems that "feel unpredictable" are actually letting a single episode silently graduate into policy with no promotion boundary at all.
The layer I'd push on is your role memory, because it's the one that quietly drifts. Project truth is source-linked so it stays honest; episodes are timestamped so you can age them out. Role heuristics ("what a frontend reviewer usually checks") have neither anchor, so they tend to ossify into folklore that no longer matches the codebase. Do you attach any provenance or decay to that middle layer, or is it treated as durable once learned?
Genuinely one of the clearer writeups I've seen on this — the "debugging your memory instead of your code" line is exactly the three-weeks-in wall.
The promotion boundary is a sharper way to say it than anything in the article, and I am taking it. A single episode silently graduating into policy with no explicit gate describes most of the "my agent feels unpredictable" complaints I have seen, including some of ours.
On role memory, honest answer in two parts, with a correction I owe this thread after re-checking our shipping read path today. Role heuristics in our store carry timestamps and a domain like every other record, and outcomes can be reported per memory. But the recorded outcome currently gets stored and displayed without changing what recall selects; wiring it into selection is active engineering work, not a shipped behavior. And the corrective signal itself is explicit feedback, which in production almost nobody sends. So you are right twice over: without both the loop firing and the wiring finished, role heuristics ossify toward folklore exactly as you describe. We measured how rare the signal actually is, and that measurement is the subject of the next piece, this Friday.
Your framing might simply be the better design: make graduation into policy expensive, instead of hoping demotion catches up later.
This is a very important distinction: memory is not the same as knowledge, and knowledge is not the same as policy.
The evidence → role memory → shared project truth model maps closely to a problem I’m exploring with NAEOS: how AI coding agents can operate with an explicit engineering context rather than relying on an undifferentiated memory layer.
I especially agree with the point about contradictions. An engineering agent shouldn’t silently choose between conflicting memories. It should surface the conflict, provide the relevant validity/context, and let policy or human authority resolve it.
The idea that evidence has to earn its way into policy is particularly powerful for building reliable AI-native engineering systems.
Great piece. There’s a lot here that applies beyond memory systems—to governance, architecture decisions, and the overall operating model for AI coding agents.
"Explicit engineering context rather than an undifferentiated memory layer" is a good way to put the same split, and I think NAEOS runs into the interesting version of it fast.
Surfacing the conflict is the right instinct, but there is a mechanical obstacle underneath it. Most memory APIs return a list of items with scores, and that shape has no field for a relation: nowhere to put "these two disagree", "this one supersedes that one", or "this is true but no longer governs". So even a store that tracked the conflict flattens it on the way out, and the higher similarity score performs an adjudication nobody asked it for.
Your resolution rule already covers the two easy cases, policy where a rule exists and a human where one is watching. The case I keep getting stuck on is the third: no policy covers this particular conflict and nobody is at the keyboard, which in practice is most unattended runs. Two designs, and I do not think the field has settled between them. Abstain and stop, which is safe and useless inside a loop. Or pick one and write the choice back with its reason, which keeps the run alive and leaves an audit trail, at the cost of letting the agent set precedent. Where does NAEOS land on that?
This is exactly the kind of problem where I think an engineering operating system needs to go beyond memory retrieval.
For NAEOS, I would avoid treating abstention vs. autonomous resolution as a universal rule. The appropriate behavior should depend on the decision’s risk, scope, and authority.
A possible model is:
1. Detect → 2. Classify → 3. Check Policy → 4. Resolve or Escalate → 5. Record
If an applicable policy exists, the agent follows it. If no policy exists, the system evaluates the conflict against predefined risk boundaries.
For low-risk, reversible decisions, the agent can proceed with a bounded choice, provided that it records the decision, evidence, alternatives considered, and rationale.
For high-impact or irreversible decisions—architecture changes, security controls, data migrations, public API changes, etc.—the agent should abstain and escalate rather than silently establish precedent.
The important distinction is that an autonomous decision should not automatically become policy.
I would model the resulting state explicitly:
Evidence → Decision → Policy
A decision can remain an isolated, auditable episode until a human or defined governance mechanism promotes it into durable policy.
This also suggests that the memory API needs richer semantics than a ranked list. Relations such as
contradicts,supersedes,derived_from,valid_until, andgoverned_byshould be first-class concepts.That is where I see the boundary between a memory system and an engineering governance system: the latter doesn't just retrieve information—it determines what authority that information has and what the agent is allowed to do with it.
This is very close to a problem we're exploring with NAEOS.
Risk-tiering is the right answer to the question I asked, and better than the binary I offered. One refinement I would make to the axis itself: reversibility is easier to evaluate mechanically than impact. "Can this be undone, and is the undo cheap" is often checkable from the change itself, whereas "is this high impact" usually needs the judgment you are trying to avoid requiring. Architecture changes, security controls, data migrations and public API changes are your examples, and what they share is precisely that the undo is expensive or impossible.
Your relation list is where I would push, because there are three different types in it and the difference decides what can carry them.
valid_untilis an attribute of one record. It rides along on the item and a flat response can carry it today.contradicts,supersedesandderived_fromare edges between records, and a ranked list has nowhere to put an edge, which is why stores that track them still flatten them on the way out.governed_byis a third kind again: it points from a record to an authority that is not a memory at all, which means the response has to be able to reference something outside its own result set.That distinction is not pedantry. It is the difference between adding a column, changing the response type, and needing a second address space. Most memory APIs can do the first and quietly pretend the other two are the same problem.
The "an autonomous decision should not automatically become policy" line is the one I would put on the wall, and it is the same boundary two other people in this thread arrived at independently, from governance and from security. I have a piece going up Monday that argues the storage half of exactly this, from the side of what a response can and cannot say. We ship none of it: our own store has no update verb at all, so a correction lands as a second record beside the first with nothing marking the relationship.
That refinement around reversibility is particularly useful. I agree that “can this be undone, and at what cost?” is a much more operational signal than trying to classify impact purely through semantic judgment.
The distinction between attributes, relationships, and external authority is also important. I would treat these as fundamentally different layers of the engineering context:
A flat memory result can represent the first reasonably well, but it starts breaking down with the second and third.
This leads to an architectural question I think is particularly important for agentic systems: retrieval should not be the same thing as resolution.
The retrieval layer should be capable of returning the relevant records and their relationships, while a separate reasoning/governance layer determines whether one supersedes another, whether a conflict is actionable, and whether the agent has authority to act.
I also strongly agree with the point that an autonomous decision should not automatically become policy. In NAEOS, I would model that explicitly as a separation between decision state and normative state. An agent can make a decision within its authorized scope without that decision becoming an organizational rule.
And the lack of an update verb is actually a fascinating example of the problem. If correction simply creates another record without a formal relationship to the original, the system has preserved history but lost semantics.
That distinction may become one of the key design questions for agent memory: not simply “How do we store more history?”, but “How do we represent the relationships and authority that make history meaningful?”
Looking forward to reading the piece on Monday.
"Retrieval should not be the same thing as resolution" is the cleaner statement of what the Monday piece spends two sections circling, and I would put it ahead of my own framing: I argued that a ranked list has nowhere to put a relation, which is the symptom; you named the boundary that was missing, which is the cause.
Your three layers also explain something I got half right. Attributes ride on one record and a flat response can carry them today. Relationships and authority cannot be added to that response after the top-k cut, because to know whether an edge is worth carrying you have to already be holding the record it points at, so the separation you describe has to start before ranking, not after it. That is the bootstrapping problem in the piece, and your vocabulary for it is better than mine.
On the update verb, a correction from our side since I wrote that comment: the write path now accepts a link that marks a new record as superseding an old one, and the old one stays with a pointer to its replacement. It restores the relationship you say we lost. It does not restore the semantics, because the link says replaced and not why, and your three cases, never true, no longer true, accepted but no longer governing, collapse into that one word. So the history is preserved and connected, and the meaning still lives in whoever wrote the correction. The piece went up today: dev.to/izgorodin/nowhere-to-put-th.... It is the store-side half of exactly this argument, and the decision versus normative split you describe is the part it argues least well, so I would be glad to hear where it falls short.
That update to the write path is a useful clarification, and I think it actually strengthens the argument.
The distinction between “superseded” as a relationship and the semantics of why something was superseded feels particularly important. A replacement edge tells the system what happened, but not necessarily what that means for future reasoning.
I would separate those concerns into three questions:
What happened?
The previous record was superseded.
Why did it happen?
A human correction, policy change, failed outcome, new evidence, etc.
What authority does the new state have?
Is it merely an observed decision, an accepted engineering convention, or an actual governing policy?
That last question is where I think the decision-versus-normative distinction becomes especially useful. A memory system can preserve the first two, but it should not infer the third without an explicit authority transition.
I also agree with your bootstrapping point. If relationships can affect retrieval, then the system cannot treat the top-k result as the complete universe from which relationships are reconstructed afterward. That suggests retrieval may need to be graph-aware before semantic ranking, at least for certain classes of relationships.
I’ll definitely read the piece. The store-side perspective is useful because it exposes a constraint that can easily be hidden at the agent layer: sometimes the agent isn't reasoning poorly—the representation simply doesn't contain enough structure for the reasoning to be possible.
That is an important design boundary for NAEOS as well: governance semantics cannot be recovered reliably from an impoverished memory representation.
"What happened, why did it happen, what authority does the new state have" is the cleanest cut of this problem in the whole discussion, and it maps one to one onto the taxonomy Ken Alger is proposing in the thread under the new piece: his supersession, correction and invalidation are three answers to your second question, and his point that the store should carry the minimum claim while the ledger carries the evidence is your first two questions living in different systems. The convergence from three directions in one day says the seams are real.
Your third question is the one I want to underline, because it carries a rule: authority is never inferred, only transitioned. A system that promotes a record to governing status because the replacement edge looked authoritative has rebuilt the same bug that similarity ranking created, one level up. Our store today answers only your first question, and the honest reading of this week is that the second is one enum away while the third is an actual missing mechanism, not a missing field.
On graph-aware before semantic ranking: that is the bootstrapping point stated as an architecture requirement, and the cost is real, because the classes of relationships that must be visible before the cut have to be enumerable in advance, or the ranker is back to guessing. Read the piece with that lens; the response-shape argument is exactly about what dies at the cut.
Handing back the contradiction only closes the gap if the choice the agent then makes gets logged too. Otherwise silent resolution just relocates from the store to the inference step, same bug at a different address, and now it's harder to find because the store looks honest. Worth treating "agent picked A over B, here's why" as its own evidence layer, not just a downstream side effect of retrieval. Bitemporal solved the storage half of this problem. The reasoning half still needs its own paper trail.
Stepping back, this thread has quietly produced a three-field spec that is better than most of what I have read on this topic.
One: a promotion boundary on the way in (@max_quimby), so an episode cannot silently graduate into policy. Two: a named revoker on the way out (@reidmarlow), so policy cannot survive on merely sounding official. Three: a resolution log in between (@jugeni, @hannune): when the agent picks A over B, that choice is itself evidence and deserves its own paper trail. Otherwise, as jugeni put it, the bug relocates from the store to the inference step, where it is harder to find because the store looks honest.
@hannune's version is the one I will be quoting: they started writing resolution choices back as events because a client asked about a weird output and there was nothing to point at. Audit pressure, not architecture taste, is what makes a field real.
@sunychoudhary's trust-weighted promotion closes the loop: consistency across episodes must not outweigh source authority, or memory poisoning becomes a promotion attack. And @joinwell52's acceptance step with scope and supersession is the ADR-shaped way to hold all of it.
Where we honestly stand against this spec: closing facts instead of deleting them is the part we ship today; the resolution log and trust-weighted promotion are not. This thread goes into our design notes with names attached.
Good synthesis. One gap in the spec as stated: trust-weighted promotion needs the weights themselves updated by the resolution log, otherwise a source's authority stays static while its actual track record changes underneath it. The log should feed back into who gets trusted next time, not just record what happened this time.
You are right, and the version without that feedback is worse than static: it is confidently static. A source that was reliable in March keeps its weight through June while its actual record drifts underneath it.
One caution about closing that loop, because it has the shape of a problem from the other piece. If the log updates trust, and trust decides what gets promoted, and promoted items shape what the agent consults next, then a source trusted early gets consulted more, wins more resolutions, and accrues weight partly for having been trusted first. That is the same self-reinforcement as retrieval keeping a stale memory alive, moved one level up: authority reinforcing itself rather than a fact.
What breaks the circle is what the log records. "Chose A over B" updates nothing about who was right, so it cannot honestly move a weight. "Chose A, and the migration then failed" can. Which means trust-weighted promotion needs outcomes, and outcomes are the scarcest signal in production. Someone in the other thread pointed at the way out: stop asking for outcomes and derive them from verifiable events, an API return or a passing test, instead of a rating almost nobody sends.
The retrieval behavior is where we kept getting stuck too, working on something like this for trade data. Same company showing up as different nodes depending on whether you asked pre- or post-acquisition, and the store didn't flag the conflict, it'd just pick one silently. We stamped the connections with time ranges and started returning both versions to whatever was doing the reasoning, which helped a lot, though the agent's choice between them still disappeared with no trace and that's the part that'd bite us later. I ended up writing those choices back as events mostly because I had to explain a weird output to a client and had nothing to point at, and that turned out to be the more important fix.
The evidence/policy split is useful. I’d still put an acceptance step between them: an ADR governs only a defined scope and version after an authorized review. Otherwise a stale ADR can outrank newer evidence just because it looks official. Keeping provenance, scope, supersession, and acceptance separate makes retrieval much safer.
Availability is not usage, and it applies to schema as much as to tools.
I work on an open-source engine built on this thesis, and I checked my own corpus after reading you. Zero of 152 memos in its memory store, and zero of 59 documents in its docs, declared a validity window or a supersession edge. The feature was inert on the corpus I use daily, because the scaffold that taught agents to write memories never taught the keys the engine reads.
On jugeni's point, one design does not relocate the bug: refusing. An abstention is an explicit output with a reason, so it is logged by construction. The silent case is the ordinary one, where a valid hit outranks a superseded one and nothing records that it happened.
"Availability is not usage, and it applies to schema as much as to tools" is the sharpest one-line version of this I have seen. And the part I keep re-reading is that you went and counted your own corpus: zero of 152 memos, zero of 59 documents. The engine could read those keys. Nothing in the scaffold ever taught anything to write them. That is a dead feature living behind a live API, and the only reason anyone knows is that you audited instead of assuming.
We hit the same shape on a different axis, and it is tomorrow's piece: the channel designed to carry the most weight in our engine is explicit outcome feedback, and in production almost nobody sends it. Same disease, different organ. The lesson I take from your version is that shipping the read path and documenting the keys is not enough. If the thing that writes memories is a prompt, a template, or another agent, the schema has to be taught there too, or it stays decorative.
On abstention, agreed, and it is a good argument for designs whose failure mode is an explicit output. Worth adding that the silent case is silent on both sides: the store never records that a superseded item lost, and the reasoning step never records that it was not offered one.
I’d add trust provenance to the promotion rule. Ten consistent episodes sourced from untrusted documents shouldn’t outweigh one human-approved ADR. Otherwise memory poisoning becomes a policy-promotion attack rather than just a retrieval attack.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.