When AI Agent Memories Conflict: Rules for Which Fact Wins

When an AI agent holds two stored facts that disagree, it should not guess or blend them. Give every memory a source, a date and an owner, then apply a written precedence order: authoritative records beat conversation, newer beats older within the same kind of source, and anything still unresolved goes to a named person. Because the rules live outside the model, the agent resolves the same conflict the same way every time.

Key takeaways

• Conflicting memories are normal in any agent that learns over time, so the fix is a rule set, not a cleaner memory.
• Every stored fact needs three labels before it can be compared: where it came from, when it was true, and who is allowed to change it.
• Source authority comes first, date comes second. A newer chat remark rarely overrides an older signed record.
• Some conflicts should never be resolved by the agent. Define which ones go to a human, and send the decision with the evidence.
• Log every resolution so you can review it, and correct the losing memory so the conflict does not return.

Why do AI agent memories conflict in the first place?

An agent that remembers more than one session will eventually remember two versions of the same thing. The causes are ordinary. A client changes a contact person and tells one team member but not another. A policy document is updated while an older copy sits in the knowledge base. Someone mentions a deadline in a chat, and the project plan says something different. The agent saved all of it, faithfully, and now has no basis for choosing.

There is a second cause that is easy to miss: the agent itself writes memories. If it summarizes a conversation and stores the summary, an error in the summary becomes a fact with the same weight as a verified record. Compaction can also drop the qualifier that made a statement true, such as a condition or an expiry. The article on AI context compaction without losing important decisions covers that failure in detail.

Without rules, a language model will pick whichever fact appears more prominent in its context, or the one phrased more confidently. That is not a judgment about truth. It is a side effect of retrieval order and wording, which is why conflict handling should be designed rather than left to chance.

What decides which stored fact wins?

Start with source authority, because a date only means something once you know what kind of statement it dates. A practical precedence order, from strongest to weakest, looks like this:

• System of record: the billing system, the CRM, the scheduling tool, the contract repository. These are the places your company already treats as official.
• Approved documents: policies, price lists and procedures with a named owner and a review date.
• Direct statements from an authorized person, recorded with their role and the date.
• Statements from the counterparty, such as a client, when they concern their own details.
• Agent-written summaries and inferred notes.
• Unattributed content, including pasted text and forwarded messages.

The order will differ between companies, and that is fine. What matters is that it is written down and applied mechanically. The same logic underlies a reliable source of truth for an AI agent: the agent should know which system is authoritative for each type of fact, and treat everything else as supporting evidence.

Two refinements help. First, authority is per field, not per source. The CRM may be authoritative for a client's company name but not for their preferred meeting time, which the client's own latest message may define better. Second, content retrieved from outside your control (a web page, an inbound email) should never outrank internal records. The OWASP Top 10 for LLM Applications describes how untrusted content can manipulate model behavior, and stored memory is one place where that can persist.

How should dates be used to break a tie?

Within the same level of authority, the newer fact usually wins. But dates are trickier than they look, so store at least two of them:

• Effective date: when the fact became true in the real world.
• Recorded date: when the agent or a person stored it.

A client may tell you today that their address changed last month. The recorded date is recent, but the effective date is what decides whether an invoice from last week used the right address. Comparing only recorded dates will sometimes let a late-arriving old fact overwrite a current one.

Add an expiry or review date to any fact that decays. Opening hours, staffing, prices and access rights all change. A fact past its review date should not be deleted automatically, but it should lose ties and trigger a check. The guide on stopping stale context from misleading your agent goes deeper on this.

Finally, define when recency does not win. A newer statement should not replace an older one if it comes from a lower-authority source, if it lacks a named author, or if the change affects something sensitive such as payment details or permissions. In those cases the agent keeps the established fact, flags the discrepancy and asks.

Who owns a fact, and why does ownership matter?

Ownership answers a question that source and date cannot: who has the right to say this is now different. Every memory that can matter to a decision should have an owner, either a person or a role. The owner approves changes, answers when the agent escalates, and is accountable for the record being right.

Ownership also limits who can overwrite what. An employee may be able to tell the agent their own working hours, but not a colleague's. A sales assistant should not be able to alter a finance policy through a casual conversation. This is ordinary authorization thinking, applied to memory writes as well as reads. The OWASP Authorization Cheat Sheet is a useful reference for the principle: check permissions on every request, and deny by default.

Personal and shared memory raise a particular version of the problem. If a team member tells the agent a preference that contradicts a team-wide convention, both can be true: one is personal scope, the other shared. Decide the scope before you decide the winner. The discussion in shared vs personal memory in company agents helps draw that line.

A simple ownership record needs only three fields: the owner, the scope the fact applies to, and the people allowed to propose changes. Without them, the agent cannot tell a legitimate correction from an overreach.

What is a step-by-step plan for resolving a conflict?

Use the same sequence every time, whether the agent runs it automatically or a reviewer follows it by hand.

• Detect: when retrieval returns two facts about the same subject and field, flag them as a conflict instead of passing both to the model silently.
• Check scope: confirm both facts apply to the same client, project, person and time period. Many apparent conflicts are two different truths.
• Compare authority: apply the precedence order. If one source clearly outranks the other, it wins.
• Compare dates: if authority is equal, prefer the later effective date, unless the newer fact is unattributed or the field is sensitive.
• Check ownership: if the winner would change something the proposing party does not own, hold the change and escalate.
• Decide or escalate: if a rule gives a clear answer, use it and log it. If not, ask the owner with both facts, their sources and dates side by side.
• Repair: mark the losing memory as superseded, expired or corrected, so it stops competing. See how to correct, expire or remove agent memory.
• Record: write down what was decided, by which rule, and by whom.

The last two steps are the ones teams skip. Without repair, the same conflict returns in the next session. Without a record, nobody can tell later why the agent behaved as it did. Observability practices, such as those described in the OpenTelemetry primer, apply here: if you cannot see the decision, you cannot review it.

What does this look like in practice? An illustrative scenario

This scenario is illustrative, not a real case. A small services firm uses an agent to prepare client meeting briefs. The CRM lists Dana as the client's main contact. Two weeks ago, a message in a shared inbox said that Lee now handles the project, and the agent stored that note. Today the agent finds both.

The agent checks scope: both facts concern the same client and role. It compares authority: the CRM is a system of record, the stored note is an inferred summary of an email. By the precedence order, the CRM would win, but the note comes from the client's own message, and the client is authoritative about their own staffing. That makes the two roughly equal on the contact field, so the dates decide. The note has a more recent effective date.

However, contact changes affect who receives invoices and sensitive documents, so the firm's rules mark this field as one that needs confirmation. The agent does not switch. It uses Dana in the brief, adds a line saying the contact may have changed, and sends the account owner a short message with both facts, their sources and dates. The owner confirms Lee, updates the CRM, and the agent marks the old entry superseded. The next brief shows Lee.

Notice what the agent did not do: it did not average the two, hide the doubt, or make a permanent change on its own authority.

How does Be Human handle conflicting memories?

Be Human treats conflict resolution as part of the memory design, not an afterthought. In a first engagement we define the role, the memory it needs, and for each type of fact, the authoritative source, the owner and the review interval. Precedence rules and escalation boundaries are written down and approved by the client's team. Under managed operations, conflicts and their resolutions are logged, memory audits review which facts are being superseded most often, and rules are adjusted under human control when the evidence shows a gap. Our memory audit approach describes what such a review covers.

Frequently asked questions

Should the agent always trust the most recent memory? No. Recency is a tiebreaker within the same level of authority, not a rule on its own. A newer remark from an unknown source should not replace an older record from a system of record, especially for sensitive fields.

Can the agent resolve conflicts without a person involved? Yes, for conflicts where your rules give a clear answer, such as a system of record versus a casual note. Anything involving money, permissions, legal commitments or personal data should go to the fact's owner. Start with a narrow automatic scope and widen it as the logs show the rules work.

Do we need a vector database to manage this? Not for this problem specifically. Conflict handling depends on metadata (source, dates, owner, scope) and on rules applied around retrieval, not on a particular storage technology. If you are weighing the infrastructure, do you need a vector database explains when it helps.

How do we find conflicts that already exist? Run a review of the current memory: group entries by subject, look for different values on the same field, and check each against its source. Fix the highest impact ones first, then add the labels and rules so new conflicts are caught as they appear.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.