Skip to main content
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.
If you only have one Instance, or you’re happy with full sharing, you don’t need this page; the default already does that.

​
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.
Consent is an AND: a grant alone is not enough if the source has opted out, and shareable alone shares nothing without a grant (or a parent link). This is the deliberately safe default for a privacy control.

​
A worked example

Say one client runs three Instances under the same customer: You switch the policy to Isolated and configure:
  • A grant inst_sales → inst_support (sales may read support’s memories).
  • inst_sales marked not shareable (sales conversations are private).
Resolving each viewer against the rule “V sees S iff S is shareable AND (V→S granted OR S is a child of V), plus V always sees itself”: Two things to notice:
  • inst_manager sees inst_support for free: the parent → child edge is automatic; no grant needed.
  • Even if you later granted inst_manager → inst_sales, the manager still would not see sales: inst_sales is not shareable, and the source-side opt-out wins over any grant.
Throughout, every Instance still retrieves any client-scoped shared knowledge; isolation only ever scopes the per-customer memories.

​
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.

​
Configuring it from the CLI

To manage the policy as code (CI, scripted onboarding) instead of clicking the matrix, use the Synap CLI. It edits the same policy the dashboard does.
set-mode, grant, revoke and share read the current policy first and send its version back with the change. If someone edits the policy at the same time, the command fails and writes nothing instead of overwriting their edit; run it again. Changes apply to the next retrieval. Any member can run visibility get; changing the policy needs an Owner or Admin login.
To turn isolation off again, run maximem-synap visibility set-mode shared_all. The mode gates everything: in shared_all, grants and shareable flags are ignored and every Instance sees every other.

​
What this does and doesn’t cover

  • Read-side only. Instance Visibility decides what a fetch returns. It does not coordinate the write-side, e.g. propagating a correction or supersede from one Instance to another that can see it. That cross-Instance write coordination (and the related lineage/consolidation work) is a separate, planned capability.
  • Direct children only. A parent sees its immediate sub-agents. Multi-level (grandchild) transitivity is not yet derived, so grant those edges explicitly if you need them today.
  • Within one customer. Visibility governs sharing between Instances of the same customer. It never opens memory across different customers; customer isolation is unchanged and absolute.
  • Filters, doesn’t delete. Revoking a grant or marking an Instance unshareable hides memories from retrieval; the data is untouched and reappears the moment you restore access or switch back to Shared.

​
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.
Instance Visibility governs what is returned at retrieval (read-side). It does not yet coordinate the write-side, e.g. propagating a correction from one Instance to another that can see it. That coordination is a separate, planned capability; today, isolating Instances only affects which memories a fetch returns.