Private vs Shared Agent Memory: What Should Another Person's Agent Be Allowed to Recall?

An engineer’s coding agent remembers a workaround that fixed a local integration test. The next day, a colleague’s agent encounters a similar error. Sharing the previous episode could save time—unless the workaround depended on a temporary secret, a specific dependency version, or a customer environment the second agent cannot access. The question is not merely whether memory can be shared. It is which memory, with whom, under what conditions, and with what authority.

Private memory and shared memory serve different purposes. Private continuity may help a person or agent resume work. Shared organizational knowledge must be safe and useful for several participants over time. Neither is intrinsically better; the danger comes from moving between them without evaluating provenance, relevance and permissions.

Three kinds of information are easily confused

Working state includes notes, draft plans and recent tool results; it often expires with the task. Episodic memory preserves an experience and its conditions: “API configuration B failed against service version 3.” Approved shared context captures a rule or decision the organization wants others to follow: “Use configuration A for production service version 3 until the migration completes.” These items may begin with the same incident, but they carry different trust levels.

If Agent A learned that a timeout of 90 seconds solved a test on a developer laptop, Agent B should not automatically apply it to production. The episode may be useful evidence. It becomes an approved policy only after someone verifies where it applies and whether it creates unacceptable cost or risk.

Model sharing as a promotion workflow

First capture the episode with source, actor, timestamp, environment and any privacy classification. Next decide whether the lesson is reusable or merely local. If it might affect shared behavior, propose a candidate decision or rule. An authorized reviewer examines evidence, rejects or qualifies the candidate, and approves a scoped record when appropriate. A downstream agent can then receive the approved rule while still being able to inspect the originating episode if permissions allow.

Crucially, approval does not make a memory timeless. If the dependency upgrades or a security requirement changes, the record needs a new status or successor. “Forget” can be a feature when context is expired, wrong or no longer authorized.

A security-sensitive example

Imagine a customer support agent records that a particular account required manual billing intervention. A sales agent could benefit from knowing an account has an open issue, but not from receiving private billing details. A shared summary may be permitted within a narrow scope while the raw evidence remains restricted. Storing both in one vector database without user and task boundaries is not a sharing policy; it is a leakage risk.

The same logic applies to engineering. A security incident may contain useful guidance about how to validate a fix, but the supporting logs could expose internal addresses or credentials. A reusable decision can reference the evidence without distributing the raw source to everyone.

Where DM helps—and its current boundary

DM keeps reviewed Decisions, Rules and Skills with organizational scope, ownership and evidence so that humans and connected agents can retrieve the relevant approved context. The review workflow makes explicit what becomes trusted rather than assuming that writing to shared storage confers authority. That is valuable for teams using several agents or changing personnel: one agent’s observation can contribute to team learning without automatically becoming a rule.

DM also has a partial Mem0-based memory integration, subject to entitlements and not enabled by default. This article should not be read as a claim that universal shared episodic memory is already active. DM likewise does not replace identity, access control or secret-handling responsibilities in the source systems and agent runtimes.

Test the boundary before scaling sharing

Use a fictional but realistic incident containing one useful lesson and one restricted fact. Ask whether Agent B can retrieve the lesson while being denied the restricted detail, and whether the lesson is labeled as an episode or approved rule. If the system cannot distinguish those outcomes, improve the memory policy before increasing the number of agents.

Sources

• Anthropic: effective context engineering for AI agents
• Model Context Protocol: security best practices