Multiple agents need enough shared context to avoid contradiction, but they should not all receive the same memory. A coding agent, support agent, and voice agent have different identities, permissions, deadlines, and context budgets. Coherence comes from governed sharing between bounded spaces—not from a single universal prompt.
One bucket creates accidental authority
If every agent reads and writes the same undifferentiated store:
- a low-trust inference can become a high-impact operational fact;
- private context can cross team or customer boundaries;
- a voice summary can crowd out the coding decision a developer needs;
- one poisoned tool result can influence unrelated workflows;
- deletion and retention become difficult to scope.
Isolation alone is not enough either. Completely separate stores force people to repeat stable decisions and let agents drift into contradictory local histories.
Context Spaces as the design unit
A Context Space is the hardened term for a bounded context domain. The intended contract uses stable principals, positive grants, one authoritative placement for each record, and explicit composition when a view needs selected context from more than one space.
Space: customer-support
principals: support agent, voice agent
data: consented customer interactions
Space: product-engineering
principals: coding agent, release agent
data: decisions, contracts, build receipts
governed view: incident-response
selected support evidence + selected engineering state
Composition should reference allowed context rather than copying every memory into a common bucket.
Coherence is not identical context
Two agents can remain coherent while receiving different packets. They need agreement on governing facts and source authority, not the same token sequence.
For each consumer, define:
- stable principal identity;
- spaces it may read or write;
- entities and tasks it is serving;
- context budget and timing deadline;
- facts that require shared authority;
- evidence and feedback it may produce;
- teardown and revocation behavior.
The server should eventually own those decisions. Clients should request context for a declared principal/task, not mix spaces through prompt instructions.
Current Northsun (formerly Mnemix) boundary
Northsun has tenant-scoped storage and governed evidence/fact substrate. The public dashboard does not currently expose “Memory Bank 1/2” controls, and the frozen caller REST API has no Context Spaces field. Unified cross-agent composition and production access-control semantics remain design-gated.
The hosted MCP endpoint can be connected to several clients, but connecting multiple agents to one key does not itself prove safe shared memory, per-agent grants, or cross-session coherence. Evaluate each observed tool contract and tenant path separately.
What must graduate
A customer-facing Context Spaces capability needs:
- Explicit create/list/grant/revoke semantics.
- Stable principal identity rather than display names.
- Negative tests proving unauthorized cross-space reads fail.
- Governed composition that does not duplicate authority.
- Audit receipts for placement and access decisions.
- Migration and rollback rules for moving a record.
- Dashboard and API parity.
Until then, use Context Spaces as the design contract and MCP server for the current agent-tool boundary.