AI Agents Keep Acting on Stale Decisions? The Problem Isn't Retrieval — It's Memory Conflict

Many developers running multiple coding agents in parallel share a common frustration: you've already told the AI you changed the technical approach, yet it keeps acting on outdated decisions. A Reddit developer recently shared a hard-won lesson that cuts right to the heart of this issue — the problem usually isn't in the retrieval step, but in the memory conflict over "who gets the final say."

Retrieval Works Fine — Choosing the Wrong Memory Is the Disaster

This developer was running both Claude Code and Codex on the same project. His memory architecture was a classic semantic search + vector store combo — reliable retrieval by most standards. In his own words: "The retrieval actually works fine. Every time it finds exactly the right memory. It found the wrong one — that's the part nobody warns you about."

Here's what happened: back in August, he told all his agents that the local cache had switched from SQLite to DuckDB. Every agent confirmed and saved the update. Then last week, Codex rebuilt the entire cache layer using SQLite — because it had surfaced a July memory from when he'd originally decided on SQLite.

The key detail: the retrieval system correctly returned both the old and new memories, but the agent chose the older one simply because it was "written more confidently." This exposes a counterintuitive truth — retrieval accuracy and decision correctness are two entirely different things. When a memory store contains contradictory information, perfect retrieval doesn't help you. The real challenge is arbitrating which entry represents the current "truth."

Semantic search paired with a vector store is the dominant architecture for AI memory systems today. Vector stores (like Pinecone, Chroma, or Weaviate) encode text snippets as high-dimensional numerical vectors and retrieve them by computing similarity scores (cosine similarity or Euclidean distance) rather than exact keyword matching. This makes them excellent at fuzzy queries — even if you phrase things differently, semantically similar content still gets surfaced. However, vector similarity fundamentally measures "how alike the content is," not "which entry is more authoritative" or "which is more recent." When multiple contradictory records exist on the same topic, the retrieval system may surface all versions simultaneously with no built-in mechanism to determine which one reflects the current decision. That's precisely the trap this developer fell into: the retrieval system did its job perfectly — the failure happened in the arbitration step that came after.

The 200-Line "Freshness Scorer" That Failed

Faced with this problem, the developer did what most engineers would do: he spent an entire Saturday building a freshness-scoring resolver. Time-weighted scoring, penalties for stale writes, decay curves — the whole works, 200 lines of code he was initially quite proud of.

The system worked exactly once, then quietly broke. The reason was subtle: the "freshness" of a decision and the timestamp of when that memory was "written" are not the same thing. Only he knew this — and the resolver he'd written didn't.

This failure is instructive. When we try to algorithmically arbitrate memory validity, we often fall into the over-engineering trap — trying to get the system to "guess" which information should be trusted, while ignoring that the real context behind a decision is far more complex than a timestamp. In the end, he deleted the entire resolver.

One Store, One Rule: The Newest Explicit Write Wins

Starting over, he landed on a solution almost boring in its simplicity: maintain a single shared store for all tools, with exactly one rule — the newest explicit write wins.

He says it once — "We're not using SQLite anymore, it's DuckDB now" — in one place, and that becomes the single source of truth for every tool. No resolver, no scoring mechanism, no expiry windows. This "deliberately boring" design turned out to be stable and reliable.

He implemented this through Vilix AI's shared memory feature, letting Claude Code, Codex, and Cursor all read from and write to the same store — and he admits that shared infrastructure is the only reason the single-store approach actually works. The solution isn't perfect: "Models are lazy. They won't save things unless I explicitly tell them to, so half my workflow is typing 'save this' like a nagging parent."

"Single Source of Truth" (SSOT) is a classic software engineering architecture principle: any given piece of data has exactly one authoritative source, and all other modules read directly from that source rather than maintaining their own copies. This principle is especially critical in multi-system collaboration — when multiple tools or services each cache the same data, inconsistencies between copies are almost inevitable. Applying this to multi-agent memory systems means abandoning the approach of letting each AI tool maintain its own independent memory store, and instead having all tools read and write to a single shared store. The conflict resolution rule should be as simple as possible: the most recent explicit override wins, with no scoring, no voting, and no semantic inference. This "deliberately boring" design trades flexibility for predictability — and for long-running projects where multiple AIs collaborate, predictability is worth far more than a clever algorithm.

The Core Insight: You're Facing a "Truth Ownership" Problem

The most valuable part of this write-up is how it reframes the problem. As the developer put it: "If your agents are confidently doing old things, your retrieval is probably fine. You don't have a retrieval problem. You have a 'who gets to decide what's true right now' problem."

This framing is highly relevant for anyone building multi-agent systems. As more AI tools run in parallel on a single project, memory consistency and conflict arbitration become harder challenges than retrieval accuracy. Rather than investing engineering effort in complex automatic arbitration algorithms, it's more effective to establish a single source of truth and maintain consistency with the simplest possible rule.

His final advice is blunt and self-deprecating: "Delete the resolver file. I should have done it in June."

For teams building AI memory systems, this lesson is worth keeping in mind: when multiple agents share memory, a simple and explicit "newest write wins" rule consistently outperforms clever but fragile scoring mechanisms. Sometimes the best engineering answer is to be deliberately boring.