Brokentooth.io / 06 Writing / A Memory System Should Be Able to Show Its Work
A Memory System Should Be Able to Show Its Work
Evidence, editable Markdown, and an honest route back to the record are how I want agent memory to earn trust.
An agent remembering the wrong thing can be more expensive than an agent admitting it doesn't know.
If it doesn't know, we can inspect the system. If it remembers a plausible account of something that never happened, we first have to discover that the account is wrong. Then we get to inspect the system anyway, with a little less trust and a little more vocabulary.
That is why I care about the route back to the record. A useful memory should be able to show where it came from.
A conclusion needs a receipt
“The tests passed” sounds reassuring. It can also conceal a lot.
Which tests? Against which revision? On which machine? Did the command finish successfully, or did an earlier agent write that it intended to run it? Was the result copied from an old session? Did the summary leave out the failing suite immediately below the passing one?
These are ordinary engineering questions. Adding an AI memory layer doesn't retire them.
The current SessionMunch candidate builds deterministic cards from supported imported or managed transcript events. Extracted facts refer back to event sequence identifiers. The card can describe visible commands and outcomes while also recording gaps in what was available.
That is valuable because it makes a claim inspectable. It does not turn a transcript into an omniscient witness. A source harness can omit something; a tool result may be missing; the card's input may be bounded. The record needs to preserve those limitations instead of quietly promoting them into certainty.
“The record shows this” is a claim I can investigate. “The memory says so” is where the investigation begins.
Keep the layers understandable
SessionMunch has a Markdown knowledge wiki and a derived SQLite search index. It also has session evidence and artifacts. Those layers have different recovery needs.
The wiki is ordinary text I can read, edit and version. The index makes lookup practical. Reindexing can reconstruct the wiki's search index from the files. That is a useful guarantee, with a specific boundary: it does not mean every recorded event and artifact can be regenerated from a folder of wiki pages.
If I care about the full history, I need a backup that covers the evidence stores as well. “It's local” is a location, not a backup policy. The hard drive has declined to accept responsibility for our optimism.
This matters when people hear “Markdown source of truth.” It should tell them what they can own and inspect, not imply that a rebuild command recovers information that was never in those files.
The interface should let me inspect it
The repository includes screenshots of the built-in web interface. They are useful because memory should have somewhere a human can look, rather than only a collection of reassuring tool responses.

A screenshot is not a test result either. It shows a particular interface at a particular point. I want the public project page to make that distinction as carefully as the underlying software should.
Old knowledge must stay old
History helps explain a decision. It shouldn't silently become a new instruction.
An old conversation might say a service runs on one machine. The current operational record might say it moved. A memory search has recovered a historical statement; it has not granted that statement authority over today's system.
The same applies to summaries. They help compress a long record into something usable, but compression involves selection. A cited AI summary gives us a way to check that selection. It still needs judgment, especially when the question concerns a deployment, a credential, or a change that happened after the recorded session.
The retrieval workflow I want is gradual: start with a relevant snippet, inspect the supporting section or event, and verify against current source when the decision matters. A giant context dump makes that harder by asking the agent to sort out relevance and authority all at once.
The product should make its limits legible
In October I was asking whether SessionMunch was actually ready to ship as a portfolio project. I wanted more than a green-sounding status report. I wanted the path from capture to retrieval explained, and the repository to match the system.
That is still the standard. An unsupported client should be identified. An optional provider should be optional in practice. A partial import should say what it could read. A proposed integration should stay a proposal until somebody proves it works.
I want people to use this because it makes their work easier, then be able to tell me exactly where it falls short. Keeping the evidence inspectable makes that conversation possible.
There is enough mystery in software already. I don't need to put the project history in another box and call the box wisdom.
Explore the project and all six articles · Inspect the architecture · Read the backup and recovery commands