> ## Documentation Index
> Fetch the complete documentation index at: https://docs.memory.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](https://docs.memory.anonalabs.com/use-cases/overview.md)

[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)

## 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](https://docs.memory.anonalabs.com/api-reference/spaces.md).

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

> [!WARNING]
>
> **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).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.