How To Limit Memory: General Data Protection Law Article 5 Delete or Cut 80% Token Costs

This guide enforces GDPR Article 5(1)(c) data minimisation for multi-agent AI systems.

It mandates a per-field necessity test before summarization, with deletion of unnecessary fields as the primary path to compliance.

How Article 5 memory deletion actually works

The winner is delete-before-summarize for any field that fails the active-task necessity check. For fields that pass the check, summarization or de-identification is acceptable, but only after the field has been justified. Summarization-only loses because a surviving quasi-identifier remains personal data under the RUG combination test, meaning the token reduction is not minimization but merely compression. The Groningen guidance is explicit: indirect identifiers, such as location combined with vehicle type, can single out an individual when collected together, so retaining even a summarized version of such a field without de-identification fails the Article 5 standard.

Delete-before-summarize is the winning strategy over summarization-only and retention-for-reuse. The three field labels—direct identifier, quasi-identifier, and non-personal operational state—are defined above, and the delete gate is placed at write time. The 80% token-cut target is a goal, not evidence; the legally meaningful standard is GDPR’s three core minimization elements—necessary, adequate, and relevant—which the 80% figure does not itself satisfy.

Costs and numbers that matter

Every retained memory field carries a compound cost that must be accounted for before any summarization occurs. The total expense comprises three distinct layers: the storage tokens multiplied by the retrieval frequency, the per-token price of the underlying model, and the labor cost of weekly review and deletion. Reporting a single blended prompt cost obscures this breakdown and prevents meaningful optimization; each field must be evaluated individually to determine whether the data it carries is justified by an active processing purpose.

The 80% token-reduction figure cited in the headline functions as a target ceiling, not a measured outcome. To assess actual progress, compute the reduction for each field using the formula (baseline field tokens minus post-cut field tokens) divided by baseline field tokens. This calculation yields a numerator and denominator that reveal whether the cut is substantive or merely cosmetic. If a field’s tokens drop from 5,000 to 1,000, the reduction is 80%, but if the baseline was 100 tokens and the post-cut is 20, the reduction is only 80% of a trivial baseline—numbers that must be reported separately to avoid misleading aggregates.

Weekly checkpoints are essential for maintaining a defensible data-minimization posture. At each cycle, count the fields that were deleted at write time, the fields that required de-identification or generalization because they contained a quasi-identifier, and the fields that were retained for a named purpose. Additionally, track retrieval hits per field; a field accessed rarely may justify its cost, while one accessed frequently with redundant data demands immediate scrutiny. If a field has zero retrieval hits for two consecutive weeks, the default action is deletion before the next summarization pass.

Delete-before-summarize is the only strategy that satisfies both GDPR minimization and token-efficiency goals. Summarization alone cannot prove minimization, as it compresses existing data without removing the underlying fields that may violate Article 5(1)(c). Retention-for-reuse defers the compliance burden and risks accumulating unnecessary data. Only by deleting unnecessary fields at write time, and de-identifying those that are necessary but contain identifiers, can the system achieve the 80% target with legal certainty.

What Article 5 does not establish

The GDPR’s Article 5(1)(c) mandates data minimization, yet it does not prescribe a single technical method for achieving it. Article 5(1) itself requires that personal data be “adequate, relevant and limited to what is necessary” for the purposes for which they are processed, but the regulation leaves the implementation details to the controller.

This means that a summarization pipeline cannot, by itself, satisfy the law; the legal obligation to minimize precedes any token-reduction tactic. Without an explicit purpose attached to each field, the default legal position is deletion, not aggregation.

Researchers often assume that a research exemption permits the retention of raw agent transcripts indefinitely. To check this against the RUG Digital Competence Centre guidance, look for the conditions it places on storing personal data for research purposes: retention must be tied to a documented research necessity, case by case, not treated as a blanket permission.

If a field lacks a documented, active processing purpose, the exemption collapses and the data must be deleted. This distinction is critical: a research aim does not automatically legitimize the storage of every intermediate variable produced by a multi-agent system.

HHS de-identification guidance further undermines the notion that summarization alone can render data anonymous. The HHS framework distinguishes between safe harbor methods and expert determination, but neither certifies a summary as anonymous if quasi-identifiers persist. If a summary retains a residual quasi-identifier—such as a generalized ZIP code or birth date—re-identification risk remains, and the data cannot be treated as de-identified. Controllers relying on expert determination must document the methodology and the specific risk assessment that justified the outcome, as the guidance provides no certifying seal for automated summaries.

The practical path to compliance therefore runs through deletion before summarization. A per-field Article 5(1)(c) necessity test must run before any token-cutting step; fields that fail the test are deleted, and those that pass must be de-identified or generalized if they contain identifiers or quasi-identifiers. Only by pruning unnecessary fields first can a system reliably achieve the 80% token-cut target while preserving legal defensibility. Summarization alone, without this prior minimization, risks producing a headline that is technically shorter but legally unprotected.

One agent memory field

The illustrative arithmetic demonstrates how necessity-driven deletion directly serves the 80% token-cut headline target. The raw inputs are: a 240-token raw transcript, a 15-token name field, a 9-token city-plus-vehicle quasi-identifier cluster, a 12-token task-state field, and a 24-token summary. These sum to 300 tokens per retrieval. At 10,000 retrievals, the system processes 3,000,000 tokens. Checkpoint 1 applies the necessity test: the raw transcript, name, and city-plus-vehicle fields are deleted because they are not necessary for the active task. The task state and summary are kept. This reduces the per-retrieval footprint from 300 tokens to 36 tokens—a reduction of 264 tokens, or 88%.

The 36-token result (12 tokens task state + 24 tokens summary) proves that summarization alone cannot achieve the headline 80% cut. A pure summarization approach would retain the identifying and quasi-identifying fields, preserving the 254 tokens of non-essential data (name, transcript, city, vehicle) while only condensing the summary. In contrast, the worksheet-mandated deletion removes those fields before summarization ever runs. The arithmetic is explicit: 36 tokens divided by 300 tokens equals 12%, meaning the combined effect of deletion and summarization achieves an 88% token reduction, comfortably surpassing the 80% threshold.

Fields that pass the necessity test but carry identifiers or quasi-identifiers must still be de-identified. If the task state or summary contains a direct identifier—such as a name—or a quasi-identifier—such as a specific city paired with a vehicle type—those fields must be generalized or stripped prior to any token reduction step. This two-gate approach—necessity first, then de-identification—ensures that the system does not merely compress personal data but actively minimizes it, making the per-field necessity check the mechanism by which token efficiency and GDPR compliance converge.

Decision rules for Article 5 memory limits

When a field carries a quasi-identifier—data that does not directly name a subject but could combine with other fields to re-identify them—the rules tighten. If the active task functionally requires that field, the system must generalize or de-identify it before any cross-agent handoff. Critically, this de-identification step must be followed by a combination risk test: the remaining fields, generalized values, and the quasi-identifier together must be assessed to confirm they do not create a new identification pathway. Only if the risk remains acceptable does the field proceed; otherwise, deletion is the only compliant path.

Summarization does not absolve the system of its minimization obligations. If a generated summary contains a direct identifier or quasi-identifier, the same per-field necessity test applies.

If no documented active purpose exists for that identifier within the summary, it must be deleted even if the token counter celebrates the reduction. A headline hitting 80% token cut is meaningless if the retained text still carries personal data without a legal basis; the necessity test must run before summarization on retained fields, and again on the summary outputs themselves.

These four if/then rules transform the canonical data minimization principle into actionable agent-handoff checks. First, delete direct identifiers at write time if no active task needs them. Second, generalize quasi-identifiers and test combination risk before any hand-off. Third, run the necessity test on summary outputs, deleting identifiers without a purpose. Fourth, treat the deletion gate as a write-time guard, not a post-hoc cleanup, to prevent unnecessary fields from ever entering the vectorized memory in the first place.

What to do next

Quick answers

Also worth reading: Multi-Agent Orchestration: Real Deployments and Data Caveats: Multi-Agent Orchestration: Real Deployments and · How to Audit AI Agent Coordination: Ratios and Hidden Leaks: How to Audit AI Agent