Shared Memory Pools

Individual agent memory creates information silos. Agent A learns that Client X prefers executive summaries under 200 words. Agent B, drafting a report for the same client, does not know this preference and produces a 500-word summary that the client rejects. Shared memory pools solve this by creating a common memory space that multiple agents can read from and write to.

The shared pool architecture has three components. First: the pool itself — a persistent store with the same tiered structure as individual memory but accessible to multiple agents. Second: write permissions — rules governing which agents can write to which pools. Not every agent should write to every pool. The sales agent writes client preferences to the client pool. The analytics agent writes data insights to the analytics pool. Cross-pool writing is controlled. Third: read permissions — rules governing which agents can read from which pools. All agents can read from the client pool (client preferences are universally relevant). Only analytics agents can read from the analytics pool (raw data context is not useful to the sales agent).

1. 1. Define Pool Boundaries Create pools by domain: client intelligence, project knowledge, operational procedures, market intelligence. Each pool has a clear scope. Memories that do not fit any pool stay in individual agent memory.
2. 2. Set Read/Write Permissions For each pool, define which agents can read and which can write. The principle: write access is narrow (specialists contribute), read access is broad (everyone benefits). Log every write for audit.
3. 3. Implement Conflict Resolution When two agents write conflicting memories to the same pool (different client preferences observed in different contexts), the conflict must be resolved: most recent wins, highest confidence wins, or both are retained with context.