Sharing across multiple agents and applications
Combine workspaces, applications, visibility and facets so shared rules reach everyone while app-specific and private notes stay contained.
Problem: Several agents (e.g. planner, backend, frontend, reviewer) and several applications run in the same organization. Shared rules should be visible to everyone; application-specific decisions shouldn't pollute other applications; an agent's own notes shouldn't be visible to the others.
Solution: Use Agent Memory's four separation tools together:
| Tool | What for? | Access boundary? |
|---|---|---|
| Workspace | Separate memory per project/organizational unit. | Yes |
| Application | Application-specific memory + a shared pool within the same workspace. | Yes (the shared pool is open to all) |
Visibility (private, user, workspace) | Who sees each memory. | Yes |
| Facet | A topic label independent of the application (e.g. auth, payments). | No, filter only |
1. Design the layout
Workspace "shop-platform"
├── Shared pool → stack, coding rules, error format (all applications see it)
├── Application "storefront" → storefront-specific decisions
└── Application "billing" → billing-specific decisions
facet "invoicing", "refunds" → topic split within billingRule: an agent bound to an application sees its own application's memories and the shared pool; it doesn't see another application's application-specific memories.
2. Give each agent its own key
In the console (API Keys), create a separate key for each agent:
| Agent | Application binding | Bound agent name | Permissions |
|---|---|---|---|
| Planner | — (shared pool) | planner | read, write, feedback, curate |
| Billing backend agent | billing | billing-backend | read, write, feedback |
| Reviewer agent | — | reviewer | read, feedback, share |
Binding keys to agent names makes it reliable who wrote each memory and keeps private notes separate. A key can't act as an agent it isn't bound to (403).
The application comes from the key's application binding.
3. Write to the right place
- Shared rules → with the shared pool key, default
visibility(workspace). - Application-specific decisions → with the application-bound key.
- An agent's own working notes →
visibility: "private". Other agents in the same workspace can't see, read or delete the memory. - Topic split →
add_memory(..., facet="refunds"); in search,search_memory(..., facet="refunds")returns only memories in that facet.
If a private note later needs to be shared with everyone, the owning agent widens its visibility with the share permission:
share_memory(memoryId="<id>", visibility="workspace")4. Shared rules across workspaces
Different workspaces don't see each other's memories. For rules that should apply across the organization:
- When the same decision/pattern shows up in several projects, consolidation produces a tenant-wide rule candidate.
- A tenant admin approves it in Settings → Promotions (as a floor if needed).
- The approved rule enters the context of every project.
visibility: "tenant" does not move a memory into other workspaces; use this approval flow for organization-wide sharing.
5. Who wrote what, who saw what?
- Memories carry
agentId,actorId,ownerAgentId,applicationIdandtags.facet; memories written via MCP also carry the client identity (theclient_idtag). - The change feed records sharing and promotion events (see Webhooks and change feed).
explain_memoryshows how many times a memory entered context and was used.
Caveats
- Facets and tags are not access boundaries; every agent in the same application can search all facets.
runIdis a namespace; if another agent searches with the samerunId, it can see that run's visible memories. Write sensitive notes asprivate.- Relation and supersession links are workspace-level; a supersession across applications may be possible.