log 0003: memory is not the same as truth

giving an agent more memory sounds like a storage problem. connect it to notes, make them searchable, and let it remember past work.

that part was easy.

the part that kept bothering me was what happened next: if an agent finds a sentence in memory, why should that sentence be allowed to become the answer?

the problem

chat, search results, and source notes can all look like memory to an agent. they are not the same thing.

chat is temporary working context. it can contain guesses, abandoned plans, and corrections that only make sense beside the message before them. a search result is a useful lead, but it is still a shortened pointer selected by a retrieval system. the source note is the place i can inspect, maintain, and decide to treat as the record.

when those layers collapse into one, an agent can retrieve an old brainstorm and repeat it with the confidence of a settled decision. giving it more context does not solve that. sometimes it only gives the mistake a longer memory.

so i stopped treating “the agent can find this” and “the system accepts this as the record” as the same permission.

the method

i built a private mcp server for my second brain. mcp is a connector that gives an agent a small list of actions it can take against another system. it is not the memory itself. it is the doorway into the notes and the list of verbs available at that doorway.

i kept that list small and separated the read path from the write path.

1. search points back to a source. results include a path to the original note, so the agent can inspect the full record before using a retrieved sentence. search is navigation, not authority.
2. reading does not grant writing. finding and reading notes are ordinary actions. a write request has to acknowledge the note-writing rules and include a reason for why the addition belongs.
3. writes are additive through this interface. the exposed note-writing actions create a new note or append a dated section. there is no arbitrary overwrite or delete tool in the mcp.

this gives the agent enough access to recover useful context without giving the same interface a silent way to replace the history that explains it.

the control

this is the actual shape of it:

read
agent -> mcp -> search -> source note -> answer with source

write
agent -> rules acknowledged + rationale -> create / append

not exposed through this interface
overwrite / move / rename / delete

missing tools matter here. “be careful with my notes” is an instruction. not exposing a delete tool is an interface boundary. the first depends on an agent remembering what i asked. the second changes what that agent can request through this particular doorway.

for a changed decision, the agent can append the correction and its context rather than quietly replacing the earlier state. the older note may still be wrong, but the path from old decision to new decision remains visible.

i also checked the live tool list and ran the server’s self-test. the search, source-reading, rule, create, and append paths are present and working. arbitrary overwrite and delete operations are absent from the exposed interface. that is a receipt for the boundary i built, not a claim that the whole system is perfectly secure.

the limit

this is not a truth machine.

a path back to a source tells me where an answer came from. it does not prove the source was correct. a stale note is still stale. a confident mistake with a source is easier to inspect, but it is still a mistake until someone corrects the record.

write rules do not prevent bad information either. requiring an acknowledgement and a reason creates friction and a traceable decision point. it does not replace judgment, and it is not the same as a complete permissions system.

the boundary is also specific to this mcp. people or other systems with access to the underlying files can still edit them. passing a self-test proves the checked paths behave as expected; it does not prove production security or every possible access path.

what this design gives me is smaller and more useful: answers are easier to trace, writes are deliberate, and the agent cannot silently erase history through the same interface it uses to remember.

takeaway

if you are building agent memory, start with five questions:

1. what place counts as the record?
2. does search lead back to the complete source?
3. are read access and write authority separate?
4. can you begin with create and append instead of silent destructive edits?
5. which actions are deliberately unavailable through the agent’s interface?

i thought i was building a better memory layer. i was really deciding how temporary context becomes a durable record, and where it should stop.

the hard part wasn’t giving agents memory. it was deciding what they’re allowed to treat as truth.