Skip to content

Legal

Last updated August 19, 2026

Privacy policy

MemoryAgent stores conversations on behalf of the teams that send them. This page is the whole of it: what we hold, where it lives, how long it stays, and what is left once you delete it.

Who we are

MemoryAgent is run by PackageFactory. For the account you hold with us — your name, your email address, your usage figures — we decide what happens to that data, so the law calls us the controller. For the memory content your systems send us, you decide and we act on your instructions: you choose what is stored and why, and we hold it for you.

That split matters if you are storing memories about your own users. They exercise their rights against you, and we answer to you rather than to them.

How the roles work under the GDPR

What we hold

Six kinds of data, and nothing outside this list.

Account data.
Your name and email address, and a hash of your password. We never see the password itself.
Memory content.
The conversations you send and the durable facts we take out of them. This is the only category whose contents you chose.
Key details.
An API key is stored as a hash. We keep its first few characters, its label and the date it was created — never the secret itself, which is shown once at creation and cannot be retrieved afterwards.
Provider credentials.
If you store your own model-provider key with us, we encrypt it before writing it down and decrypt it only to pull facts out of your own workspace's conversations.
Usage records.
Counters and a note of each background job, kept so that quotas can be applied and so that you can see whether a job finished.
Technical logs.
Request identifiers, timestamps and error codes. An API key is never written to a log, never placed in a web address and never sent to an analytics or session-replay tool.

We do not sell data, we do not run advertising, and we do not use the content you store to train models.

Where it lives

Every workspace gets a space of its own, on machines in the European Union. Most services keep every customer's information in one big list and tell the two apart with a label on each entry. That works until one request forgets to check the label. We give you a space instead, so there is nothing else in it to confuse your data with, and no label to forget.

Your API key tells our servers which space it belongs to, and that is the only space it opens. A client never sends the name of a workspace, a place to look, or a filter — so there is no way to ask for someone else's data by asking differently.

How we keep customers apart

What we use it for

  • Running the service: storing what you send, taking the durable facts out of it, and giving them back when you ask.
  • Applying quotas, which is why usage is counted. Nothing is charged today.
  • Keeping the service working: finding faults, restoring from a backup, and looking into abuse.
  • Meeting obligations we cannot decline, such as answering a lawful order.

No item on that list is a polite word for a second use of your data.

Who else touches it

The companies that host our infrastructure necessarily handle the data, because it sits on their machines. When we pull facts out of a conversation, that text goes to a model provider for as long as the request takes. If you store your own provider key with us, that request runs on your account with them rather than ours.

We do not print a vendor list on this page, because it would go stale between edits. A current list of the companies involved is available on request through the contact form, and we will tell you before adding one that handles memory content.

We hand over data where the law requires it. If we receive a lawful order for your data we will tell you, unless we are forbidden to.

How long we keep it

Deleting a memory stops it coming back in a search straight away. The original conversation behind it stays until you delete the workspace itself, because that original is what lets the work be done again — reading a fact out afresh, or moving your memories onto a better model. Routine clean-up inside a workspace works the same way: it marks what is out of date, it does not destroy it.

Backups expire on a fixed schedule. Daily copies are kept for 6 days, weekly copies for 27 days and monthly copies for 89 days. A nightly portable copy is kept for 30 days.

Account data is kept while the account exists. The audit records described below are kept indefinitely, in the stripped-down form set out there.

Deletion, and what it actually does

Deleting a workspace removes everything in it, outright. It is not a flag, not a queue and not a hidden copy kept somewhere out of sight. It cannot be undone, and it gives up for good any chance of restoring those memories or of processing them again later.

Backups taken before a deletion still hold the data until they expire on the schedule above. That is the one gap between deleting and disappearing, and at the outside it closes in 89 days.

One record survives a deletion

An audit trail that can delete the record of its own deletion is not an audit trail.

We keep a record of what was done to an account: when it was created, when keys were issued, when a workspace was suspended, when one was deleted. That record is never deleted — not by you, not by us, and not by a deletion.

What identifies you is stripped out of those records in the same operation that deletes the workspace. Its name, its internal identifiers and any free text an operator wrote when they acted are all removed. What survives is the event and its timestamp — not who it was about.

We would rather state this here than have you find it. It is also what lets us answer, years afterwards, that a deletion happened and when.

Your rights

Access, correction, deletion, restriction, portability and objection all apply. The GDPR page sets out what each one means here in practice — including the fact that an export is produced on request rather than by pressing a button.

GDPR and data processing

Children

MemoryAgent is a developer service and is not aimed at children. We do not knowingly hold an account for anyone under 16. If the memory content you send is about children, you are responsible for it and the legal basis is yours, not ours.

Security

How customers are kept apart, how keys are handled, how the credentials we hold for you are encrypted, and how backups are taken and proven are all described on their own page, in enough detail to be checked rather than believed.

Security and separation

Technical and organisational measures

For a data-protection reviewer, the same guarantees with the mechanism named. Each customer's data is held in a dedicated PostgreSQL schema. Every query runs inside a transaction that issues SET LOCAL search_path for that one schema — never a session-level SET, which would outlive the transaction and follow a pooled connection to the next caller. Schema names come from our internal registry and are never built from anything a request contained. Erasing a workspace is DROP SCHEMA: the tables cease to exist, and it is irreversible. Retention sweeps mark rows rather than deleting them. Audit records are retained through an erasure and de-identified inside the same transaction. Traffic is encrypted with TLS, and the model-provider credentials we hold for you are encrypted with AES-256-GCM before they are written down.

Changes to this policy

When this policy changes, the date at the head of the page changes with it. We keep the earlier versions and will send you one on request.

We do send email about your account — confirming your address, resetting a password, answering something you sent us — but we do not run a mailing list, so we will not promise you a notification by mail when this page changes. A change that genuinely reduces the protection you already had is published here before it takes effect.

Contact

Questions about this policy, or a request about data we hold, go through the contact form.

Contact us