Skip to main content
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

Org

The tenant boundary, resolved from your API key. Nothing crosses it. Every read and write is confined to the org the key belongs to.

Agent

Who wrote it, from the X-Vex-Agent header. Used for attribution, and for private memory when you ask for it.

Space

A named subdivision within the org — one per project, service, or workstream. Managed with the space tool.

​
The visibility ladder

Where a memory lands depends on how it was written, not on a parameter you have to remember.

​
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.
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:
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.
Then pass the slug on reads and writes:
Omit space and you are working against the org’s default store. See the space tool for list, create, info, and switch.

​
Narrowing a recall

recall also accepts a project filter, which narrows results without needing a separate space:
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: 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.