Data Retention

By default m8tes stores your runs' conversation content so you can review history, replay runs, and read generated reports. If your product handles sensitive end-user data, you can switch the account to zero data retention instead.

Two modes

The mode is resolved onto each run when it starts, so it applies to every run created after you set it.

What metadata_only does and doesn't keep

Not stored: the conversation content m8tes would otherwise persist.

• Assistant replies and the conversation transcript
• Tool inputs and outputs (including a paused tool call's arguments, cleared once the run ends)
• Model reasoning (thinking / plan)
• Run output
• Generated reports and documents, both the body and the model-written one-line summary
• Anything the agent tries to remember for later: saved memories, task lessons, and company "learned context" are all refused on a metadata_only run, so no conversation-derived fact is carried into future runs

Kept: what billing and basic observability need, so the agent can still run.

• Roles and message ordering
• Token counts and cost metrics
• Tool names (which tools ran, never their inputs/outputs)
• Run status, timing, and audit events
• Configuration, not conversation: the instruction you submit to start the run, and the task/agent definitions and schedules the agent sets up. A saved document's name label survives too (so the record is still manageable); its summary and body do not.

The agent's work product (replies, tool I/O, reasoning, reports, and any memory or note it would normally save for next time) is never written to our database. What is kept is configuration: the run's starting instruction and the task/agent setup the agent needs to operate. If a configuration field itself would carry sensitive content (for example an agent rewriting an agent's instructions with a fact it learned mid-run, or an inbound email body used as the prompt), contact us; tightening those paths and fully ephemeral input are on the roadmap.

What stops working under metadata_only

Because the content was never stored, anything that reads it back is unavailable for metadata_only runs. This is the whole point of the mode, but plan for it:

• Reviewing a past run's transcript. The run still appears in history with its status, timing, cost, and which tools ran, but the messages have no content to show.
• Searching or reading saved documents / reports. A metadata_only run can still record that a document exists (its name), but there's no stored summary or body to search or open.
• Cross-run memory and history. The agent cannot save a new memory, lesson, or company note during a metadata_only run (those writes are refused), and a later run can't recall an earlier metadata_only run's content (history=true and the task-history tool return metadata only).
• Run summaries and replay. Generated from content, so they're empty.

Still works: listing runs and their metadata, live execution (the agent has full context while a run is in progress), billing and usage, and the audit trail.

A single run completes normally; only the persisted record is content-free. If you need to keep history for some agents and not others, keep those on standard; retention is account-wide today (per-agent overrides are on the roadmap).

About upstream model providers

retention_mode governs what m8tes stores. Separately, and on by default, m8tes routes model requests through its own gateway to providers operating under Zero-Data-Retention terms, so the underlying model provider does not retain your prompts or responses. Combined with metadata_only, that gives end-to-end zero retention on a ZDR-routed path: neither m8tes nor the model provider keeps your content. It is conditional on that path, not automatic — the two exceptions below leave gateway routing, and on those your content reaches a provider whose own terms govern retention even though metadata_only still stops m8tes storing it.

Two cases fall outside that gateway routing, so check them if end-to-end ZDR is a requirement:

• Models with no ZDR host. A few selectable models have no zero-data-retention provider and may retain. Check zdr_supported on GET /api/v2/models before sending customer data — it is the definitive per-model answer. The Platform model picker marks models confirmed to run on zero-data-retention providers; an unmarked model is simply not confirmed, so check the API.
• Runs on your own Claude subscription. If an account authenticates with its own Claude OAuth subscription (including the Platform's free plan), requests go direct to Anthropic rather than through the gateway, and Anthropic's terms for that subscription apply.

On every path, your data is never used to train models, by us or our providers.

Choosing a mode

Use metadata_only when your end-users' data must not be retained by a third party and you don't need transcript history or replay. Use standard when reviewing past work, reading reports, and cross-run memory matter more than minimizing what's stored.

Export everything the account holds

client.account.export() returns the account's stored data as one JSON document. Use it to answer a right-of-access request, or to snapshot state before deleting.

Two things are deliberately left out. Secrets are never exported: password and API-key hashes, encrypted integration tokens and the API keys inside integration metadata, and MFA secrets. Run transcripts are not exported either, because a message can contain a credential the agent read at runtime. The runs section carries status, trigger source, channel, and timing only.

Fields in each section

Section	Fields
account	id, email, first_name, last_name, phone, company, job_title, country, plan, created_at
teammates	id, name, role, instructions, goals, status, created_at
tasks	id, agent_instance_id, name, instructions, status, created_at
runs	id, status, trigger_source, channel, created_at
documents	id, name, summary, content, scope, created_at
memories	id, content, created_at
integrations	id, provider, kind, status, account_id, created_at

The export is account-wide. It is not scoped by user_id, so it includes every end-user's records.

Delete the account

client.account.delete() requests erasure. It returns 202 and the grace window:

Immediately, in one transaction: every session is invalidated, the default key and every named key are revoked, and login is refused. Then, best effort: the Stripe subscription is cancelled, every schedule is disabled and unregistered from the scheduler, and in-flight runs are cancelled. Export first if you want a copy, because the same call that starts deletion also ends your ability to authenticate.

After 30 days, a daily job erases the data. This is not self-service reversible: no endpoint restores a deletion request, so contact support inside the grace window if you need it undone.

Exactly what is erased and what is retained

Erased at the end of the grace window: agents, tasks, schedules, runs and their conversation messages, documents, memories, integrations and their OAuth tokens, webhook endpoints, custom MCP servers, Slack installs, Apple Messages bridges, inbound event receipts, end-user records, tool permission policies, MFA secrets and recovery codes, and refresh tokens. An organization where you were the only member is deleted with it; one with other members survives, with its name replaced by "Workspace".

Retained, anonymized: the account row is scrubbed in place rather than deleted, because retained financial and audit records point at it. email becomes deleted+<id>@deleted.invalid, and name, phone, company, job title, country, and password are cleared. Audit logs keep the aggregate access trail with the identifiers nulled (IP address, API-key prefix, request id, end_user_id, and resource_id). Stripe customer and subscription ids are kept so retained invoices can be reconciled; Stripe holds its own copy of the billing record.

Next: Going Live · Users · Limits