> ## Documentation Index > Fetch the complete documentation index at: https://docs.klio.tech/llms.txt > Use this file to discover all available pages before exploring further. # Scope and spaces > Strong scope is the feature. Random global memory everywhere is the failure mode. The most common objection to shared agent memory is the right one: memory that leaks everywhere is worse than no memory. An agent working on your billing service should not surface a note from an unrelated prototype, and one team's context should not appear in another's. Klio answers that with three separate axes. ## The three axes The tenant boundary, resolved from your API key. Nothing crosses it. Every read and write is confined to the org the key belongs to. Who wrote it, from the `X-Vex-Agent` header. Used for attribution, and for private memory when you ask for it. A named subdivision within the org — one per project, service, or workstream. Managed with the [`space`](/tools/space) tool. ## The visibility ladder Where a memory lands depends on **how it was written**, not on a parameter you have to remember. | `scope` | Who can recall it | What lands there | | ---------------------- | ---------------------------------------- | ----------------------------------------------------------- | | `private` | **Only you.** Not teammates. Not admins. | Everything your editor captures passively | | `project` | Members of that project, and org admins | Explicit writes made while a project is set | | `org` | Everyone in the org | Explicit writes — `remember`, `decide`, `plan`, `note` | | `agent` *(deprecated)* | The agent identity that wrote it | Superseded by `private`. Still readable; no longer written. | ### Capture is private, sharing is deliberate Passive capture — the hooks that record what your agent did — lands in **your** private scope. Nobody else can read it, including an organisation administrator. Calling a write tool is the act of sharing. `remember`, `decide`, `plan` and `note` write to the team, or to a project when one is set. ```json theme={null} { "content": "The staging deploy needs the VPN on" } ``` That goes to the whole org, because you chose to write it. ### Recall spans everything you are entitled to A normal `recall` searches your private memories, the projects you belong to, and the org's shared brain — in one call. Ask for `scope: "private"` to narrow to your own. ### Promoting something you captured When a passive capture turns out to be worth sharing, promote it: ```json theme={null} { "memory_id": "60a0fa87-…", "to": "org" } ``` `share` moves it from your private scope to the team's, and keeps you recorded as the author. Only the owner of a memory can share it. **Private means private.** There is no administrator override, no support path and no break-glass. An organisation administrator sees every org and project memory and a single org-wide storage total — never the contents of anyone's private scope, and never a per-person count of it. **`agent` scope is not a privacy boundary** and never was. It resolves against the `X-Vex-Agent` header, which the client sends and can set to any value. It is deprecated in favour of `private`, which is enforced against your verified credential. Existing `agent`-scoped memories remain readable; nothing new is written there. ## Spaces A space is a named store within the org. Use one per project so a question about the billing service does not pull answers from the marketing site. ```json theme={null} { "action": "create", "name": "Billing service", "slug": "billing" } ``` Then pass the slug on reads and writes: ```json theme={null} { "content": "Invoices are generated nightly at 02:00 UTC", "space": "billing" } ``` ```json theme={null} { "query": "when do invoices generate?", "space": "billing" } ``` Omit `space` and you are working against the org's default store. See the [`space` tool](/tools/space) for `list`, `create`, `info`, and `switch`. ## Narrowing a recall [`recall`](/tools/recall) also accepts a `project` filter, which narrows results without needing a separate space: ```json theme={null} { "query": "auth error handling", "project": "api", "limit": 5 } ``` Clients can additionally declare a workspace-wide project through the `X-Vex-Project` header. A project is identified by whichever of these it has: a git remote URL when the workspace is a git repo, or the repository root directory path when it is not. Both resolve. Earlier, only a git remote or a project's display name looked itself up correctly — a non-git project fell back silently to org-wide recall, with nothing to indicate why its memories were not showing up filtered. Directory-path projects now resolve the same way git-remote ones always did. Filtering by project is additive, not subtractive: recall fills the result set with that project's memories first, then — if the limit has not been reached — fills the remaining slots with unfiled memories (nothing was ever explicitly attached to a project). Memories filed under a *different* project never come back. There is no third pool for "everything, ranked, regardless of project." Project resolution **fails open**. If the header is missing, the identifier is unknown, or the lookup errors, the request falls back to org-wide rather than returning nothing. That keeps a misconfigured client working, but it means the header is a convenience — never a security boundary. The boundary is the org. This is the same story as [spaces](/tools/space#spaces-are-not-a-tenancy-boundary): narrowing by project is a relevance filter. Anyone holding the org's API key can still recall any project's memories by asking for them, or by omitting the filter entirely. ## Choosing a layout One org, one space per repo. Set `X-Vex-Project` per workspace, or pass `space` explicitly. Skip `agent` scope entirely — with one person, shared is the point. One org, spaces per service or bounded context. Set `X-Vex-Agent` per tool so you can see whether a decision came from Claude Code or Cursor, and who was driving. One org per client, not one space per client. Spaces subdivide; they are not a tenancy boundary. If two bodies of work must never see each other, they need separate orgs and separate keys.