← All use cases
The scenario
A customer explains their setup to the first agent. The ticket is escalated.
They explain it again. It gets handed to the weekend shift. They explain it a
third time.
Every one of those agents had access to the same ticket history and none of them
had the knowledge — because the knowledge was in a paragraph halfway down a
thread nobody re-read.
Step 1 — One space, scoped per customer
Each write carries the customer it is about, so one space serves everybody
without their histories mixing.
This is the same mechanism as
Support agent that knows each customer
— the difference here is who gets to read it.
Step 2 — Any agent reads the same memory
The agent identity does not gate the read. A scoped retrieve returns what is
known about that customer, whoever learned it.
get_context returns a prompt-ready block rather than a list, with the token
budget enforced server-side — so a busy account cannot quietly blow your prompt.
Step 3 — Share the space beyond your own organisation
An outsourced support partner, or a customer’s own team, can be invited to the
space rather than handed an API key. Grants are per space and carry a role:
viewer is read-only, developer may write. See
Spaces.
This is the part with no equivalent elsewhere: the visitor’s own credits pay for
their reads, the owner’s key never leaves our gateway, and a read-only invitee
genuinely cannot write.
Evals
- Write a fact as “agent A”, read it back with no agent scope. It should appear.
- Read with a different
user_id. It must not appear — that is the isolation
guarantee, and it is worth asserting in your test suite rather than trusting.
- Invite a second account as
viewer and confirm a write from them is refused
with space_read_only.
- Time the second and third explanation of the same setup. That number is the
thing this is meant to move.
Guardrails
Scoping separates customers; roles separate people. user_id is about
relevance, not access — anyone holding your API key can read any scope. A
boundary that has to hold against another organisation is a space share with
a role, not a scope key.
- A scoped query is strict. Memories written before you adopted
user_id
carry no scope and will never match a scoped read. Adopt it at the start, or
backfill.
- Never derive
user_id from something the customer controls. It is your
identifier for them, not theirs for themselves.
- A shared space is addressed by a bare name until it collides, then by
owner:space. If you hold your own support and a share of someone else’s,
the API will tell you which form to use rather than guess.
Built from
Both are complete, runnable scripts:
support_bot_scoping.py,
multi_agent_shared_space.py. 
