Skip to main content
← All use cases
support_bot_scoping.pymulti_agent_shared_space.py

​
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

  1. Write a fact as “agent A”, read it back with no agent scope. It should appear.
  2. 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.
  3. Invite a second account as viewer and confirm a write from them is refused with space_read_only. This one needs a second Anona account — a separate sign-up, with its own API key — because the refusal is about who is writing, and one key cannot be both the owner and the invitee.
  4. 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.