Most vendors in this space offer a retention policy: data is stored by default, and the vendor promises to delete it after thirty days, or on request, or to exclude it from training. A policy is a promise about a system that retains. It depends on configuration staying correct, on every engineer respecting it, on no backup falling through the cracks, and on the promise surviving the next acquisition.
We made the opposite choice. FuturOne has no durable store for customer content. There is nothing to delete, because nothing was kept — nothing to leak from storage, nothing to subpoena from storage, nothing to quietly train on. That is a property of the architecture, not a paragraph in our terms. This post explains how it actually works, why it cut our customers' security reviews from months to about two weeks, and what it honestly costs us.
Content exists only inside the request lifecycle
During a run, customer content — code, documents, financials, whatever the workflow touches — lives in exactly two places: the memory of the worker executing the current step, and the inference requests sent to model providers. Between steps, intermediate artifacts are held in transient buffers: encrypted with AES-256 under per-run keys that exist only in an in-memory keyring, never written to durable storage, and destroyed when the run completes. If a run hangs, the buffers expire at the run's hard timeout regardless. Key destruction is the deletion mechanism — once the per-run key is gone, whatever bytes briefly existed are noise.
What never happens: no content-bearing database rows, no object storage writes, no payloads in logs, no "cache for quality improvement." Deliverables are returned to you over the API or pushed to systems you control (your repo, your webhook endpoint); we do not keep a copy.
Audit events without content
Enterprises rightly refuse to trade auditability for privacy, so the real engineering work was building observability that is useful without payloads. Every run emits an append-only stream of audit events: actor, action, step types, timing, token counts, tool names, outcome codes — and a salted SHA-256 hash of each artifact, so customers can verify that what they received is what the agent produced, without us holding the artifact itself.
{
"event": "run.step.completed",
"run_id": "run_4kq9z31",
"step": "verify_sources",
"duration_ms": 4180,
"tokens": { "in": 9412, "out": 1206 },
"artifact_sha256": "9c1f8e44…",
"content": null // by construction, not by configuration
}Keeping content out of logs is a discipline problem as much as a design problem, so we enforce it structurally: the internal logging API accepts typed event objects, not strings, which makes "just log the payload while debugging" a compile error rather than a code review catch. A CI check greps for payload types crossing the logging boundary, and we periodically audit log sinks for anything that looks like content. Boring, repetitive, load-bearing.
The chain matters too. Inference runs against Anthropic, OpenAI, and Google under zero-retention enterprise terms; transient compute runs on AWS; Cloudflare handles the edge. Your zero retention is only as strong as your weakest subprocessor, which is why the security page names them.
What this does to enterprise security review
The standard security review for a tool that touches source code and financial documents is a 200-question questionnaire, a data-flow workshop, and a months-long negotiation over retention schedules, deletion SLAs, and breach scope. The slow part is rarely encryption ciphers — it is every question downstream of "so where does our data live, and for how long?"
Zero retention collapses those questions instead of answering them. Retention schedule: there is none. Deletion SLA: deletion is the end of every request, automatically. Breach scope for stored content: there is no stored content. Data residency for content at rest: no content is at rest. Entire questionnaire sections become "N/A — see architecture," and the data-flow diagram fits on one page.
Across our enterprise deals, security review now averages about two weeks from first call to signoff — against the three-to-six months that is typical for tools in this category. One customer's counsel put it simply: there was nothing to negotiate on data handling.
We did not build zero retention as a sales tactic, but it has become one of the most measurable things about our pipeline.
What it costs us — the honest part
Anyone who tells you zero retention is free is selling something. It cost us real product surface and a permanent engineering tax, and you should weigh both.
No conversation history features
We cannot offer "pick up that analysis from last month" backed by stored context, because we did not store the context. Every run starts from inputs you provide or systems you control — your repository, your document store, your data feeds. Competitors demo memory features we will not build this way. For recurring workflows we lean on artifact diffing against the previous deliverable you re-supply, which covers most of the real use case — but not all of it, and we will not pretend otherwise.
Debugging without payloads is genuinely harder
When a run misbehaves, our engineers see shape, not substance: step durations, token counts, tool outcomes, error codes. We reproduce issues with synthetic fixtures that match the metadata signature of the failure. When that is not enough, customers can re-run with a debug flag they control, which shares content for the lifetime of that support session only — explicit, scoped, and off by default. Our observability had to get unusually good at inferring failure modes from metadata, and it took quarters to get there.
Support cannot "just look at your run"
There is no replay button on our side. Support works from your description, the audit event stream, and reproduction — slower for everyone on a bad day, and we accept that.
Some features are structurally impossible
Cross-customer caching of content, personalization learned from your documents, fine-tuning on customer data: cannot be built without breaking the property. We consider the last one a feature of the architecture rather than a limitation, but it is fair to call it a constraint.
Why we would choose it again
The asymmetry is what convinced us. The upside of storing customer content is incremental product convenience. The downside is carrying a liability that compounds with every customer and every month of retained data — one breach of stored enterprise content would cost more trust than every history feature ever built. Add the measurable sales velocity, and the decision has aged well: in eighteen months, no customer has asked us to start retaining their data, and several chose us because we cannot.
Zero retention is not a checkbox we toggled. It is load-bearing in how the product is built, reviewed, and sold — which is exactly why a policy promise cannot substitute for it.