Your Agent Remembers Everything — Including Every Wrong Answer It Ever Gave

Why this matters

Bolt a vector store onto your agent and call it "memory," and you've built something worse than no memory at all: a system that never forgets — including every time it was wrong. Retrieval doesn't know a fact went stale. It just gets more confident the more times you write the same mistake back into the index.

The incident

An engineer here asked our coding agent why it kept retrying a database migration approach we'd killed two weeks earlier. The answer was the unsettling part. The agent pulled up a memory entry — its own prior output — and cited it: "Based on prior analysis, this migration strategy is preferred because..." That prior analysis was wrong. We'd told it so, at the time. But the correction never got written anywhere the retrieval layer could see, so the wrong answer just sat in the index, semantically neighboring every future question about migrations, waiting for someone to ask again.

What we'd built, and why it looked fine

The setup was standard, which is exactly the problem. Every agent output, every decision rationale, every chat turn got embedded and dropped into a vector store. New task comes in, we pull the top-k similar past entries, stuff them into context. In the demo this looked like magic: ask the agent about a service it touched three weeks back and it "remembers" the naming convention, the auth quirk, why some config value is set the way it is. Everyone in the room — me included — walked out convinced we'd solved memory.

What the demo didn't show: every entry we'd ever written was still in there, undifferentiated. A correct decision and the later-overturned version of it sat side by side, both fully retrievable, both scored on nothing but embedding distance.

The slow degradation

It didn't break on day one. Weeks in, engineers started noticing a pattern: the agent would confidently repeat an approach someone had already shut down in code review. "Didn't we already tell it not to do this?" turned into a recurring line in Slack. And it got worse the more it happened — each repeat of the wrong pattern added another instance of it to the store, so the next retrieval was even more likely to surface it. Five similar embeddings pointing the same wrong way now, instead of one.

The diagnosis

Similarity search answers exactly one question: what looks like this? It has nothing to say about whether that's still true, or whether it got overturned last Tuesday. A vector store has no slot for a correction — a rejection and the thing it rejects are just two more points in embedding space, and if the rejection is phrased differently than the original claim, it might not even land as the nearest neighbor. Retrieval optimizes for relevance-by-resemblance, not relevance-by-currency. Nothing in that architecture ever marks an entry false.

Why this is worse than no memory at all

A stateless agent fails randomly. No memory means it's reasoning from scratch every time — sometimes it lands on the bad approach, sometimes a fresh one, sometimes the right one. An agent with write-only memory fails consistently, because it's stopped reasoning and started citing precedent. And every repeat of the mistake becomes one more citation for the next repeat. That's compounding false reinforcement, and it's strictly worse than noise — noise at least averages out over time. A reinforced false belief gets more confident, not less.

• ▹No memory → errors are independent and roughly random per attempt
• ▹Retrieval-only memory → errors correlate with each other and self-reinforce
• ▹The failure mode isn't "it forgets" — it's "it never revises anything"

The fix we prototyped: a write path with contradiction and expiry

The core change is simple to state and annoying to retrofit: stop treating memory as an append-only index, start treating it as a decision log with state. Every entry gets a status — active, superseded, or rejected — and writing a new decision that contradicts an old one has to explicitly close the old one out, not just add a new competing vector next to it.

entry: {
  id, embedding, content,
  status: active | superseded | rejected,
  supersedes: <entry_id | null>,
  reason: string,       // why it was superseded/rejected
  created_at, resolved_at
}

retrieval rule:
  - default: only return status=active entries
  - if a rejected/superseded entry is the nearest match,
    surface it as "previously tried, rejected: <reason>"
    instead of as a recommendation

That last line in the retrieval rule matters as much as the status field does. A superseded entry doesn't get deleted — it's still useful, just reframed. Instead of the agent quoting its own wrong output as justification, it now says "this was tried and rejected, because X" — which is the guardrail you actually want, not a soft echo of the original mistake.

Setting up Day 9

This changes what "memory" even means for an agent. Not an index you search — a log of decisions with a lifecycle: proposed, active, superseded, rejected. Tomorrow we go deeper on memory-as-decision-log: how to get agents writing to it correctly in the first place, not just how to read from it safely.

Extend your knowledge

• ▹If you're running a vector store for agent memory right now, go audit it: query for a decision you know got reversed later and check whether the old version still comes back.
• ▹Look at how memory modules in LangChain or LlamaIndex handle updates versus inserts. In my experience, most still default to append-only — which is exactly the gap this piece is about.
• ▹Read up on event sourcing and CQRS — state built from an append-only log of events, but with explicit 'superseded' events in the log. The decision-log fix here is that pattern, applied to agent memory.
• ▹Tomorrow (Day 9): memory-as-decision-log in practice — how agents should write to it, not just how to read from it safely.