Agent-Maintained Knowledge

A session working against a payments integration in March writes a line into the project’s shared memory: the refund endpoint returns null on a declined card, so downstream code should check for null rather than catch an exception. Four months later, after the payments team migrates that endpoint to a stricter contract, a different session — a different day, a different engineer typing the prompt, no memory of the March session — touches the same integration and, following the same convention, writes its own line into the same shared file: the refund endpoint now throws on a declined card. Both lines are still there. Neither is marked wrong. The next session that loads the file inherits two contradictory instructions about the same endpoint, written months apart by two instances of the same tool, with nothing in the file itself to say which one describes the code today.

This is not a hypothetical edge case invented for a handbook. It is the direct, predictable consequence of a feature that reached mainstream coding agents in 2026: memory a model writes for itself, not memory a human writes for the model to read. The moment an agent can save what it learned mid-session and load that note back into a future session, the file it is writing to has become something genuinely new — a body of standing knowledge authored and consumed by the same class of actor, on a cadence no human is necessarily watching.

A third kind of knowledge

This Library has already covered two of the three ways knowledge reaches a coding session. One is knowledge a human writes for an agent to consume — a CLAUDE.md or AGENTS.md file an engineer authors by hand, the subject of this volume’s chapter on the constitution pattern, updated the way any document is updated: someone notices it is wrong or incomplete, and someone edits it. The other is knowledge extracted after the fact from a record — a decision summarized out of a transcript, a pattern mined from a hundred past sessions, produced by a process a human designed even if no human reads every individual output. Agent-maintained knowledge is a third category, and a newer one: knowledge an agent writes into standing context during its own work, expecting a future session — its own continuation, or an entirely different one — to read it as fact.

The distinction is not cosmetic. Claude Code, as of mid-2026, ships exactly this split as two separate mechanisms loaded into every session: CLAUDE.md files, which Anthropic’s own documentation describes plainly as something the developer writes, and auto memory, described as notes “Claude writes itself based on your corrections and preferences.” The vendor’s maintenance advice for the first mechanism is the familiar one — review it, prune contradictions, keep it current — the same discipline any document under version control gets. The second mechanism gets a different kind of advice, because nobody has fully worked out what the discipline should be yet: a model deciding, mid-session, what is worth remembering and writing it down unsupervised is a genuinely different maintenance problem than a person periodically rewriting a file by hand, and the tooling built to manage it is younger than the feature itself.

Which fact is current

The payments example is not really a question about payments. It is the general problem: two agent-written facts about the same subject disagree, no human wrote either one, and nothing intrinsic to a markdown file records which was written more recently relative to the code, as opposed to relative to the other note. A git commit at least carries an author, a timestamp, and a diff against a known prior state — three separate mechanisms a reviewer can use to reconstruct what changed and when. A line an agent appends to a shared memory file typically carries none of them, unless a system is specifically built to add them.

A 2026 study of governed shared memory in multi-agent systems names two of the resulting failure modes directly: stale propagation, where outdated knowledge keeps being read and acted on after the world it describes has moved on, and contradiction persistence, where conflicting entries simply coexist, unresolved, because nothing forces a decision between them. The researchers’ point is that neither failure is fixed by more context or a bigger window — both need explicit machinery, because a model reading two contradictory lines in the same file has no principled way to prefer one over the other from the text alone.

None of this is a new problem in computer science generally — it is the write-conflict problem that distributed and concurrently edited data stores have handled for decades, under names like last-write-wins, vector clocks, and conflict-free replicated data types, the formalism Marc Shapiro and colleagues introduced in 2011 for structures that can be updated independently at multiple sites and still converge to a consistent state without a central coordinator. What is new is applying that same class of problem to a store where the writers are not deterministic replicas of a database but language models improvising a note in natural language, with no schema forcing the note into a form a conflict-detection algorithm can reason about cleanly.

Four ways teams are resolving it, mostly by accident

A 2026 formal analysis of contradiction resolution in agent memory, published under the name TOKI, found that production systems already lean on one of a small number of heuristics whenever a new agent-written claim contradicts a stored one — but that, in the paper’s words, none of the systems examined declared “the isolation level it assumes or the write-time anomalies it admits.” In plain terms: teams are already picking a strategy, mostly without deciding to, and without knowing what that strategy silently gives up.

None of the four is free, and the more interesting finding is not which one wins — the same research argues most production systems should use different strategies for different kinds of fact — but that almost nobody currently declares which one they are using. A team relying on last-write-wins by default, because that is simply what happens when a new markdown line is appended below an old one and nobody looks closely, is making a real choice about which facts survive. It just has not written the choice down.

A conflict resolved silently is not a conflict resolved. It is a coin flip a team agreed, by never checking, to stop noticing.

Detect first, decide second

The more tractable version of this problem, and the one production systems are actually converging on, separates conflict detection from conflict resolution and keeps the second step human wherever the stakes justify it. Zep’s temporal knowledge-graph architecture for agent memory, one of the more citable production designs in this space, tags every stored fact with both the time the fact was true in the world and the time the agent first recorded it; when a new fact contradicts an old one, the old fact is not deleted, only marked superseded and excluded from what a future session sees by default, while the full history stays available to anyone who wants to look. Mem0’s memory layer runs a comparable step at write time, flagging a new claim against existing entries before deciding whether to add it, update the old one, or keep both and mark the disagreement. Neither system claims to have solved judgment — both still lean on an automated ranking or an explicit human decision to say which fact wins. What they add is a record that the disagreement happened at all, which unattended last-write-wins never produces.

What this looks like inside Operon

Operon’s own answer sits closer to the await-confirmation end of that table than the fully automated end, deliberately. Its MemoryConflictResolver engine compares a newly written project-memory entry against existing entries using Jaccard similarity — a standard measure of how much two sets of terms overlap — to catch the case that matters most: a new entry that is clearly talking about the same subject as an old one but says something different. Detection is automatic; resolution is not. The conflict surfaces through a `memory:conflict` event and a MemoryConflictCard in the interface, and a person picks keep-old or use-new. Separately, Operon’s MemoryInjector scores every memory entry by category, recency, and a confidence value before deciding what to inject into a new session’s starting context, so an older entry does not carry the same weight as a fresher one purely by virtue of having been written first. Neither piece resolves a contradiction on its own — together they land closer to a workable middle ground than either letting an agent write unsupervised or refusing to let anything into memory without a human curating every line.

Memory audits: recalibration aimed at knowledge

Detection at write time catches the contradiction that announces itself — a new entry that clearly overlaps an old one. It does not catch the slower failure: a fact nobody rewrites, because nothing about it currently looks like a contradiction, that simply stops being true underneath an unchanged sentence. This Library’s trust calibration chapter, in the verification volume, names the discipline that applies here even though it was built for a different target: the argument that an automated system’s reliability has to be periodically rechecked against outcomes rather than trusted once and left alone, because trust that is never rechecked drifts quietly in whichever direction habit happens to push it. Agent-written knowledge needs the identical discipline, aimed at facts instead of at confidence in a model’s output — a periodic, structured review of what has accumulated in shared memory over some window, checked against what is actually true in the codebase today.

Practitioner guidance converging on AGENTS.md maintenance in 2026 describes something close to this by instinct, even without borrowing the trust-calibration vocabulary: a scheduled prune, commonly quarterly, to remove stale or duplicated instructions, paired with an on-trigger update whenever an agent’s repeated mistake reveals that a standing note is wrong rather than simply unconsulted. Anthropic’s own memory tooling bakes a version of the same cadence directly into its interface, prompting a check on whether a file “has been reviewed and pruned within the last 90 days.” None of it is exotic once named. It is the same recalibration argument this Library has already made about trusting a model’s output, applied one layer up, to trusting what the model has written down about itself — audited on a schedule, not trusted indefinitely because nothing has obviously broken yet.

How settled any of this actually is

It would overstate the evidence to call any of the above a solved practice. The research specifically evaluating how memory systems handle contradicting or outdated facts is recent enough that most of the citable work is 2025 and 2026 preprints rather than settled consensus — a benchmark built specifically to test long-term memory systems under intentional contradictions found meaningful gaps across every system it evaluated, and a separate empirical taxonomy of multi-agent failures, built from more than 1,600 annotated execution traces, put agents contradicting or duplicating one another’s work in its own top-level failure category, alongside failures of specification and of verification, rather than treating it as a rare edge case. Industry practice mirrors the research’s youth: multiple vendors ship a version of agent-written memory now, but there is no shared standard across tools for how a conflict in that memory should be detected, surfaced, or resolved, and the strongest guidance available is convergent practitioner habit rather than anything a vendor ships as a built-in default. A reader looking for a settled best practice here, the kind that exists for, say, indexing a database, will not find one. What exists instead is a consistent shape — detect automatically, resolve deliberately, recheck on a schedule — arrived at independently by enough different systems that it is worth adopting even without one canonical source to point to.