Team Memory: governed operational memory
How I describe the memory people and agents use to carry work across sessions, tools and systems.
Back to the playbook · Implementation and task walkthrough · Inside the memory kit
What the memory belongs to
I build memory around the world agents work in: the people, entities, events, decisions and activities that shape their work. A conversation is one input. Databases, business events, tool results, other agents and human decisions can also contribute context.
Personal memory helps an assistant understand a person. Operational memory helps authorized participants understand what is happening and carry the work forward. The continuity belongs to the situation, even as agents, sessions and tools change.
I use Team Memory as the approachable name and governed operational memory as a description of its purpose. This is my positioning language, not a universally adopted taxonomy or a claim to have invented shared agent memory.
| Memory focus | Question it helps answer | Typical content |
|---|---|---|
| Session memory | What is happening in this conversation or execution? | Messages, the current plan and intermediate results |
| Personal memory | What should an assistant remember about this person? | Preferences, goals and past interactions |
| Shared operational memory | What should authorized participants know to act on this ongoing situation? | Relevant entities, events, work state, decisions, dependencies and evidence |
These purposes can overlap. Personal memory can persist for years; operational memory can contain information about a person. Short-term and long-term describe duration. Personal and operational describe purpose and organization. Semantic facts, episodic experiences and procedural guidance can occur in either setting. LangChain's memory overview distinguishes thread-scoped and cross-thread memory and permits application-level data and custom namespaces.
The work keeps its memory
Conceptual illustration. The participants and connections explain a pattern; they are not a claim that every integration or control shown is implemented.
Suppose a customer changes a requirement. One agent discovers it, another assesses the impact, a third changes implementation work and another prepares communication. Their actions may happen in different tools and at different times, without a new human prompt for each step.
The next participant needs the relevant source, the current decision, what has already happened and the unresolved dependencies. It should receive the context it is authorized to use, rather than a complete copy of someone's conversation. The source system retains authority over its records; retrieved memory may need checking for freshness or correction.
The same pattern applies beyond software development. A customer, account, campaign, incident or project can be the shared subject. The task/session/decision model in this playbook is one implemented application of that broader idea.
What governed and shared mean here
- Operational: relevant to ongoing activity, its history and decisions.
- Shared: selectively accessible across authorized people and agents, not globally visible to everyone.
- Governed: retrieval and updates have explicit scope and authority, with attribution and checks against changed state where supported.
Storing a guideline does not enforce it. Backend permissions, conditional writes and the runtime's action controls need to implement the guarantees being claimed. A memory record does not grant permission to act, replace the workflow engine or become the authority for every external system.
My lean workers deliberately have no memory MCP. Preparation selects their context and coordinating scripts return selected outcomes to shared records. The memory backend supports version-guarded writes; my current queue does not yet use atomic claims, so I run one coordinator. Section 5 retains those implementation boundaries.
Related research and terminology
There is an established and growing literature on multi-agent, collaborative and organizational memory. These works overlap with the problem; they do not establish that the implementations are equivalent.
| Work | Connection to this explanation |
|---|---|
| G-Memory, NeurIPS 2025 | Uses organizational memory theory to preserve collaborative experiences and reusable insights across agent-team executions. |
| Collaborative Memory, May 2025 | Studies sharing across users and agents with changing access permissions and provenance. |
| Governed Shared Memory for Multi-Agent LLM Systems, June 2026 | Frames a fleet-memory problem involving leakage, stale information, contradictions and provenance. |
| My Governed Memory paper, March 2026 | Describes Personize's architecture for workflows acting on common entities, combining facts, typed properties, governance and scoped retrieval. |
The first is a conference paper; the other linked papers are arXiv preprints. My own paper describes my work and is not independent validation of it.
I would not describe Mem0 as merely session memory. Its agent-to-agent memory explanation describes persistent shared memory across agents, including a user-identifier-centered example. The meaningful comparison is the operating model and demonstrated behavior: entity identity, typed records, source attribution, scoped access, update conflicts and governed context delivery. A label alone does not demonstrate differentiation.
Why this can remove bottlenecks
The intended benefits are less repeated discovery, less manual context transfer, clearer handoffs and fewer actions based on outdated information. Relevant context should remain usable when a person changes tools, an agent stops or work passes between workflows.
Those are mechanisms to test, not a measured memory-only productivity multiplier. In my October workflow, preparation, execution and review changed alongside memory. The results reference keeps activity, verification, cost and unmeasured accepted delivery distinct. Memory makes evidence and work state available; the checks and acceptance still have to happen.