> ## 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.

# Subprocessors

> Third-party services that receive customer content, what reaches them, and on which requests.

This page lists the third parties that can receive customer content when you use
Anona Memory, and exactly which requests send it.

## TypeSafe AI

**Used for:** the decision model behind
[automatic space routing](https://docs.memory.anonalabs.com/guides/automatic-routing.md).

**Endpoint:** `https://api.typesafe.ai/v1/systemone`

### When content is sent

Only on a request that asks for routing, that is, one carrying `route: "auto"`,
and only when that request reaches the decision model stage of the cascade.
There are **two such requests, and they send different text:**

| Request | What reaches TypeSafe |
| - | - |
| A **routed write** — `route: "auto"` on `POST /v1/record` or `POST /v1/record/batch`, or on the MCP `record` tool | The content of the memory being filed |
| A **routed read** — `route: "auto"` on `POST /v1/retrieve`, or on the MCP `retrieve` tool | The text of the query being answered |

Both also send the space catalogue described below. Both ask the same single
question of the same endpoint: which of these spaces does this text belong to,
or should be searched for it.

**A request that names its `space_id` sends TypeSafe nothing.** So does a routed
request that is answered earlier by one of your own declared rules, and a routed
request made by an organization with no candidate spaces: in all of those cases
no request to TypeSafe is made at all. On a routed read, `fallback_space_id`
changes only where Anona looks when nothing fits — it does not change whether
the call is made or what it carries.

No other Anona surface calls TypeSafe. `POST /v1/reason`, the chat proxy,
document upload, the memory list, the graph and entity endpoints, and any
retrieve that names its `space_id` are all unaffected.

### What is sent

| Sent | Detail |
| - | - |
| On a write, the memory text | The `content` of the memory being routed. On `POST /v1/record/batch`, the content of up to the first 20 items, joined and truncated to 4,000 characters. |
| On a read, the query text | The `query` string of the retrieve, as you sent it. It is not truncated and not rewritten. |
| The space catalogue | For each candidate space: its id, and the description Anona renders for it (your charter and topics, plus the terms derived from that space's contents). |

The space catalogue is built the same way for a read as for a write, with one
difference: a read's candidates include spaces shared with you as a **viewer**,
because a viewer can read them, while a write's do not. Your organization's
default space is never a candidate on either path, and neither is any space
whose routing profile is disabled or which has no description yet.

Anona does not send API keys, memory ids, member identifiers, `user_id`,
`agent_id` or `session_id` values, tags, metadata, or any memory other than the
one being routed. On a read in particular, TypeSafe receives the question and
never the answer: no stored memory, no search result and no score from our own
retrieval is sent, and the only thing that comes back is a per-space suitability
figure. One caveat on identifiers: a space shared with you by another
organization appears in the catalogue under its qualified
`owner-slug:space-name` id, so that organization's slug is part of the space id
sent.

### Data handling

We have not independently verified TypeSafe's retention period, whether
submitted content is used to train their models, or which region processes a
request. We are not going to imply otherwise here: treat those three as unknown
to us, and read TypeSafe's own terms if they matter to you. This page is updated
when we have confirmed answers.

What is within our control, and is true today:

* **Nothing is sent unless a request asks for it.** Routing is opt in on every
  individual request, read and write alike. An account that never sends
  `route: "auto"` never has any content reach TypeSafe, and there is no setting
  that changes that.
* **The smallest useful payload.** One memory's text, or one query's text, and
  the descriptions of the spaces it could go to or be looked for in. Not your
  other memories, not your keys, not your end users' identifiers.
* **A routed query does not come to rest in our logs either.** Anona records the
  decision and the query's length, never the query text.
* **You can exclude a space** from the catalogue entirely with
  `auto_route_enabled: false`, so a space holding sensitive material need never
  be described to them. This applies to both paths: a space that is not a
  candidate is neither a routing target nor a search target.

If your organization requires that every subprocessor's terms be established
before use, do not use `route: "auto"` on anything. Naming a `space_id` on
every record and every retrieve keeps all routing decisions, all memory content
and all query text inside Anona.

### Turning it off

Automatic routing is opt in on every single request, read and write alike, so
not sending `route` is sufficient: nothing is ever routed on your behalf. To
make a space ineligible regardless, set `auto_route_enabled: false` on its
[routing settings](https://docs.memory.anonalabs.com/guides/automatic-routing.md#routing-settings), or delete its
routing profile. A space that is not a candidate is never described to TypeSafe.


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