Agent memory gets genuinely interesting when it is wrong.

Imagine an agent returning to a repository three weeks after a decision was made: "retries belong to the worker." It retrieves that sentence from memory, builds its plan around it and avoids reopening twenty files. Excellent, unless the architecture changed last Thursday.

Without provenance, the sentence still looks like truth. Without staleness, it ages beautifully. Without a way to see what superseded it, the agent can become more consistent as it becomes more wrong.

That is what makes Memory, a young open-source project from Aictx, more interesting than the generic promise of "persistent memory."

The repository was created in late April, the version inspected here is still 0.2.1, and it has only a few dozen GitHub stars. This is not a newly proven standard that every agent stack should install on Monday. It is a useful object for examining what a memory should store besides the memory itself.

The memory carries a reason for existing

Memory keeps a local product graph under .memory/. Bodies are Markdown, metadata lives in JSON, and SQLite provides full-text search. It does not require embeddings, a cloud account or a model API to store the graph.

The more useful decision is inside the schema.

A memory object can have code anchors, but it can also carry evidence. The current format can point to a file, commit, task, another memory or a source. source records who introduced information, while origin can describe external provenance with a locator, capture time, digest and media type.

Objects also keep a content hash and can be marked stale or superseded, including a pointer to what replaced them.

That sounds like a lot of ceremony for remembering that retry logic belongs to a worker.

It is also the point.

Persistent memory turns a small local claim into an input that future decisions can reuse. The better the system becomes at retrieving that claim, the farther a mistake can travel.

Researchers can already see mistakes travelling

An ACL 2026 study examined how agents reuse stored experiences. The researchers describe an experience-following behavior: when a new task is highly similar to a retrieved memory record, the agent's new output also tends to resemble the previous output.

That helps explain why memory works. It also explains the unpleasant edge of the feature.

The study identifies error propagation, where bad past experiences degrade future behavior, and misaligned experience replay, where an execution that looked correct in one setting can still be misleading when reused as experience elsewhere.

"This worked before" is not the same information as "this is good evidence for the current task."

The authors' controlled experiments show that the quality of stored experience needs active regulation. Memory therefore stops looking like a longer disk attached to the context window. It becomes an editorial system: add, correct, forget and reclassify.

Provenance still does not prove truth

One distinction matters here.

Knowing that a claim came from commit abc123, a file or a user message does not make the claim correct. Provenance answers "where did this come from?" It does not automatically answer "is this true?"

Memory does not magically solve that problem.

Its sync command checks code anchors and reports memories whose referenced paths changed or disappeared since the previous sync. The current source then generates an instruction for the agent to re-verify those objects, fix or replace dead anchors, and mark invalidated memories stale.

That limit is healthy. A changed file is a review signal, not mathematical proof that every decision mentioning it is obsolete.

The mechanism is closer to a smoke detector than an architecture expert. That is already useful as long as nobody asks the smoke detector to fight the fire by itself.

Provenance is showing up in memory research too

Aictx is not the only place where the problem is moving in this direction.

MemORAI, published in the Findings of ACL 2026, explicitly identifies absent provenance tracking as a weakness in existing graph-based memory systems. Its own design enriches memory graphs with the factual origin of information at conversation-turn level.

That is not validation of Aictx. The systems have different goals, and MemORAI did not evaluate Memory.

The overlap is narrower and more useful: retrievable text is not enough to make durable memory trustworthy.

Another ACL 2026 benchmark, Mem2ActBench, moves beyond asking whether an agent can retrieve a fact. It asks whether long-term memory can actually guide tool choice and parameter grounding. Across seven evaluated memory frameworks, current systems still struggled with that active use of memory.

Retrieving the right sentence was only the easier half of the problem.

Memory should be contestable

A lot of agent-memory discussion has focused on context size: how many tokens can survive, how to summarize a session, how to retrieve the right file later.

Persistent memory adds a less comfortable question: what are we allowing to become durable?

For a coding agent, a consequential memory should ideally be able to answer several questions when challenged:

  • what claim is being preserved;
  • which source or artifact supported it;
  • what code it was anchored to;
  • when it was observed;
  • what changed afterward;
  • whether a newer decision replaced it.

Not every memory needs Aictx's schema. A preference such as "use Celsius" does not require a Git commit and three witnesses.

But once a memory starts driving consequential actions, modifying code, choosing an environment, sending something, or making a decision for a user, its provenance becomes more interesting than its similarity score.

A memory that remembers everything is impressive. A memory that can explain why it still believes something is much more useful.