The Forgetting Right: When Agent Memory Must Expire By Pact Or By Law

TL;DR

Agents that cannot forget cannot operate in regulated domains. The right to be forgotten under GDPR, customer-pact TTLs, and industry-specific retention limits all converge on the same engineering requirement: memory expiration must be verifiable, not merely promised. The wrong implementation deletes the row and hopes nobody asks. The right implementation produces a tombstone (a signed record that proves the forgetting happened, when, and at whose request) and runs propagation through embeddings, summaries, and any downstream artifacts that may have absorbed the forgotten content. The forgetting compliance matrix specifies, per regulation, what must expire, when, with what evidence. Forgetting is not the absence of remembering. It is an engineered operation. Build it that way.

Why Forgetting Is Harder Than Remembering

Remembering is straightforward: write to a store. Forgetting is genuinely hard, because data spreads. The original fact lives in the source entry. The fact also lives in the embedding generated from the source. The fact lives in the warm-tier summary that compressed the source. The fact lives in any cold-tier archive of the original. The fact may live in another agent's memory if that agent ever retrieved the source and absorbed it into its own context. The fact may live in a model fine-tune if the source was used as training data. The fact may live in a transcript a third party logged from an agent interaction that referenced the source.

Deleting the source row deletes one copy. Forgetting the fact requires identifying and erasing every derivative. This is the technical challenge that makes forgetting in agent memory architecturally distinct from forgetting in a relational database. A user deletion in a CRM means dropping a row, maybe cascading some foreign keys. A user deletion in an agent memory store means tracing the user's information through every embedding, every summary, every fleet member that ever read the original, and ensuring nothing is left behind that could surface the user's information in a future retrieval.

This is also where most implementations quietly fail. The deletion deletes the source. The deletion does not regenerate the embedding (the embedding still encodes the deleted content and can still be matched by similarity). The deletion does not invalidate the warm summary (the summary still contains the user's name and their financial details). The deletion does not propagate to other agents in the fleet that may have read and cached the source. The user has been told they were forgotten. The user has not been forgotten in any meaningful sense. Six months later, an agent retrieves a similarity-matched fragment that surfaces the user's data, and the company is in violation of the regulation it claimed to comply with.

The engineering answer is that forgetting must be a structured operation with explicit propagation, and the operation must produce a verifiable record of what was forgotten and when. The record (the tombstone) is what lets you prove compliance to a regulator, to the user, and to your own future self when you need to know whether something is supposed to be in the store or not.

The Tombstone: What Forgetting Leaves Behind

The tombstone is the artifact of the forgetting operation. It is a signed record that says: at time T, in response to request R, the following entries were deleted, with the following content hashes, under the following authority. The tombstone contains the hashes of the deleted content (so future verification can confirm what was deleted matches what was supposed to be deleted) but not the content itself (because the content was the thing being forgotten). The tombstone is permanent. The original content is gone. The proof of the deletion is durable.

The tombstone has five required fields. The deletion request reference: who asked, on what authority (a user invoking GDPR Article 17, a pact TTL clause, a regulatory inquiry resolution, an internal retention sweep). The scope: which entries were targeted (by ID, by tag, by query). The execution record: which entries were actually deleted, with their content hashes, their tier at the time of deletion, and the tools used to delete them. The propagation record: what derivatives were also handled (embeddings regenerated or removed, summaries deleted, downstream caches invalidated, fleet members notified). The signature: the tombstone signed by the operator's deletion authority key, with timestamp from a trusted source.

The tombstone serves three audiences. The user (or regulator) who requested the deletion can verify that the deletion happened by inspecting the tombstone. They cannot reconstruct the deleted content (the hashes are one-way) but they can confirm that something with that hash existed and was deleted. The operator can use tombstones to audit their own retention policy compliance: a sweep of tombstones over a period shows what was forgotten, when, and why. The next agent in the fleet that tries to retrieve the deleted content gets back the tombstone (if it queries by hash) or simply gets no result (if it queries by similarity, because the embedding has been removed); either way, the agent does not surface the forgotten content.

Tombstones also make audit-grade absence provable. The hardest question to answer in any data-rights inquiry is "do you no longer have this data?" Without tombstones, the answer is "we don't see it." With tombstones, the answer is "here is the signed record of when we deleted it." The first is unverifiable; the second is evidence. Regulators care about the difference. So do customers, when they get to the part of the conversation where they ask for proof.

What Counts As Expiration: Pact-Driven, Law-Driven, Operationally-Driven

Forgetting fires under several distinct triggers, and the architecture has to handle all of them with the same primitive. The first is law-driven: a user invokes a right under GDPR, CCPA, or any of the proliferating data-rights regimes, and the operator is legally required to delete the user's data within a specified window. The trigger is the user request; the deadline is regulatory; the scope is the user's data across the entire substrate.

The second is pact-driven: an agent's pact specifies a TTL for certain content classes. "Customer transcripts retained for 90 days, then forgotten." "Internal deliberation logs retained for 30 days, then forgotten." The trigger is the calendar; the deadline is contractual; the scope is the content matching the pact's classification rules. Pact-driven forgetting is the most operationally significant because it runs continuously and at volume; the substrate processes pact TTL forgettings constantly as a background sweep.

The third is operationally-driven: internal retention policies or specific events trigger forgetting. A customer churn event triggers forgetting of the customer's interaction history. A merger or acquisition triggers forgetting of obsolete acquired-company memory. An incident response involves forgetting compromised memory that may have been poisoned. The trigger is internal; the deadline is operational; the scope is whatever the operational policy specifies.

The fourth is regulatory retention: certain industries require that data NOT be deleted for a specified period (financial transaction records for seven years, healthcare records for the patient's lifetime plus a window, securities communications for a regulator-defined period). Regulatory retention is the inverse of forgetting: it is the requirement to preserve. The forgetting system has to know about retention requirements so it does not delete content that legally must be preserved. A pact TTL of 90 days does not override a regulatory retention requirement of 7 years. The substrate has to enforce the maximum of (operational retention, pact retention, regulatory retention) and only forget when all three permit.

The practical implementation is a per-content-class retention table that the substrate consults at every forgetting decision. The table has columns for pact TTL, regulatory retention, operational policy, and the resulting effective retention is the maximum of all three. A forgetting request that would violate regulatory retention is rejected by the substrate with an explanation of which regulation is the blocker. A user requesting deletion under GDPR for a content class with a regulatory preservation requirement gets a response that explains the conflict; in most regimes, regulatory retention overrides individual deletion requests for the relevant content, and the user has the right to know that.

Reader Artifact: The Forgetting Compliance Matrix

The matrix specifies, per regulation or pact obligation, what content classes are affected, what the retention or expiration rules are, and what evidence the operator must produce. Each row is a row the substrate must enforce.

The matrix is not exhaustive but it is the working core. Operators building in regulated domains add rows for their specific obligations. The substrate enforces the matrix at every forgetting decision; the matrix is itself a versioned, signed artifact, just like the mesh charter, so changes are auditable.

Embeddings Are The Sneaky Part

The least-handled aspect of forgetting in production agent systems is the embedding. The source entry is in the database; you delete it. The summary is in the warm tier; you delete it. The cold archive holds the raw bytes; you delete it. You think you are done. You are not done. The embedding generated from the source is still in the vector index, and it still encodes the content of the deleted source. A similarity query for content semantically close to the deleted material will still match the embedding and return... well, what does it return? The metadata pointer that said the source was at row X. Now the source is gone, so the retrieval system handles the dangling pointer somehow: maybe it returns null, maybe it returns the tombstone, maybe (worst case) it returns a stale cache of what was there.

The correct implementation deletes the embedding too. This is non-trivial because vector indexes are typically optimized for write and query, not for deletion. Some vector stores support hard deletion; others mark entries as deleted but keep them in the index for query performance reasons (which is exactly the wrong behavior for forgetting). Some embedding architectures index in segments that get rewritten lazily, so a deletion is not effective until the next segment rewrite, which may be hours or days later.

The substrate has to handle this with an explicit embedding-purge step in the forgetting operation. The step verifies that the deleted source's embedding is actually gone from the index, not just marked. If the underlying vector store does not support synchronous hard deletion, the substrate either forces an index rebuild (operationally expensive but correct) or it queues the deletion for the next rebuild and reports the deferred deletion in the tombstone (operationally cheaper but requires the deferral to be explicit and time-bounded).

The second-order issue is that embeddings can be inverted. Modern embedding models, especially the larger ones, leak meaningful content reconstruction with sufficient effort. An embedding of a customer's address is, in a literal information-theoretic sense, a compressed representation of the address. Treating embeddings as non-personal-data because they are vectors rather than text is wrong; the GDPR and similar regimes treat any data that can be linked back to a person as personal data, regardless of representation. Embeddings of personal data are personal data. They have to be deleted on forgetting. There is no out.

Counter-Argument: Just Hold Less

The counter-argument is that forgetting is hard precisely because we hold too much, and the right response is to hold less in the first place. Aggressive minimization at write time means little to forget at expiration time. This has the appeal of simplicity and is genuinely good practice up to a point.

The point at which it stops being sufficient is the point where any agent does anything useful for a customer. Useful work generates context. Context contains personal data if the customer is a person and operational data if the customer is a business. The minimum viable memory state for an agent that handles customer interactions is non-trivially populated, and the populating happens whether you wanted it to or not.

Minimization helps. It does not eliminate the forgetting problem. The architectural reality is that you will have personal and sensitive data in your agent memory because that is what makes the agent capable of doing real work, and you will need to forget some of it under regulatory or contractual obligations because that is what makes the agent operable in regulated domains. Minimization is hygiene; engineered forgetting is infrastructure. You need both.

What Armalo Does

The Cortex memory subsystem implements forgetting as a first-class operation with tombstone generation, propagation through embeddings and summaries, and per-regulation enforcement of expiration windows. Pact-driven TTLs are enforced as a continuous background sweep; user-initiated deletions under GDPR or similar regimes run on-demand against the deletion window. The substrate maintains the forgetting compliance matrix as a signed, versioned artifact; pact compliance scoring includes whether the agent's substrate is operating in conformance with the matrix. Embedding deletion is part of every forgetting operation, with explicit verification that the embedding has been hard-deleted rather than soft-marked. Tombstones are queryable by the operator, the user (for their own deletion requests), and regulators (under appropriate access authority); each tombstone is signed by the deletion authority and timestamped against a trusted clock source. Regulatory retention requirements are enforced as deletion blockers: a forgetting request that would violate retention is rejected with an explanatory response, and the conflict is logged for compliance audit purposes.

FAQ

Q: How do you handle a user request when the user's data has been used in fine-tuning? A: Fine-tuning leakage is the hardest forgetting problem and there is no perfect solution today. The best current approaches are (1) avoid fine-tuning on personal data at all, (2) maintain influence-tracking so you can identify which fine-tunes a deleted record contributed to, and (3) when a deletion request hits fine-tuned content, schedule retraining without the deleted records. None of these are cheap. The right architectural response is to make fine-tuning on personal data a deliberate, opt-in decision with the deletion-cost factored in.

Q: What if a counterparty's pact requires us to retain something a user wants deleted? A: This is a real conflict and the substrate cannot resolve it unilaterally. The conflict gets surfaced to the operator as an exception requiring resolution. The general legal precedent is that statutory rights (GDPR Article 17) typically supersede contractual retention obligations, but this varies by jurisdiction and content class.

Q: How is a tombstone different from a soft delete? A: A soft delete keeps the data and marks it inaccessible. A tombstone deletes the data and keeps a record that the deletion happened. Soft deletes are not forgetting; tombstones are. Regulators distinguish between the two and treat soft deletes as continued processing.

Q: Does the tombstone reveal what was deleted? A: It contains a hash of the deleted content, not the content itself. Hashes are one-way; you cannot reconstruct the content from the hash. You can verify that specific content matches a tombstone by hashing the content and comparing.

Q: What about backups? A: Backups are a known forgetting headache. The standard practice is to either (a) propagate deletions to backups synchronously, (b) document a backup retention window after which all backups predating the deletion are themselves deleted, or (c) maintain a deletion-log that gets applied at restore time. Each has trade-offs; the regulator-facing answer is that the backup must not allow the deleted data to re-enter active processing.

Q: Can a user verify their deletion happened? A: Yes. The user receives the tombstone reference as part of the deletion confirmation. They can verify the tombstone's signature against the operator's published deletion authority key. They cannot recover the deleted content from the tombstone, which is the point.

Q: What if a fleet member already absorbed the data before deletion? A: The forgetting operation propagates to fleet members that read the source. Each fleet member's substrate runs its own forgetting operation against the absorbed copy, generating its own tombstone. The propagation is logged in the original deletion's record so you can verify all paths were handled.

Q: Does forgetting affect attestation? A: A prior attestation that committed against the now-deleted content remains valid as a record that the content existed at attestation time. The content itself is gone. This is the appropriate behavior: attestations record history, deletions affect future. The two are not in conflict.

Bottom Line

Forgetting is engineering, not absence. An agent operating in any regulated domain needs to be able to forget on request, on schedule, and on policy, with verifiable evidence that the forgetting happened. The tombstone is the evidence. The propagation through embeddings, summaries, and fleet members is the discipline that makes the forgetting actually effective rather than nominal. The compliance matrix is the table that tells the substrate what to enforce. Skip any of these and you have a memory architecture that promises compliance and does not deliver it. Build all of them and you have an architecture that can stand up to a GDPR inquiry, a pact audit, or a regulator's question about whether the data really is gone. In a world where the answer to that question increasingly determines whether your agent can operate at all, the forgetting infrastructure is no longer optional. It is the cost of being in the regulated agent economy.