March 25, 2026
By David Szarzynski · Founding Engineer
Your agent tells a customer that Project X was cancelled last week. The customer is confused. Project X is active and on track. What happened? The agent retrieved a real Slack message from a team lead who floated the possibility of cancellation. But the project management tool shows the project as active. Two real sources, two conflicting facts, one confident wrong answer.
This is not a hallucination problem. It is a data consistency problem, and it gets worse as agents connect to more sources. A recent survey of memory in the age of AI agents identifies trustworthiness as one of the core open challenges for agent memory systems.
This guide covers why conflicts happen, how they surface as failures, and the patterns that handle them.
Memory conflict occurs when an agent's memory contains contradictory information about the same entity, sourced from different tools or timestamps.
The distinction from hallucination matters. Hallucination is the model generating information it was never given. Memory conflict occurs when the model is given genuinely contradictory data. A Slack message says "meeting cancelled." The calendar still shows it as active. Both are real. The agent must decide which to trust. Most agents have no mechanism for that decision.
Property | Hallucination | Memory Conflict |
|---|---|---|
Data source | No source; model-generated | Multiple real sources |
Root cause | Model generates unsupported claims | Genuinely contradictory data in memory |
Fix | Better grounding and retrieval | Conflict detection and resolution logic |
Detection | Fact-checking against sources | Cross-referencing within memory |
Hallucination means the agent made something up. Memory conflict occurs when two real sources disagree and the agent picks the wrong one.
Conflicts do not appear randomly. They enter through four predictable patterns tied to how workspace data moves through systems.
Different integrations sync at different intervals. Your CRM updates hourly. An email thread references a deal status from three days ago. The agent retrieves both, and they disagree.
Temporal knowledge graphs address this by tracking both valid time (when the fact was true) and transaction time (when the system recorded it). Most memory systems lack this granularity.
People say different things in different channels. A manager mentions budget cuts in Slack, but the finance document shows the budget as approved. A sales rep updates the CRM with one close date and tells the team a different one in a standup.
Agents inherit the same ambiguity that humans navigate through context and judgment. The difference: humans know to ask a follow-up question. Most agents do not.
Field meanings change over time. "Status: Complete" meant "delivered to client" in 2023, but "internal review done" in 2025. Same field, different meaning. This form of conflict is invisible at the data level because both values look valid.
Some sources get updated; others do not. A deal closes in the CRM, but the project tracker still shows "in progress." As noted in a comparison of memory systems for LLM agents, "stale edges" in knowledge graphs and "consolidation errors" in episodic memory are documented failure patterns.
Undetected memory conflicts surface as three specific failure modes, each eroding user trust in a different way.
The agent retrieves one version of a fact and presents it without qualification. This is arguably worse than hallucination. The agent has real supporting evidence for its wrong answer. It passes fact-checking because the cited source is real.
The same question in different sessions yields different answers, depending on which memory gets retrieved first. Retrieval order in vector databases is similarity-based, not recency-based. A semantically close but outdated fact can outrank the current one. Trust erodes fast.
When both conflicting facts are retrieved simultaneously, the agent tries to reconcile them mid-response. The result is hedged, confused, or incoherent output. Benchmark research on multi-turn memory finds that agents struggle to revise stored knowledge when new information contradicts it.
Without conflict handling, your agent will sometimes confidently give wrong answers, sometimes contradict itself, and sometimes produce confused word salad. All three erode user trust.
Detection must happen before resolution. You can catch conflicts at three points in the pipeline.
Check new facts against existing memory before storing them. If the system already knows "Project X: active" and a new source says "Project X: cancelled," flag the conflict at write time. The tradeoff is ingestion latency.
When retrieving memories, check whether multiple facts about the same entity conflict. Surface conflicts to the LLM with metadata (source, timestamp, confidence) so the model can make an informed choice. The tradeoff is query latency.
Periodic jobs scan the memory store for conflicting facts. These generate conflict reports for human review or auto-resolve based on rules such as source authority or recency. This catches conflicts that emerge gradually, like schema drift.
Production systems benefit from all three layers. Ingestion time is the first defense. Query time is the safety net. Background reconciliation is the audit.
Once detected, the system needs a resolution strategy. These four patterns are well established in distributed systems and cover most production scenarios we've seen at Hyperspell.
Pattern | Mechanism | Best For | Failure Mode |
|---|---|---|---|
Timestamp-based | Most recent fact wins | Fast-changing statuses | An older authoritative source was overridden |
Source authority | Predefined hierarchy | Structured data with clear owners | Wrong hierarchy causes systemic errors |
Explicit flags | Store both, surface to user | High-stakes decisions | Too many flags cause fatigue |
Confidence scoring | Weight by extraction confidence | Edge cases, tiebreaking | Complex to tune |
Simple and often correct. If two facts conflict, the newer one is probably more accurate. But a carefully researched document from last month may be more reliable than a casual Slack message from today. Recency is a useful heuristic, not a universal rule.
Define which sources are canonical for which fact types. The HR system is authoritative for employee data, not Slack. The CRM owns deal status, not email threads.
Implementation involves assigning authority weights per source per entity type. At Hyperspell, we support source weighting across our integrations, so you can configure which sources rank higher in retrieval results.
Here's how to weight data sources in a query to prioritize CRM data over Slack mentions:
from hyperspell import Hyperspell
client = Hyperspell()
response = client.memories.search(
query="current status of Project X",
sources=["slack", "hubspot"],
options={
"slack": {"weight": 0.5},
"hubspot": {"weight": 2.0},
}
)
for doc in response.documents:
print(f"[{doc.source}] {doc.title} (score: {doc.score})")
The weight parameter tells our re-ranker to favor results from higher-authority sources. In this case, HubSpot results rank roughly four times higher than Slack results: a simple implementation of source authority hierarchies.
Do not resolve the conflict. Store both versions with a conflict marker and let the agent or user decide at query time. The agent can surface the conflict directly: "I found two different statuses for this project. Slack says cancelled, but the project tracker shows active. Which is correct?"
This is the safest pattern for high-stakes decisions where an incorrect auto-resolution could cause real harm.
Weight facts by extraction confidence, source reliability, and corroboration (how many sources agree). This pattern works best as a tiebreaker when timestamp and authority patterns produce ambiguous results. In the systems we have seen, multi-signal approaches in which no single factor determines the resolution hold up best, and the survey cited above flags trustworthiness as an open research frontier for exactly this reason.
The patterns above only work if the underlying data model supports them.
Memory schema design. At Hyperspell, we automatically track source and timestamp for every document. For conflict resolution, you can extend this with custom metadata that captures additional context your resolution logic needs:
memory = client.memories.add(
text="Project X has been cancelled per team lead decision.",
resource_id="slack-msg-2026-03-05",
metadata={
"source_authority": "team_lead",
"confidence": 0.6,
}
)
Your resolution logic can then compare built-in fields (source, timestamp) alongside custom metadata (authority level, confidence) to decide which version of a fact to trust.
Surfacing vs. silencing. Not every conflict should be shown to the user. Low-stakes conflicts with high-confidence resolution can be handled silently. Financial data and customer records warrant human review. Meeting time updates can usually auto-resolve.
Audit logging. Every resolution decision should be logged. The MemOS architecture treats provenance and versioning as first-class memory metadata. Audit trails are an architectural requirement, not an afterthought.
Escalation patterns. Define thresholds for escalating conflicts to human review. High-stakes entity types (financial data, compliance-related facts) warrant human-in-the-loop resolution.
Our multi-source search across dozens of integrations provides the building blocks for conflict-aware retrieval: source weighting, custom metadata, and timestamp tracking are available out of the box.
Conflicts are inevitable in any memory system that ingests data from multiple sources. The goal is not to eliminate them. It is to detect them early, resolve them systematically, and surface uncertainty when resolution is ambiguous.
Store source metadata. Define authority hierarchies before you need them. Log resolution decisions. Design your agent to communicate uncertainty rather than guess.
Memory conflict is a data problem: the agent has genuinely contradictory inputs from real sources. Hallucination is a model problem: the agent generates unsupported claims. They require different solutions: conflict-resolution logic for the former, better grounding and retrieval for the latter.
Three approaches: ingestion-time detection (check new facts against existing memory), query-time detection (compare retrieved facts for contradictions), and background reconciliation (periodic scans). Most production systems combine all three. Hyperspell's multi-source retrieval across dozens of integrations provides the data layer these detection strategies build on.
It depends on the stakes. Low-risk, high-confidence conflicts can auto-resolve using timestamp or source authority rules. High-stakes or ambiguous conflicts should be surfaced with the conflicting sources identified.
Knowledge graphs model entities and relationships explicitly, making it possible to detect when two facts about the same entity contradict each other. They also support source attribution and temporal metadata: essential inputs for any resolution strategy.
Memory conflict is distinct from hallucination: contradictory real sources, not model generation.
Conflicts enter through four predictable patterns: timing mismatches, human inconsistency, schema drift, and partial updates.
Detect at ingestion time, query time, and through background reconciliation.
Four resolution patterns cover most scenarios: timestamp-based, source authority, explicit flags, and confidence scoring.
Source and timestamp metadata are essential for conflict detection. Custom metadata (authority level, confidence) strengthens resolution.