Team Memory vs Personal Memory for Agents

Choose the audience before saving the fact

Suppose Maya tells her coding agent, ‘Give me concise explanations, use my staging tenant for experiments, and remember that the billing service requires idempotency keys.’ That turn contains a presentation preference, a personal environment detail, and a possible engineering convention. Saving the whole sentence as team knowledge would share too much and give an unverified observation the appearance of policy.

Classify each candidate independently. Ask who should benefit, who may see it, and who can confirm it. A useful default is personal scope for an individual's preferences, temporary session context for unfinished investigations, and a proposed shared entry for knowledge with a wider audience. Uncertainty about the audience should pause sharing.

LangChain's memory overview describes long-term memories stored in custom namespaces across conversations. That gives an application a way to organize personal and application knowledge. Our design recommendation is to treat audience as a separate authorization decision: a namespace called ‘private’ needs enforcement behind it.

Separate preferences, conventions and restricted facts

• Personal preference: Maya prefers explanations with a short example before the theory. Recall it when helping Maya, without changing how another engineer receives an explanation.
• Personal project context: Maya's test tenant has synthetic invoices for her current investigation. Keep the reference with Maya; check actual service permissions whenever the agent uses it.
• Team convention: Billing requests require an idempotency key, supported by the service contract and confirmed by its owner. Share the rule with the engineers responsible for that service.
• Restricted operational knowledge: A customer-specific incident workaround belongs only with its authorized responders. If the memory store offers only personal and workspace scopes, leave it in the restricted system of record.

Claude Code's documentation makes a related distinction for instruction files: ~/.claude/CLAUDE.md holds user preferences, project CLAUDE.md files hold team instructions shared through source control, and CLAUDE.local.md holds personal project preferences. It recommends adding the local file to .gitignore. Those locations are useful conventions, but repository sharing and file access still determine exposure.

Keep approved procedures in an instruction or skill workflow with its own review. A remembered remark about how Maya handled one incident should remain an observation until someone establishes that it is repeatable guidance. See keeping agent instructions in sync when that promotion produces a repository rule.

Promote a reviewed statement, not a transcript

Make sharing a separate operation that shows the proposed text and its destination audience. For the billing example, the candidate might read: ‘The billing API requires an idempotency key on invoice creation; confirmed against the current API contract by the billing maintainer.’ Exclude Maya's preferred response style, staging tenant, and the conversation that led to the discovery.

Record the author, reviewer, source reference, applicable service, and review date alongside that statement. These are suggested fields for your memory design. They let a teammate distinguish a maintained convention from a colleague's recollection. Require a new review when an edit changes the audience or turns an observation into a requirement.

Give automatic extraction a conservative destination. An extractor can propose a team entry without being allowed to publish it. Repetition across several private conversations should not automatically count as permission to share their contents. Several people reporting a workaround also does not establish that the workaround is approved.

Promotion creates another retained copy. Keep a relationship to the original so correction or deletion can identify the shared derivative. Decide explicitly whether deleting a personal entry should also withdraw its shared version; a reviewed engineering rule may have acquired an independent source by then.

Enforce ownership where memory is read and written

Resolve the person and workspace from authenticated identity. Check that identity for list, search, direct reads, updates and deletes. Apply audience restrictions before selecting recall results; withholding a private entry's body while exposing its title or search snippet still reveals context.

For a small PostgreSQL example, assume each person connects through a distinct ordinary database role with appropriate table grants. This policy binds private rows to that role:

CREATE TABLE personal_memory (
  owner_name text NOT NULL,
  memory_key text NOT NULL,
  body text NOT NULL,
  PRIMARY KEY (owner_name, memory_key)
);

ALTER TABLE personal_memory ENABLE ROW LEVEL SECURITY;

CREATE POLICY own_memory ON personal_memory
  USING (owner_name = current_user)
  WITH CHECK (owner_name = current_user);

PostgreSQL documents USING for row visibility and WITH CHECK for proposed inserted or updated rows. Table owners normally bypass these policies; superusers and roles with BYPASSRLS always do. Use a restricted runtime role. With one pooled database identity, current_user cannot distinguish application users; enforce authenticated application identity separately. Team rows also need a membership policy.

Recall both scopes without confusing their authority

When Maya asks about invoice creation, retrieve relevant personal and authorized team entries separately, preserving their scope and provenance in the context supplied to the agent. Her preference can shape the explanation; the reviewed billing convention can inform the implementation. Neither should silently acquire the other's authority.

Define conflict handling for specific categories. A personal formatting preference can govern conversational replies, while the repository's reviewed formatter configuration governs committed code. If Maya remembers that idempotency keys are optional but the maintained API contract says otherwise, have the agent inspect the contract and flag the stale memory for correction.

Use the same audience boundary for recall caches and generated summaries. A cached answer containing Maya's staging reference must not become another engineer's recall result merely because both asked about billing. Key cached context to its authorized audience and invalidate it when membership changes.

A CI agent needs an explicit machine identity and an authorized shared scope. Do not give it Maya's personal credential to obtain the team's conventions. When a teammate leaves, remove their access while preserving independently maintained team knowledge. Handle their personal entries under the chosen memory retention and deletion policy.

Keeping the scopes distinct with SPYN3

SPYN3 makes Memory & skills opt-in per workspace. Personal memories live under spyn3://me/memories/…; shared memories live under spyn3://workspace/memories/…. Reading requires call:tools; writes require the separate write:memory permission. Every memory write is audit-logged with its key or agent, and recalled memories are labelled as recorded data. Start by deciding which entries belong in each scope; a shared path still needs an editorial decision about what the team should retain.

Test with two people and one machine identity

Use synthetic entries whose contents make accidental sharing obvious: Maya's private staging reference, Leon's preferred explanation format, and a reviewed billing convention. Exercise every memory interface with both human identities and the CI identity. Useful acceptance cases include:

1. Maya recalls her own preference and the billing convention. Asking for Leon's exact memory path yields no private content or descriptive snippet.
2. Leon searches for Maya's unique staging reference and receives no matching personal entry, including through cached answers.
3. The CI agent reads the approved shared convention and cannot inherit either person's personal scope.
4. A read-only credential cannot update Maya's preference or publish a shared convention through an alternate write operation.
5. After sharing a reviewed billing statement, another teammate receives that statement without Maya's tenant reference or surrounding transcript.
6. After removing membership, fresh reads and cached recall stop returning the former member's authorized team context.

Repeat the relevant cases when changing extraction, search, or caching. The boundary should remain observable even when two agents use the same model and ask identical questions: each receives context selected for its authenticated audience.