Cross-agent memory sharing

An agent can retrieve records written by another agent when both target the same authorized storage boundary and use supported operations. Retrieval also depends on the selected query and on any asynchronous extraction or indexing needed for the result.

On NAMS, the workspace is the service’s tenancy boundary. A workspace key is bound to that workspace; an admin key selects a workspace according to the authentication contract. On Bolt, access depends on the Neo4j database and credentials granted to the caller.

Within that boundary, conversation IDs organize messages and trace records. Entities can be shared across conversations. A caller with broader read access can inspect more than one conversation, so separate IDs must not be described as private agent notebooks.

See Authentication and Backend capabilities for the exact boundaries.

user_identifier is not accepted or enforced by every memory method. The supported fields and filters differ by backend and operation. A field stored in metadata does not automatically become a predicate on every read.

In particular, the current Bolt semantic message search accepts a session_id argument but does not apply it as a conversation filter. Do not use that argument to promise isolation or correct it by filtering only a limited result page in application code. Such filtering can miss relevant results and does not create an access-control boundary.

For a multi-user application, use the documented workspace/database boundary and enforce application authorization before calling memory operations. Follow Multi-tenant memory and the capability table for the supported per-operation filters.

Python’s NAMS REST transport and the TypeScript SDK can address the same hosted workspace. The Python Bolt backend connects directly to Neo4j and is not the same transport. The TCK bridge is a separate conformance-testing interface.

Sharing requires the same hosted endpoint and workspace, not merely the same environment variable names or user label. SDK return shapes can differ, and a method available on Python Bolt may have no hosted counterpart. Use the REST contract and the capability table when designing a cross-language path.

Each process can hold its own client. The client is a connection to shared storage, not a private copy of the graph. Authorization and write ownership remain application design decisions.

An ingestion process can store source messages. A chat process can retrieve relevant supported records after any required extraction completes. An analytics process can inspect permitted records and produce summaries.

These processes need not call each other directly, but they need a shared contract for identifiers, provenance, and readiness. A chat process must not assume that an entity write also created preferences, facts, or relationships unsupported by its backend. See NAMS quickstart for a concrete hosted path.

Two agents can try to describe the same entity. Resolution and deduplication help identify candidates, but they do not substitute for a concurrency policy or guarantee that every simultaneous write is merged correctly.

Decide which application owns an update, retain source evidence, and distinguish repeated requests from separate observations. Backend-specific resolution outcomes and review workflows belong in Resolution and deduplication and the long-term API reference.

Trace records can be associated with a conversation or session, and a session-specific retrieval operation can select that subset. This association is useful for reviewing one task; it is not a promise that other authorized callers cannot query those records.

An orchestrator’s broader audit access must be intentional. The recorded trace contains only the actions, observations, and outcomes the application or integration captures. Follow Audit reasoning for the supported read path.

Shared records can reduce conflicting copies of knowledge and retain a common provenance trail. They do not guarantee that every agent immediately holds the same context: agents may query different subsets, cache results, or read before asynchronous processing completes.

Adding agents therefore requires checking authorization, identifiers, lifecycle hooks, and concurrent writes, even when the underlying storage remains the same.