Where your agent's memory actually lives

Where does the data live?

The database is in Frankfurt, and the table lists the rest honestly. We deliberately do not say "everything in the EU": the service itself runs on Cloudflare's global network, and for Cloudflare the safeguards for transfers to the USA described in our privacy notice apply.

What happens to names and email addresses?

They are replaced by placeholders before anything is stored. A deterministic tokenizer always detects email addresses, phone numbers and IBANs on its own. It recognizes names once they are known: when the agent tagged them as a person while storing, or after the nightly check has found them. The plaintext goes into a vault, encrypted with a key of its own.

The librarian model that reworks the memory at night reads the placeholders instead of those values. On recall, plaintext is restored only for keys with the personal data permission. In the dashboard you decide for each key whether it gets it. Keys from an agent's self-signup do not have it.

We are open about where the protection ends. A name that appears untagged in free text for the first time is still unknown and can reach the model. That is exactly what the nightly check looks for: whatever it finds is replaced everywhere, retroactively, and reported in the morning briefing. Recall search queries go through the same tokenizer, so there too only what is already known gets replaced. And two fields are stored exactly as sent: the payload of /ingest and the key of remember. Keep personal data out of both.

How does deletion work?

By destroying the key rather than chasing the rows. Every person in the vault has their own encryption key. Destroy it and every place in the live memory that uses that placeholder becomes unreadable at once: in the knowledge graph, in the raw experiences and in the archive. This is what makes an Article 17 request answerable in a system that has copied and consolidated data over months.

There are three levels. The agent forgets a single entry with forget, or you click Forget in the dashboard. You erase a person by destroying their key, with forget or with one click under Personal data. You delete a whole memory yourself in the dashboard, or we erase it by hand on request to accounts@tulimoa.com. Experiences, knowledge, vault, keys, connected apps and archive are then gone. Payment records are kept as the law requires.

Who can read a memory?

Each API key belongs to exactly one memory, and every query asserts that boundary explicitly rather than relying on a filter someone might forget. Only a checksum of the key is stored. In the dashboard you revoke a key with one click, and the revocation applies from the next request.

Several agents can share one memory, each with its own key and name. The timeline shows which agent remembered what. None of them ever sees another memory. Apps like claude.ai or ChatGPT connect by signing in, to exactly the memory you pick on the consent page. You see them in the dashboard and disconnect them with one click.

What is not done yet?

A few things, and we would rather list them than let you find out later. There is no countersignable data processing agreement for customers yet. Multi-factor authentication for dashboard accounts is not built. There is no full export of a memory yet. There is no SOC 2 report and we are not going to imply otherwise.

If a compliance question blocks you, write to hello@tulimoa.com and you will get a straight answer about whether it exists today.