By default, every Instance under the same client (and same customer) shares
memory. Instance Visibility lets you turn that sharing into something you
control — per-Instance and directionally — without moving any data. It is
opt-in: until you set a policy, nothing changes.
When you need this
You have more than one Instance (agent) under a single client and you want to decide who reads whose memories. For example:- A support agent and a sales agent under one client that should not read each other’s conversation memory.
- A manager agent that should see its sub-agents’ memories, but not the other way around.
- A shared knowledge Instance whose memories everyone may read, alongside private Instances that keep to themselves.
The default: everything shared
Synap stores each memory tagged with the Instance that created it, but retrieval has historically ignored that tag — so any Instance under the same client + customer could retrieve any other’s memories. That remains the behaviour until you create a policy. Concretely:- No policy / “Shared” mode → every Instance sees every other Instance’s memories (today’s behaviour, byte-for-byte). There is zero performance or result change for clients who never touch this feature.
- “Isolated” mode → an Instance sees only itself, plus whatever you explicitly grant.
Visibility applies to customer-scoped memories (the per-user/per-customer
memories your agents create). Client-scoped shared knowledge stays visible
to everyone regardless of policy — isolating Instances never hides your
client-wide knowledge base.
The one rule
Under Isolated mode, an Instance V can read another Instance S’s memories iff:S is marked shareable AND (V → S is granted OR S is a sub-agent (child) of V).An Instance always sees itself. That’s the whole model — a source-side opt-out (
shareable), a viewer-side grant (the matrix), and an automatic
parent → child edge.
Setting it up on the dashboard
Open Dashboard → Visibility.1
Choose the mode
Toggle between Shared (default — everyone sees everyone) and
Isolated (no one sees anyone unless granted). Switching to Shared greys
out the grid; nothing below it applies until you switch back to Isolated.
2
Grant who sees whom (the matrix)
In Isolated mode you get a grid. Rows are viewers, columns are sources.
Tick the cell at (row V, column S) to let V read S’s memories. Grants
are directional — ticking V→S does not let S read V. The diagonal
(an Instance seeing itself) is always on and not editable.
3
Mark sources shareable (or not)
Each Instance has a Shareable toggle. Turning it off makes that
Instance’s memories invisible to everyone else — even Instances you’ve
granted. It’s a source-side veto that overrides any grant, so it’s the
safe way to quarantine one Instance’s memory without editing the matrix.
4
Parent → sub-agent is automatic
If an Instance is registered as a sub-agent of another (a parent-child
link), the parent automatically sees the child’s memories. Those cells show
pre-checked and locked in the matrix — they come from the agent topology,
not the grid, so you can’t un-tick them here. (The child does not
automatically see the parent.)
5
Save
Click Save. Changes take effect immediately for new retrievals.
Saving is protected against concurrent edits: if someone else changed the
policy since you loaded the page, you’ll get a “policy changed, please
reload” prompt instead of silently clobbering their edit. Only Owner and
Admin dashboard roles can edit; others see the matrix read-only.
Good to know
- Safe by default. Doing nothing keeps full sharing. Isolation is something you switch on deliberately.
- Same customer. Visibility decides sharing between Instances of the same customer. It does not open memory across different customers — customer isolation is unchanged and still absolute.
- It filters, it doesn’t delete. Making S unshareable or revoking a grant hides S’s memories from a retrieval — the memories still exist and become visible again the moment you restore the grant or flip back to Shared.
- Tightening propagates fast. When you remove access, the change applies to the next retrieval — there’s no stale window where a just-revoked Instance can still read.