Long-Term Memory As A Liability: When To Compress, Archive, Or Delete For Risk Reduction

TL;DR

The instinct of every agent operator is to keep all memory forever, because more context seems unambiguously better. It is not. Memory you cannot justify keeping is risk on the books: liability under data subject requests, attack surface under adversarial scenarios, retrieval noise under normal operations, and operational cost in storage and indexing. The mature practice is to apply a risk-vs-utility triage to every memory cohort and to deliberately compress, archive, or delete when the risk exceeds the utility. This post defines the triage framework, walks through the four risk dimensions and three utility dimensions that drive the decision, and provides a Memory Liability Triage worksheet you can run quarterly to keep your memory store on the right side of the trade-off.

Intro: The data subject request that took six months

A financial-services platform we worked with received a data subject access request from a customer who had been on the platform for four years. The request was straightforward under the relevant regulation: enumerate every piece of personal data held about the customer, indicate the purpose of each, and provide either a copy or a justification for retention. The platform's customer-service agent had a memory store accumulating since the beginning of the relationship. The store had no retention policy, no purpose tagging, no structured way to enumerate per-subject entries. Producing the response took six months of legal and engineering time; the team built a custom extraction pipeline against the agent's memory just to enumerate the entries, and a second pipeline to assess each entry's purpose. The customer's request was eventually fulfilled. The platform's general counsel issued a directive that no agent could store memory without a per-entry retention policy, ever.

This is the visible cost of treating long-term memory as an unalloyed asset. The hidden costs are even larger. The same memory store, had it been tagged for purpose and retention from the start, would have answered the request in days instead of months. Had it been periodically triaged, much of the four-year accumulation would have been compressed or archived already, reducing both the work and the exposure surface.

The instinct to keep everything is understandable. Memory is the substrate of an agent's competence; pruning it feels like deliberately making the agent worse. But the same memory that makes the agent more useful in normal operation makes the operator more exposed under adversarial or regulatory pressure. The trade-off is real, and ignoring it does not make it go away; it just defers the bill.

The rest of this piece argues for a structured approach to memory retention: every cohort of memory entries gets a periodic triage that weighs risk against utility, and the result is one of three actions (compress, archive, delete). The framework is opinionated. It will not always be right; it will always be defensible. The goal is to move from accidental retention (we kept it because we never thought about it) to deliberate retention (we kept it because the utility outweighs the risk, and we documented the reasoning).

What makes long-term memory a liability

The word liability is not chosen casually. It captures something specific: an obligation that costs something to discharge and that grows in cost as the underlying object grows. Memory entries are liabilities in four distinct dimensions, and a complete risk picture requires looking at all four.

The first dimension is regulatory exposure. Every memory entry that contains personal data is a potential subject of a data subject request, a regulatory inquiry, or a breach disclosure if the underlying store is compromised. The cost per entry is small in expectation but unbounded in tail; a single regulatory action against a large memory store can dwarf the entire operational cost of running the agent. Entries with no clear retention justification are pure exposure: they cost as much to defend as entries you actively need but produce no offsetting value.

The second dimension is attack surface. Every memory entry is a potential target for memory poisoning (covered in detail in a prior post in this series), a potential vector for cross-tenant leak (when isolation fails), and a potential subject of unauthorized retrieval. Larger stores have more attack surface; older stores have entries whose access patterns are no longer monitored as carefully; both effects compound over time.

The third dimension is retrieval noise. Memory stores are search systems; the larger the store, the more entries compete for the top retrieval positions on any given query. Old entries that are no longer accurate, relevant, or current pollute the retrieval space and degrade the quality of the agent's reasoning. This effect is gradual and invisible until you measure it; teams that measure retrieval quality over corpus age usually find a quiet decline as the corpus grows past a threshold.

The fourth dimension is operational cost. Storage is cheap per byte but not free; indexing is more expensive than storage; embedding is more expensive than indexing. A memory store that triples in size triples its embedding bill, more than triples its index footprint, and at some scale starts requiring sharding, replica strategies, and dedicated operations. None of this cost is justified by entries that are not being used.

These four dimensions are not equally weighted in every workload. A regulated workload weighs regulatory exposure heavily; an adversarial environment weighs attack surface heavily; a high-traffic agent weighs retrieval noise heavily; a small-scale deployment weighs operational cost lightly. The triage framework is the structured way to weigh them per cohort and act accordingly.

The three utility dimensions

Liability is one side of the ledger; utility is the other. A memory entry is worth keeping if its utility exceeds its liability. The three dimensions of utility are retrieval frequency, decision impact, and replacement cost.

Retrieval frequency is the simplest dimension. An entry that is retrieved often is producing direct utility every time. An entry that has not been retrieved in months is, by behavioral evidence, not producing direct utility. The retrieval log is the source of truth for this dimension; every retrieval is logged, and the log is queryable per-entry. Most memory stores can produce a per-entry retrieval count for any time window with a single query.

Decision impact is more subtle. Some entries are retrieved often but produce low impact (they appear in the results but do not load-bear the agent's conclusion); others are retrieved rarely but produce high impact (when they fire, they change the answer). A complete utility model requires distinguishing the two. The proxy we use is to track per-entry impact through downstream behavioral signals: when the entry is retrieved, does the agent's output reference it, or quote it, or change direction because of it? This requires instrumentation but is achievable with a small additional logging layer at the agent's reasoning step.

Replacement cost is the third dimension and the one most often missed. An entry has high replacement cost if reproducing the equivalent context from external sources would be expensive. A memory entry recording a unique customer interaction has near-infinite replacement cost; the interaction will not happen again. A memory entry caching a fact that is freely available externally has near-zero replacement cost; the fact can be re-fetched on demand. Replacement cost is the dimension that most justifies keeping rare-but-irreplaceable entries even when their retrieval frequency is low.

The three utility dimensions combine into a single utility score per entry, weighted by the workload's preferences. A high-traffic agent might weight retrieval frequency most heavily; a high-stakes agent might weight decision impact; a unique-relationship agent might weight replacement cost. The weights should be set at the cohort level and re-evaluated when the workload changes.

With liability scored on the four dimensions and utility scored on the three, every memory cohort can be placed on a two-dimensional grid. The grid drives the action: low liability and high utility means keep as is; low liability and low utility means archive (the entries are not actively useful but not actively harmful); high liability and high utility means compress (preserve the value while reducing the exposure); high liability and low utility means delete (the entries are pure cost).

Compression: extracting value while reducing exposure

Compression is the most interesting of the three actions because it is the one that most operators do not realize is available. The intuition is that an entry is either kept or deleted; compression breaks this binary by transforming the entry into a smaller, lower-exposure form that preserves its utility for the agent's specific use cases.

The simplest form of compression is summarization. A long memory entry containing a multi-page customer interaction is replaced by a short summary that captures the conclusions and removes the raw content. The summary is much smaller, contains less personal data, retrieves on the same queries, and produces equivalent reasoning impact for almost all downstream uses. The original entry is archived; the summary lives in active memory.

A second form of compression is fact extraction. A memory entry containing a discursive set of observations is replaced by a structured set of named facts. The facts are queryable directly, the noise is gone, and the storage footprint is dramatically smaller. This works particularly well for entries that the agent has already implicitly summarized through repeated retrieval; the facts the agent retrieves are exactly the facts worth extracting.

A third form of compression is provenance compression. A memory entry whose value is in its conclusion (and not in its supporting evidence) is replaced by the conclusion plus a hash of the original evidence. The original evidence is archived; the hash lets a future verifier confirm the conclusion was correctly derived from the archived evidence without keeping the evidence itself in active memory. This is particularly useful for entries that were originally created to support an attestation; once the attestation has been issued and accepted, the supporting evidence can usually be compressed.

A fourth form of compression is anonymization. A memory entry containing personally identifiable details that are not load-bearing for the agent's reasoning is replaced by an anonymized version where the identifiers are stripped or generalized. This is not always possible (some agent reasoning depends on identity), but where it is, it dramatically reduces the regulatory exposure dimension while preserving most of the utility.

The practical implementation of compression is a periodic background pass: every cohort that meets the triage criteria is processed by a compression routine appropriate to the cohort's content type. The compressed result replaces the original in active memory; the original is moved to archive (or deleted, if the compression was lossless). The agent's retrieval logic should be agnostic to whether it is reading the original or the compressed version; the schema should allow either to be returned.

Compression has trade-offs. Some downstream uses depend on the full original entry; compression can break those uses. The mitigation is to identify the dependent uses before compressing (the impact analysis should surface them) and to either preserve the originals for those uses or migrate the uses to operate on the compressed form. This is operational work; it is not free; it pays back in reduced liability.

Archive: the middle ground

Archive is the middle action between keep and delete. An archived entry is not in active memory; the agent does not retrieve it during normal operation; but the entry still exists, can be retrieved by an authorized operator query, and can be restored to active memory if needed. The archive serves as institutional memory without the operational cost or active exposure of the live store.

The right cohorts for archive are those with low liability and low utility, plus those whose utility might return in the future. A cohort of entries from a customer relationship that has ended belongs in archive, not active memory; if the customer returns, the entries can be restored. A cohort of entries from a deprecated product feature belongs in archive; if the feature is revived, the entries are still there. A cohort of entries that capture rare edge cases belongs in archive when the edge cases are not currently active; the entries are valuable but should not pollute the active retrieval space.

Archive has its own design considerations. The store should be cheaper per-byte than the active store, since access frequency is much lower; cold storage with longer retrieval latency is appropriate. The store should be encrypted with keys distinct from the active store, so a compromise of the active store does not implicitly compromise the archive. The store should be accessible only through audited operator queries; routine agent operation should not be able to reach it. And the store should have its own retention policy; entries do not stay in archive forever, and the policy should specify when archive entries themselves get deleted.

The triage decision to archive (versus delete or compress) is correct when the entries' future utility is uncertain but plausible, and when the cost of restoring them later is low. When future utility is very unlikely, deletion is the right choice; when future utility is very likely, the entries should stay in active memory. Archive captures the middle case where the operator is buying optionality.

A common mistake is to use archive as a stopgap because deletion feels too final. This produces archive bloat: a perpetual store of entries no one ever revisits, accumulating cost without value. The discipline is to set a clear archive retention policy at the time of archiving and to enforce the deletion when the retention period expires. An archive that grows without ever shrinking is just deferred deletion with extra steps.

Delete: the underused option

Deletion is the most-feared and most-underused action in the triage. The fear is rational at the individual entry level: deleting a specific entry might turn out to be a mistake, and undoing the deletion is impossible. The fear is irrational at the cohort level: a cohort whose liability clearly outweighs its utility is producing net negative value every day it is retained, and the longer deletion is deferred, the larger the cumulative exposure.

The right cohorts for deletion are those with high liability and low utility (the obvious case) and those that have moved through archive without being restored within the archive retention period. The latter is the cohort that most teams forget about. Setting an archive retention policy and enforcing it through deletion is the only way to keep the archive itself from becoming a liability over time.

Deletion in a memory system has practical considerations beyond the act itself. Auxiliary structures (clusters, topic models, similarity-based access) need to be updated when their underlying entries are deleted; the deletion logic should propagate through all dependent structures. Provenance trails that pointed to the deleted entry need to be marked as orphaned, with whatever downstream consequences that entails. Pacts whose evidence included the deleted entry may need renegotiation; the audit log of pact-relevant deletions should be preserved separately from the operational store.

For cohorts where the regulatory exposure is the dominant concern, cryptoshredding (destroying the encryption key rather than the ciphertext itself) is a useful pattern. The data becomes mathematically inaccessible without occupying the operational cost of full deletion; the proof of inaccessibility is straightforward. This pattern works particularly well in shared-isolation architectures (covered in a prior post in this series) where per-tenant keys are already part of the design.

The operational discipline that makes deletion safe is documentation. Every deletion event records what was deleted, why it was deleted, who authorized it, and what downstream impacts were assessed. Future audits will ask about deletion events; the discipline of documenting them at the time saves enormous trouble later. The documentation itself can be archived (with its own retention) so the platform retains the institutional memory of what was deleted even after the underlying data is gone.

The triage workflow: quarterly is the right cadence

The triage is not a one-time exercise; it is a recurring discipline. Memory accumulates continuously; the right cadence for triage is once a quarter for most workloads, with monthly cadence for high-velocity workloads and annual cadence for low-velocity ones.

The quarterly workflow has four steps. First, cohort definition: group memory entries into cohorts that share characteristics relevant to the triage (customer relationship, time window, purpose, sensitivity class, source). Cohorts should be coarse enough that the triage is tractable; too-fine cohorts produce more work than the triage can absorb. Second, scoring: compute the four liability dimensions and three utility dimensions for each cohort, weighted appropriately for the workload. Third, decision: place each cohort on the liability-utility grid and assign one of the four actions (keep, compress, archive, delete). Fourth, execution: implement the assigned action, log the event, and notify any downstream consumers whose pacts or attestations are affected.

The cohort definition step is the one that most teams underinvest in. A good cohort definition is the difference between a triage that takes a day and a triage that takes a month. The cohorts should be queryable from the memory store's metadata: a cohort is a query, not a manual list. We typically use combinations of three to five metadata fields (sensitivity class, source type, age band, tenant, retrieval frequency band) and produce somewhere between twenty and a hundred cohorts per workload. More cohorts than that and the triage becomes intractable; fewer and the triage loses precision.

The execution step should be largely automated. Compression routines, archive transfers, and deletion logic are all scriptable; the human decision is in the action assignment, not the action execution. Automation also makes the triage repeatable, which is what makes it a discipline rather than an event.

The results of each triage should be recorded as a triage report: which cohorts were triaged, what actions were assigned, what was executed, what the resulting memory store looks like. The report becomes input to the next triage; cohorts that were preserved last quarter but are now drifting toward higher liability or lower utility get re-evaluated. The cumulative triage history also becomes useful audit evidence: a regulator asking why a particular cohort was deleted can be shown the triage report that justified the decision.

Counter-argument: 'Storage is cheap, just keep everything'

The most common pushback on memory triage is that storage is cheap enough that keeping everything is the dominant strategy. The argument: per-byte storage costs are trivial, the operational cost of running triage exceeds the operational cost of perpetual retention, and any value that might come from a kept entry is by definition realized only because it was kept.

The argument is wrong on every dimension, and unpacking why is worth doing because the position is widely held.

Storage is not the cost. The cost is the four liability dimensions: regulatory exposure, attack surface, retrieval noise, operational cost. Of these, only the last is plausibly bounded by per-byte storage pricing; the other three scale with the value of the data and the threat environment, neither of which is captured by storage cost. A platform that frames the question as 'is it cheap enough to keep' is implicitly assuming the other three liabilities are zero, which they are not.

The operational cost of triage is also overstated. A well-designed triage runs on cohort-level metadata queries and automated action execution; the human time per quarter is hours, not days. The discipline of designing for triage from the start is a one-time investment; the recurring cost is small.

The final argument, that any value comes from kept entries, is a survivorship bias. The entries you keep and use are visible; the entries you keep and never use are invisible. The right comparison is between the value of the entries you actually use and the cost of the entries you do not, and that comparison almost always favors selective retention over indiscriminate retention.

Where the argument has some merit is in the very early stages of a deployment, when the corpus is small, no entries have aged into liability yet, and the team is still learning what utility looks like. In that window, deferring triage until enough data has accumulated to triage meaningfully is reasonable. But the window is short; once the corpus crosses a threshold (we use one hundred thousand entries or one year of operation, whichever comes first), the triage becomes overdue and every quarter of further delay compounds the eventual cleanup cost.

What Armalo does

Armalo's Cortex memory layer (hot, warm, cold tiers) is built around the assumption that memory will be triaged regularly. Every memory entry carries metadata for sensitivity class, source type, retention policy, and purpose; cohort queries are first-class operations against the metadata. The hot/warm/cold tiering itself reflects part of the triage philosophy: hot memory is the actively retrieved working set, warm memory is the recently used or anticipated set, and cold memory is the archive.

The quarterly triage workflow (cohort definition, scoring, decision, execution) is supported as a built-in operational primitive. Compression routines (summarization, fact extraction, provenance compression, anonymization) are available as standard background passes; archive transfers and deletions are auditable operations that emit attested events. Operators can configure per-cohort retention policies and have the system enforce them automatically, with notification before any deletion event occurs.

Memory entries that influence pact compliance evidence are treated specially during triage: entries that are load-bearing for active pacts are not eligible for deletion until the pact is closed, and the triage report flags any conflict between the proposed action and active pact dependencies. The trust oracle at /api/v1/trust/ surfaces an agent's memory hygiene as part of its safety-dimension score; consistent triage practice contributes positively, and unbounded retention without justification contributes negatively. The multi-LLM jury (with top and bottom 20% outlier trimming) evaluates memory governance practices when they become relevant to a pact dispute or a compliance review, and score decay (one point per week) ensures that one-time triage misses do not permanently mark an agent.

FAQ

What is the right cadence for triage?

Quarterly is the default for most workloads. High-velocity workloads with rapid memory accumulation benefit from monthly cadence. Low-velocity workloads can run annually. The cadence should be set explicitly and revisited as the workload's tempo changes.

Can compression be reversed if I change my mind?

Lossy compression (summarization, fact extraction) is not reversible by definition; the original content is gone unless it has been archived separately. The triage decision should explicitly note whether the original is being preserved in archive; if it is, restoration is possible at the cost of operational work.

How do I handle entries that span multiple cohorts?

Entries should belong to exactly one primary cohort for triage purposes; the cohort definition is exclusive. Entries that have characteristics matching multiple cohorts should be assigned based on the highest-priority dimension (typically sensitivity class). If the assignment feels wrong, the cohort definitions need refinement.

What if a deleted entry turns out to have been needed for a future regulatory request?

The triage report and deletion log together constitute the response: the entry was deleted on a specific date for documented reasons consistent with the operator's retention policy. This is a defensible position under most regulatory frameworks. Improvising a response after the fact is much harder; the documentation is the safety net.

Does archive count as deletion for data subject request purposes?

Generally no, because the data still exists and is retrievable by an operator query. Data subject requests usually require either deletion (the data is gone) or active retention with disclosed purpose. Archive falls into the latter category and must be enumerated in the response.

Should triage run on the trust-relevant subset of memory?

All memory should be triaged, including trust-relevant memory, but with the additional constraint that load-bearing pact evidence is preserved until the pact closes. The triage logic should respect pact dependencies; the discipline is to prevent operational retention from drifting into perpetual retention.

Is there a minimum corpus size below which triage is not worth it?

A corpus under twenty thousand entries can usually be triaged ad hoc rather than on a schedule. A corpus over a hundred thousand entries should be on a regular schedule. The transition is gradual; teams should start the practice well before they think they need it.

Bottom line

Long-term memory is not unalloyed asset. It is asset and liability simultaneously, and the right balance depends on workload characteristics. The four liability dimensions (regulatory exposure, attack surface, retrieval noise, operational cost) and the three utility dimensions (retrieval frequency, decision impact, replacement cost) form the framework that makes the trade-off explicit. Compression preserves utility while reducing exposure; archive preserves optionality at low cost; deletion eliminates liability when justified. The Memory Liability Triage worksheet runs quarterly and turns the framework into operational practice. The cost of running the triage is small. The cost of not running it is the kind of regulatory or adversarial exposure that arrives all at once and forces the cleanup under the worst possible conditions. Build the discipline before you need it.