On October 4, 2026, I was working through how several trusty-mpm sessions, run by different people on different machines, could share engineering project memory. Each machine runs its own trusty-memory daemon. What one session remembers stays on that machine, even when another person is working on the same project.
I organize memories into palaces, rooms and drawers. That works fairly well for me. The Rust implementation saves memories quickly, and an August measurement against a live daemon put recall at about 1.2 milliseconds.
I wanted the next collaborator to have some of the context behind the work. The tickets and specs were already there. The conversation that produced them might be somewhere else.
My first proposal was to classify memories as shareable, rank them by accuracy and usefulness, and push the eligible ones to a cloud store. Keep the name of whoever originated each memory. Codex separated permission to share from quality: a useful memory could still be private. I agreed, then moved away from requiring one central store. I wanted an interoperable API, with clients able to subscribe to several backends. A mesh.
Recall would stay local. A background connector would sync permitted memories, and the scope would be engineering project work. That was the proposed design on October 4. The system I had built supported local memory and recall, with background consolidation. The shared mesh was still a design discussion.
Then I raised a different requirement: memory should not become another copy of the tickets, requirements and specifications. I wanted it to preserve expressed intent as it evolved, including the reasons a person changed direction.
That puts a fairly demanding job on memory. My own system already had trouble telling an old fact from a current one.
TL;DR
I want shared memory to preserve how intent develops, with links to the tickets and documents that hold the current decisions.
My August logs showed a stale checkpoint reaching 44.8% of turns. Sharing that memory would spread the problem.
I want dreaming to prepare memories before they enter a shared store, connecting related records and flagging conflicts. Permission to share remains a separate decision.
ADRs already preserve rationale and can hold tentative decisions. A separate memory store has to earn its place alongside them.
Agent capture leaves a human review cost. I haven’t shown that the recovered context is worth that cost.
One Fact, One Home
The working rule I arrived at with Codex is that a fact should have an authoritative home. Other places can refer to it, but I don’t want several systems maintaining competing answers.
A ticket owns the work’s status and assignee. Requirements state agreed outcomes and constraints. A product requirements document (PRD) explains the product case, while a spec describes intended behavior. An architecture decision record (ADR) holds a decision and its rationale, including alternatives. Search helps find the evidence across those artifacts.
Memory’s job, as I see it, is to preserve the path around them: what someone was trying to accomplish, how that changed, and what remained unsettled. Once that intent becomes a requirement or a decision, memory should link to the result. The requirement gets maintained in the requirements document.
There’s overlap. A spec can explain why. An issue discussion can contain a change of mind. My rule concerns which version gets maintained.
The conversation on October 4 contains the kind of movement I want to keep. I started with a cloud store, accepted a distinction between permission and quality, then changed the design to allow several backends. I narrowed its scope to engineering projects. Later I questioned what belonged in the system at all. A finished API spec could describe the resulting design without preserving those earlier framings or their sequence.
I asked for a position paper, then put it on hold and asked for this article first. I wanted to use the writing to work out the boundaries before treating them as requirements.
Stale Memory Gets Believed
In August, ADR-0028 in trusty-tools examined my memory-injection logs from July 5 through August 4. The most frequently injected memory was a July 16 checkpoint announcing that a merge train was complete. It appeared in 3,612 of 8,063 trusty-tools turns, or 44.8%. By the end of the measurement period, it was 19 days old.
The fifteen most frequently injected memories were expired checkpoints. Another pinned origin/main to a commit hash that had been wrong for four weeks, then supplied it in about one turn in five.
Recall used a 90-day decay half-life. A PR’s current head can change in hours. The checkpoint was a record of something that happened, but recall kept handing it back as useful context for current work.
Retrieval accuracy is about finding the memory that fits the request. The accuracy of that memory’s contents is another question. A system can return a relevant record faithfully even when the information is outdated or wrong. My checkpoint still described a completed merge train, but it couldn’t establish the current state of the work. That’s why I need dreaming to examine relationships between records, including corrections and contradictions, before I treat recalled material as useful shared context.
Corrections existed. Following them was another problem. Of 109 hand-written links saying one memory superseded or corrected another, only 45 resolved to a memory ID. The rest used labels the machine couldn’t follow. In one case, a rebase made a remembered PR head stale. The correction was in memory, but the old memory had no usable link to it.
Since August 5, the system has supported named fact slots through fact_key. Writing a new fact to an occupied slot retires the previous occupant and links it to the replacement. The older fact remains in history. That gives the machine a way to follow a correction instead of hoping it can interpret a hand-written note.
It also leaves me with a question about what belongs in the slot. The ADR’s example is a PR’s status at a particular head commit. GitHub already has that information. I can make a copy age more carefully, but I still have a copy to maintain.
Keep the Transition and Its Reason
Memory shows intent through its transitions.
I want to know what the person meant at one point, what they meant later, and why they moved. The ticket or PR can tell me the current status.
The fact slots have part of the direction I’m heading: earlier records survive, linked to their replacements. But a replacement link says what followed a fact. It doesn’t explain why the person changed their mind. Filling that history with successive copies of GitHub status would preserve a sequence without necessarily preserving intent.
My system also has task records for goals and checkpoints, including whether they’re complete. A goal expressed before a ticket exists could be useful memory. Once a ticket tracks the work, maintaining another open-or-done field creates another place to fall behind.
So the proposed rule would change how parts of my own system are used. I haven’t settled whether those records should become links with history attached, remain useful within a session, or move out of memory.
The July checkpoint is a reason to be careful. It was useful as a dated record that a merge train had completed. Its repeated appearance weeks later didn’t tell the next session what had changed since.
Dreaming Before Sharing
I need a dream cycle between raw capture and shared memory. A conversation leaves observations and half-formed ideas alongside decisions that may already have changed. Before another person relies on that material, I want it organized into a useful account of the thinking. For this shared-memory design, I consider dreaming an essential step.
I want the pass to recognize repeated accounts of the same intent, connect a later correction to an earlier assumption, and preserve why the thought changed. A collaborator should be able to find the correction alongside what it corrected. They should also be able to recover which parts of the earlier reasoning survived. Consolidation would help someone follow that development without piecing it together from scattered session records.
The human analogy is suggestive. In a 2010 study by Erin Wamsley and colleagues, people who reported dreaming about a virtual maze during a nap improved more on the task afterward. The association links dreaming with processing recent experience, without establishing that the dreams caused the improvement or were necessary for memory.
With its model backend and consolidation enabled, my software’s dream cycle can merge overlapping memories while retaining the originals and links to their replacement. It flags contradictions for human review. Those capabilities give me a starting point for preparing memory while preserving its history.
I want the proposed shared store to accept only memories that have been through dreaming. The pass would prepare records for reuse, with their sources and unresolved disagreements still visible. It doesn’t establish truth or grant permission to share: repeated assertions can still be wrong, and useful memories can still be private. But I want the work of connecting and sorting them to happen before they reach another person’s session. That person should get a record they can examine and follow back to its origins.
The ADR Objection
Michael Nygard’s description of ADRs, published in 2011, starts with the difficulty of tracking the motivation behind decisions. His format records context, decision, status and consequences. MADR includes considered options and their pros and cons, with a proposed status for decisions still under discussion.
That is much of what I’m asking memory to preserve, but not just the ADR but the thinking that led to it.
I use ADRs in trusty-tools. The one behind the stale-memory measurements records rejected alternatives and open limits as well as the decision. It is evidence against claiming formal documents can’t do this job. An ADR can start early, and the discussions linked to it can preserve the thinking around it.
What I want to capture is the thinking that happens before someone writes an ADR, or in the working conversation around it. A framing gets dropped before it becomes a considered option. A person gives a reason in passing. If that reason belongs in the adopted decision, it should make its way into the ADR. Memory might help it survive long enough to get there.
But a good ADR, linked discussion and search may already be sufficient. The distinction I’m proposing is about when and how context gets captured. It doesn’t establish that I need a separate store. I’m going on faith to some degree because I have been so successful using search and memory -- search covering all the static documents and memory covering the transitions.
Nor is the idea new. Jeff Conklin’s Designing Organizational Memory, first written in 1997 and revised in 2001, distinguishes formal results from the informal knowledge created while producing them. That includes assumptions and questions, along with the reasons behind choices. My evolving-intent argument fits within his project memory.
Jintae Lee’s 1997 survey of design-rationale systems even describes an apprentice approach: a system observes the designer’s work and asks questions to capture the rationale. An agent in a coding session looks a lot like that apprentice. Whether it makes capture cheap enough is still a question.
What I Would Ask Memory to Keep
Codex derived a set of proposed requirements from the October 4 conversation. They would have a record identify the person and project, preserve what the person expressed, and link to the relevant issue or document version. Assistant synthesis would be labeled separately. A tentative preference would remain distinguishable from an explicit decision or a later correction. When the intent becomes a ticket, spec change or ADR, memory would link to that artifact and record the transition. It would retrieve current work status from the system responsible for it. These are design proposals from Codex, still to be worked through.
I care about the conditions around a choice as much as the choice itself. Which alternatives were considered? What remains open? What would change the decision? Those were part of the proposed evaluation: can another collaborator recover the reasoning and its limits?
A timestamp and an author give that collaborator somewhere to start. They don’t reproduce the conversation. The more tentative the thought, the more its meaning can depend on context that a short memory record leaves out. Sharing a record between people makes that harder than recalling it for the person who wrote it.
The stale-memory measurements also make me wary of treating a decision-state label as a solution. A field called superseded helps only if the correction can be found and followed. My hand-maintained links frequently failed that test.
Who Does the Review?
Lee’s survey describes the cost problem: the person doing the capture may be doing extra work for somebody else’s later benefit. Conklin likewise identifies additional documentation effort, without a clear immediate benefit, as a reason organizational memory systems failed.
An agent can write the record. Someone still has to check whether it recorded what the person meant, whether a preference became a decision in the summary, and whether the rationale was expressed or invented. Automating the writing leaves that review cost.
In a shared system, the person able to check the memory may be different from the person who benefits from it. I don’t have an answer for who does that review.
I also haven’t run the comparison that would justify the design: give a collaborator the ADR and linked discussions, then see whether adding memory helps them recover more of the reasoning. Include the effort spent reviewing the memory. The October 4 design notes list whether imported memories improve answers as something still to measure.
I started by asking how to move memories between machines. I now have a more specific job in mind: preserve expressed intent through its changes, and connect that history to the work it becomes. My own stale checkpoints show how easily memory can get in the way.
Whether the additional context, sharpened by dreaming, earns its capture and review cost is still open. When I figure THAT out, I’ll go back to trying to link multiple people’s memories together.
Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.
Related reading:
When Sessions Talk... — What my agent sessions said to each other, and where their messages failed to arrive.
Capturing Context — Preserving insights and reasoning before an AI session resets.
Is Your Digital Brain the Light Saber of the AI Era? — Building a personal knowledge system as part of an engineering practice.
AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.
LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.