> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anonalabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Support memory the whole team shares
> What one agent learns on a ticket, the next one already knows — across reps, shifts and organisations.
[← All use cases](/use-cases/overview)
## 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.
```python theme={null}
client.record(
space_id="support",
content="Acme is on the self-hosted runner setup; the standard proxy fix does not apply to them.",
user_id="acme-corp",
)
```
This is the same mechanism as
[Support agent that knows each customer](https://github.com/anonalabs/Anona-Memory-SDK/blob/main/examples/support_bot_scoping.py)
— 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.
```python theme={null}
context = client.get_context(
space_id="support",
query="why did the proxy fix not work for them?",
user_id="acme-corp",
max_tokens=800,
)
```
`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](/api-reference/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`.
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`](https://github.com/anonalabs/Anona-Memory-SDK/blob/main/examples/support_bot_scoping.py),
[`multi_agent_shared_space.py`](https://github.com/anonalabs/Anona-Memory-SDK/blob/main/examples/multi_agent_shared_space.py).