Conflicts and summaries

On this page you will learn:

when a record gets the conflict status and why MMW never silently overwrites anything;
how to write a summary with derived_from so it does not hide contradictions;
how to resolve a conflict.

Running example: on Monday Anna’s agent saved that staging is deployed through the app-staging systemd unit. On Thursday Ben’s agent saved that staging is now deployed with Docker Compose. Deciding who is right is a job for people, not for memory.

When a conflict appears

Records are compared by fact_key. If one workspace holds several records with the same key but different content or source hash, all of them get the conflict status.

  workspace default, fact_key = deploy.staging.method
  ────────────────────────────────────────────────────────────────
  A  Mon  "through the app-staging systemd unit"        → conflict
  B  Thu  "through Docker Compose, staging service"     → conflict

Nothing is overwritten. remember always adds a new record, even with the same key. The older version stays and is flagged.
Both sides are flagged. Not only the older record but also the newer one: the server does not know which is right.
Newest version first. In search, the newest record with a key ranks above older ones, even when an older one matches the query better. If only an older version matches, the newest is pulled into the results next to it. Older versions carry superseded_by with the newest record’s ID.
Identical text is not a conflict. Saving the same wording again with the same source hash creates no disagreement.
Same text, new hash is a conflict. If the document changed and you re-saved the fact with a new source_hash without removing the old one, the versions differ by hash. Remove the old one first — see Source and freshness.
Boundaries. Only records in the same workspace that you can see are compared. Records without a fact_key never conflict.

What the agent sees

[
  {
    "id": "b3e1…",
    "content": "staging is deployed with Docker Compose, staging service",
    "fact_key": "deploy.staging.method",
    "status": "conflict",
    "created_at": "2026-10-08T14:03:00+00:00"
  },
  {
    "id": "a7d2…",
    "content": "staging is deployed through the app-staging systemd unit",
    "fact_key": "deploy.staging.method",
    "status": "conflict",
    "superseded_by": "b3e1…",
    "created_at": "2026-10-05T09:12:00+00:00"
  }
]

The newest version is a hint, not a verdict. When a record was saved as a correction, superseded_by shows it; when in doubt, the right reaction is not to pick a version by date but to tell the person: “Memory holds two contradicting facts about deploying staging, from October 5 and October 8. Which one is current?”

Summaries: derived_from

Over time records pile up and the agent condenses them into a summary. To keep the summary from becoming a “clean” version that has lost its contradictions, pass the IDs of the source records in derived_from:

{
  "content": "Deployment summary for the week: staging is moving to Docker Compose; migrations run with make migrate before deploy",
  "fact_key": "deploy.weekly-summary.2026-w41",
  "derived_from": ["a7d2…", "b3e1…", "c9f0…"]
}

derived_from takes up to 50 IDs, and only of existing records you can see; otherwise you get derived_from contains unknown memory ids;
in search results, the summary carries a derived_from field listing its sources;
a summary inherits the worst status of its sources: if any of them is conflict or stale, so is the summary. Inheritance goes up to three levels deep, so a summary of summaries still shows the problem.

In the example, the summary gets conflict even though its own text disagrees with nothing: the contradiction underneath is unresolved.

Resolving a conflict

Find out which version is right. Ask a person or re-read the source. Do not go by date: a newer record is not necessarily correct.
Delete the wrong version with forget by its ID:
forget
```
{ "memory_id": "a7d2…", "workspace": "default" }
```
Deletion is soft: the record disappears from search and the graph, and the fact of deletion is kept for audit.
Check the result. In the next search, record B is unverified: the key now has a single version.
Update the summary if needed. Deleted sources no longer affect a summary’s status, so if its other sources are fine it also becomes unverified. But its text may have relied on the wrong version — if so, save a new summary and delete the old one.

Conflicts and the archivist

The archivist works alongside, but differently. It may notice that a new record contradicts a recent one even without a shared fact_key, and mark the older one stale while lowering its confidence. Nothing is deleted. A fact_key conflict is a strict server rule; archivist marks are a model’s judgement.

Where next

Best practices How to name fact_key so conflicts are useful.

Archivist Links and staleness marks set by a model.

search reference All response fields, including derived_from.