How Do You Delete a Customer from AI Memory

Why Customer Deletion Is Complex

In a traditional CRM, deleting a customer means removing their record from the customer table and associated records from related tables. The data model is explicit and the deletion path is clear. In an AI memory system, a customer's data exists in forms that are harder to identify and remove.

A support agent stores a memory: "Acme Corp's DevOps team reported that their webhook integration drops events when the payload exceeds 256KB. We suggested they switch to streaming mode. Their contact is Maria Santos, engineering lead." This single memory creates data in five places: the memory content record, a vector embedding encoding the semantic meaning, a knowledge graph node for Acme Corp, a node for Maria Santos, relationship edges connecting Acme Corp to webhook integration issues and to Maria Santos, and potentially cached query results from previous retrievals that included this memory.

Deleting "Acme Corp" from memory means finding and removing all of these artifacts. Missing any one of them means the customer's data persists in the system. Leaving the embedding means the deleted customer's context can still influence future retrieval results through semantic similarity. Leaving the graph node means the customer remains discoverable through graph traversal even though the original memory is gone.

The Deletion Process

Step one is identifying all data. Search the memory content store for all memories that mention the customer, using the customer's name, identifier, and any known aliases or contacts. Search the knowledge graph for entity nodes that represent the customer or their employees. Check the data subject index (if memories were tagged with customer identifiers at ingestion). Create a complete manifest of everything that references the customer before starting deletion.

Step two is classifying each item. Some memories are solely about the customer and should be deleted entirely. Other memories mention the customer alongside other customers or general knowledge. "Acme Corp and Beta Inc both use our enterprise plan and both requested webhook improvements" mentions two customers. Deleting Acme Corp requires either deleting the entire memory (which loses information about Beta Inc) or redacting Acme Corp's mention while preserving the rest.

Step three is executing deletion in the correct order: cached results first, then graph edges, then graph nodes, then embeddings, then memory content. This order prevents downstream components from referencing data that has already been deleted in upstream components.

Step four is verification. After deletion, re-run the identification searches to confirm that no references to the customer remain in any storage layer. Any remaining references indicate that the initial identification was incomplete, and those references must be deleted in a follow-up pass.

Step five is logging the deletion in the audit trail, recording which customer was deleted, how many records were affected, when the deletion was completed, and who requested it. The audit record must not contain the deleted customer's data.

Handling Mixed Memories

Mixed memories, those that mention the customer alongside other information, are the hardest part of customer deletion. Three approaches handle them. Full deletion removes the entire memory, which is thorough but loses non-customer information. Redaction removes the customer's mentions while preserving the rest, which requires re-generating the embedding from the redacted text and updating the knowledge graph to remove only the customer-related edges. Anonymization replaces the customer's identifying information with a placeholder ("Customer A reported webhook issues"), preserving the organizational learning while removing the identifying connection.

The right approach depends on the deletion trigger. GDPR erasure requests require complete removal of all personal data, which means either full deletion or thorough redaction, anonymization may not satisfy the requirement if the remaining context is enough to identify the customer. Business-driven deletion (customer churned, data no longer needed) is more flexible and anonymization is usually sufficient.

Adaptive Recall handles customer deletion through a single API call that identifies all references, classifies each as sole-customer or mixed, executes cascading deletion across all storage layers, and verifies completeness. Mixed memories are flagged for review, with options to delete, redact, or anonymize based on your policy.