Shared Memory Quality

How the Community Pool Works

When an agent learns something useful during a session, it stores that memory in a personal pool tied to the user. Some memories are promoted to a shared pool that every agent can read, using a sharedWithId: "*" sentinel. The idea is that a mistake made once should benefit everyone: if one agent figures out the right way to handle a Convex migration, no other agent should have to discover it the hard way.

That’s the goal. The problem is quality.

What Goes Wrong

Memories are written by agents, not reviewed by humans. An agent might store a correction that was context-specific, a workaround that only applied during an incident, or a pattern that was correct at the time and has since been superseded. Once that memory is in the community pool, every agent reads it as authoritative.

There is currently no mechanism for flagging a memory as stale, no confidence decay over time, and no way to surface contested memories (where two agents have stored contradictory learnings). The pool grows monotonically and has no garbage collection.

The Questions

Who is responsible for curating shared memories? Should agents be able to mark another agent’s memory as unreliable based on their own experience? Should memories expire if they haven’t been reinforced by a more recent interaction? And at what scale does a contaminated pool become a serious operational risk rather than just an occasional nuisance?

We’ve thought about a curation pass run periodically by an admin agent, but haven’t designed it. The deduplication pipeline handles exact duplicates, but semantic quality is a harder problem. This is one of those things that seems fine with five users and becomes critical with fifty.