The fastest way to make agent memory untrustworthy is to treat it like a second repository.
Memory is useful when it holds the things that are expensive to rediscover but do not belong in source control as the primary record. Git and docs are still the source of truth for code, specifications, credentials, and change history.
Here is the simple split I use.
Good memory candidates:
- Why the team chose an approach when the code alone does not explain it.
- A recurring failure mode and the first diagnostic check that saves time.
- A setup detail that is real but has not made it into formal documentation yet.
- A decision made in a working session that needs to be visible to the next session.
- The name and location of a canonical doc the agent should read before changing a sensitive area.
Keep out of memory:
- API keys, passwords, tokens, customer data, or private identifiers.
- Raw code dumps.
- Anything that should be versioned, reviewed, and merged through git.
- Unverified guesses presented as facts.
The test is boring and useful: would a teammate be harmed if this memory were stale? If yes, write or update the source-of-truth document. Then memory can point to it and explain when it matters.
For example, "read the migration runbook before touching billing" is good memory. The migration runbook itself should live in the repository.
This keeps recall concise. Agents retrieve the reason, the warning, and the pointer instead of flooding a session with an old copy of the whole world.
Shared memory works best as working knowledge with boundaries, not as a mysterious black box. That is why StremAI shows human-readable, attributed entries and gives people controls to export, archive, or erase them.
What is one thing your team keeps re-explaining that should be a memory, not another paragraph in a prompt?
Top comments (1)
Treating memory as a second repo is exactly how teams end up with contradictions nobody knows how to resolve. The split you describe is the one that scales: memory for costly-to-rediscover context, Git and docs for primary facts and change history.
The subtle production issue is expiry. A diagnostic hint that saved time last month can become misinformation after one refactor unless memory items have an owner, a refresh signal, or some trigger that says "this was probably invalidated."
Curious whether you age these notes out automatically or only when a conflicting commit or doc change lands.