When Memories Disagree — Recordari Docs

On a shared workspace, different people file different things. Recordari does not silently pick a winner — it keeps both claims visible until someone decides, and it preserves who said what.

You rarely go looking for disagreements yourself. Your agent discovers them during orient or while filing, then asks you what to do. This page explains what happens behind those conversations.

Three kinds of change

Not every update is a disagreement. Recordari treats these differently:

Situation	What it means	What happens
Correction	Same claim, said better — a typo, clearer label, tag fix	In-place revise on the existing memory
Contradiction	Two active memories make conflicting claims	Both stay live until you settle which holds; agent flags it
Supersession	A decision changed — the old claim is no longer current	A new memory replaces the old one; the original is archived but kept in the graph

Getting the distinction right matters. A typo fix should not look like someone overrode your decision. A genuine change of mind should not rewrite your wording in place.

Who owns a memory

Every memory has an owner — whoever filed it:

How it was filed	Typical owner	What others can do
Personal key or OAuth session	You (human-owned)	Others cannot silently revise your wording; substantive changes use supersede with ceremony
Workspace key	Agent-owned	Editors can correct or supersede with less ceremony

You can always revise your own memories. Changing someone else's human-owned memory requires an Editor or Owner role, a stated reason, and (for substantive changes) explicit confirmation.

Plain workspace-key agent sessions cannot perform override or supersede ceremony — the session has no workspace role. An Editor using a personal key or OAuth session is required.

Walkthrough: Alice and Bob discover a contradiction

Alice and Bob both work on the payments domain. Neither knows the other has filed something conflicting.

Step 1 — Alice files a decision

Alice tells her agent:

"File a decision: checkout uses Stripe for all card payments."

Step 2 — Bob files a different decision

Bob tells his agent:

"File a decision: checkout uses Adyen for card payments — we need better EU coverage."

Step 3 — An agent discovers the conflict

Bob opens a new session the next day. His agent orients on the payments domain. The orient digest includes owned contradictions — memory pairs where Bob owns at least one side and the claims conflict.

The agent does not pick a winner. It tells Bob:

"Two memories contradict each other — Alice's Stripe decision and your Adyen decision. Which claim should we treat as current?"

Bob was not aware of the conflict until the agent surfaced it. That is normal.

Step 4 — The team decides

After talking to Alice, Bob replies:

"Keep Stripe — we evaluated Adyen but the existing contract wins for now."

Step 5 — The agent records the settlement

Bob's agent connects the two memories as resolved, with a narrative explaining the outcome. Because Alice's memory is human-owned, this step requires Editor role plus override reason and confirmation — the same ceremony as changing someone else's content.

Both memories remain in the graph. The resolved connection records how the disagreement was settled. Alice's original wording is intact.

Walkthrough: typo vs change of mind

Same domain, different mechanics.

Alice filed: "Decision: API rate limit is 100 req/min."

Correction (typo)

Alice notices the limit should be 1000, not 100. She tells her agent:

"Revise that rate-limit memory — it's 1000 req/min, not 100."

Same claim, better wording. In-place revise. No ownership issue.

Substantive change (Bob disagrees with the policy)

Bob thinks 100 req/min is wrong as a policy, not just a typo. His agent cannot silently revise Alice's memory.

Carol, an Editor, tells her agent:

"Supersede Alice's rate-limit decision — the new limit is 500 req/min. Reason: load tests showed 1000 was unreachable; 500 is the agreed compromise."

Recordari:

Creates a new memory owned by Carol (or her agent), with the updated claim
Archives Alice's original — it leaves default read paths but stays in the graph
Wires a supersedes edge with Carol's reason as the narrative

Alice's wording is never overwritten. The graph shows both versions and how they relate.

Step 6 — Alice learns what happened

Alice starts her next session. Her agent orients. The digest includes owned superseded — memories of hers that someone else replaced.

The agent tells her:

"Your rate-limit decision was superseded by a new one — Carol recorded that 500 req/min is the agreed limit after load testing. Want the details?"

Alice did not need to check audit logs or run a search. The agent brought it to her, the same way it surfaces contradictions.

What you experience day to day

On a shared domain with a personal key:

Contradictions involving your memories — your agent flags them at orient or while filing; you answer when asked
Your memory superseded by someone else — your agent tells you at orient, with who did it and why
Your own corrections — you revise in place as usual
Minor fixes to someone else's memory (tags, dates) — Editors can still do these in place; they are recorded in the audit log but do not appear in orient digest

You do not need to know tool names or relationship types. Your agent handles the mechanics once you decide.

What admins can review

Override and supersede actions are recorded in the compliance audit log on Team plans and above — who changed what, when, with what reason. That trail is for admin review, not for day-to-day agent sessions.

Authentication — personal vs workspace keys and why ownership follows from key type
MCP Tools Reference — Revise, Connect, and Orient in detail
Audit Log — compliance trail for overrides and supersede