DEV Community

Thomas Jumper
Thomas Jumper

Posted on

Shared agent memory does not mean shared secrets

"Give every agent shared memory" can sound like an invitation to build a new, invisible data dump. That is not the workflow I want.

Useful shared memory has boundaries.

First, do not store secrets. API keys, passwords, access tokens, customer data, and raw production logs need their proper systems of record. A memory tool is not a vault.

Second, make entries inspectable. A person should be able to see what was stored, which agent stored it, and whether it is still useful.

Third, keep project scope explicit. A lesson from one project should not casually appear in another just because the same person happens to be using the same client.

Fourth, design for correction. Working knowledge changes. Teams need a way to export, archive, revise, or erase memories when a decision is reversed or a note goes stale.

Finally, use memory as an aid to verification, not a replacement for it. A recalled note can tell an agent where to look and what failed before. It should not overrule the current code, test suite, or security policy.

That is the design bar I hold StremAI to: useful project memory that remains human-readable, attributable, scoped, and under the user's control.

The goal is not for agents to remember everything. It is for a useful lesson to survive long enough to help the next connected agent without creating a new source of hidden risk.

What boundary would make you comfortable letting your team share agent memory?

Top comments (0)