Context Spaces
Status: architecture with an inert database substrate. No public Context Spaces API or dashboard control is available yet.
A Context Space is Mnemix's intended boundary for deciding which memories a principal may use. It turns the informal idea of “memory bank 1” and “memory bank 2” into an explicit governance model: place a memory in one space, identify the agent or application asking for it, and require a positive grant before that memory can participate in recall.
What problem do Context Spaces solve?
A tenant may run several agents that should not all inherit the same context. A support agent may need customer history. A coding agent may need repository decisions. An executive assistant may need selected information from both—but not every raw memory from either.
Tenant isolation alone cannot express those choices. It keeps one customer away from another customer, but it does not decide which of one customer's agents may see which of that customer's memories.
The intended model
| Concept | Question it answers |
|---|---|
| Tenant | Which customer owns this data? |
| Environment | Is this production, staging, or development? |
| Context Space | Where is this memory version placed? |
| Principal | Which human, application, service, or maintenance process is acting? |
| Grant | May this principal read from this space for this purpose and surface? |
| Placement | Which single space contains this memory version? |
The current substrate follows three important rules:
- A retrievable memory version belongs to exactly one Context Space.
- Access is positive-only: no matching grant means no access.
- Authority must be evaluated before ranking, pagination, limits, or aggregation so unauthorized candidates cannot influence the result.
Separate agents, shared agents, and governed mixing
The architecture supports three distinct intentions:
- Separate context: place two agent groups in different spaces and grant each principal access only to its own space.
- Shared context: grant several stable principals access to the same space when they genuinely need one memory substrate.
- Governed composition: allow an authorized view to draw selected context from more than one space without copying every memory into a common bucket.
The third model is what makes selective mixing safe. It should be an explicit, auditable read policy—not an API key convention and not a hidden similarity-search shortcut.
Why an API key should not define a memory bank
Credentials rotate. Authority should remain understandable when they do. The architecture therefore separates a stable principal from the credential used to authenticate it. Rotating a key should not silently create a new agent identity, move memories, or broaden access.
What exists today?
The repository contains the inert Context Spaces, principals, grants, and placement substrate. “Inert” means current public recall routes do not consult those tables. The schema can be inspected and tested without changing what a live request returns.
Today, use the stable caller-memory REST lifecycle described in the quickstart, or evaluate the explicitly evolving context loop through the MCP server. Neither path should be described as a public Context Spaces implementation.
What must ship before this becomes a product feature?
Publication of a setup guide or dashboard workflow requires all of the following:
- a public contract for creating and naming spaces;
- a credential-to-principal binding lifecycle;
- explicit placement behavior for new and existing memories;
- grant creation, revocation, expiry, purpose, and surface controls;
- a governed cross-space composition contract;
- audit receipts that explain why a memory was or was not visible;
- tenant-isolation, fail-closed, revocation, and leakage tests;
- dashboard and API behavior observed in the deployed environment.
Until those gates pass, Context Spaces are a precise architecture direction—not a feature customers should be told to configure.
Related concepts
Choose Northsun as your agent memory layer.