When Your AI Agent's Memory Disagrees With Your Database, Which One Should Win?

Short answer: decide before it happens. Pick, for each kind of fact, which source is the authority when the two disagree, and the conflict stops being a judgment call your agent makes at 3 AM with no supervision.

Two sources of truth, one confused agent

Picture a scheduled support agent. At 9:00 it runs, checks an order, and stores a memory: "Order 4821 is being processed, customer was told to wait." At 9:05 the warehouse ships the order and the database updates. At 9:30 the agent runs again, the customer asks where their order is, and the agent has two answers in front of it. Its memory says processing. The database says shipped.

It picks one. Whichever it picks, it picks with total confidence, and it never tells you there was a disagreement.

This is not a hallucination problem. The agent invented nothing. Both facts were true at some point. The memory was a snapshot; the database moved on. Every scheduled agent with persistent memory eventually lives in this gap, because memory gets written at run time while the world keeps changing between runs.

Why memory keeps losing these fights

The memory most agents ship with is append-only. A correction gets added next to the original instead of replacing it. One widely-read breakdown of agent memory put it sharply: when the user says the project uses Postgres and later says it migrated to DuckDB, an append-only store ends up holding both facts with no mechanism to decide which one is current. Retrieval picks by similarity, not by temporal validity, and the agent writes code against the wrong database. (https://dev.to/stantyan/why-ai-agents-forget-by-design-4a1l)

Databases solved this decades ago with versioning, timestamps, and constraints. Agent memory stores usually ship with none of that. A deep-dive on the problem counted a corpus of 152 memos and 59 documents and found that zero of them carried a validity window or a supersession marker. The retrieval engine could have read those fields. Nothing was writing them. (https://dev.to/izgorodin/nowhere-to-put-the-disagreement-what-a-memory-store-cannot-tell-your-agent-369l)

So the fight is rigged: the live database has versions and timestamps, the memory has vibes. When they disagree, the agent is guessing.

Decide the hierarchy per fact type, not per conflict

There is no universal winner, and "always trust the database" is wrong too. The database knows the order shipped. It does not know that this customer gets anxious when support mentions delays, or that billing questions for the enterprise tier go to Tier 2 first, or that the price list on the shared drive is the one the sales team actually quotes. Those are exactly the things agents learn across runs, and no system of record holds them.

Split your agent's world into two kinds of facts:

Fast-moving facts belong to the live source. Order status, inventory, prices, ticket assignments. Memory may hold these, but only as a cache, and caches expire. If memory says "in stock" and the fact is three days old, the agent should re-check before acting.

Slow-moving facts belong to memory. Preferences, learned rules, corrections typed in by hand. When the routing rule got corrected in the spring, that correction is the authority, because no database column contains "the routing rule we actually follow."

The hierarchy is a design decision you make once, per fact type, not a judgment call the agent makes per conflict. Write it down and put it in the runbook. Future-you will thank present-you.

Supersede, don't append

When memory gets corrected, the old version has to die on the record. The pattern that keeps showing up in agent-memory engineering: stamp every memory with a validity window, and when a new fact replaces an old one, mark the old one superseded with a link to the new one. The old fact becomes invisible to queries, the new fact is authoritative, and the full history stays queryable for audits.

Append-only memory is where conflicts go to hide. Supersession is where they go to get resolved.

Log the call, or it never happened

The hardest part of a memory conflict is not resolving it. It is knowing one happened. An engineer working on trade data put the principle this way: handing the contradiction back to the agent only closes the gap if the choice the agent then makes gets logged too, because otherwise silent resolution just moves the same bug from the store to the inference step, where it is harder to find.

So write conflict resolutions back as events, not just as updated facts: "memory said X, database said Y, chose Y because order status is a fast-moving fact, at 09:30." The first time a customer asks about a strange output and you have something to point at, that log pays for itself.

The operator's version of all this

You do not need to build any of this from scratch, but you do need to decide it. Once a quarter, pull the three strangest things your agent did and check whether each one was a memory conflict in disguise. Most of the time it was, and the fix was never smarter retrieval. It was deciding which source owns which fact, giving cached facts an expiry date, and making corrections supersede instead of pile up.

And when memory stops being a pile of per-tool notebooks and becomes one shared layer, each conflict only has to be resolved once. Every tool reads the same memory, so every tool gets the same answer. That is the idea behind Vilix AI: one cloud-hosted memory your agents share over MCP, whether the agent runs in an automation platform, on a laptop, or on a phone. It keeps full conversation history, not just extracted facts, so a correction and its context survive together. Vilix AI is free forever, with a 7-day Pro trial and no credit card required, and you can export or delete everything anytime. Get Started for Free