AI SDR Memory in 2026 — Persist Facts, Expire Inferences, Limit Writes

Define four memory classes

The first class is an observed fact: a statement directly supported by an identified source at a known time. Examples include a company announcing a facility, a buyer stating a requirement in a call, or an account owner recording a confirmed procurement date. Observations should preserve the source, retrieval or event time, entity identity, and the exact scope of what was observed. They should avoid adding interpretation to the record.

The second class is a hypothesis: a sales interpretation that may help choose the next research question or conversation. A new facility may suggest a logistics need, but that need is not established until evidence supports it. Hypotheses should identify their author or generating process, supporting observations, confidence, and a short expiry. They should never be silently rendered as buyer facts. A hypothesis can be valuable while remaining explicitly uncertain.

The third class is a commitment: a promised action, agreed boundary, consent state, requested follow-up, or buyer preference that changes what the workflow may do. Commitments need precise parties, timing, scope, and status. A buyer asking to reconnect next quarter is different from an internal suggestion to do so. Because commitments affect external behavior, write access should be narrower and execution should recheck whether the commitment is current.

The fourth class is a derived summary: a concise representation assembled from multiple records for retrieval or handoff. Summaries improve usability but can blur uncertainty and omit exceptions. They must link to the records they summarize, show when they were generated, and be invalidated when source records change. A summary is a view, not the authoritative source.

Give every memory a durable envelope

Each memory should carry an identifier, account and contact scope, class, statement, source references, creator, creation time, effective time, confidence where relevant, retention rule, access scope, and current status. Add links to superseding or contradicted records rather than overwriting history. This envelope allows a retrieval system to select appropriate context and allows an operator to explain why it appeared.

Keep identity resolution outside free text. The record should point to canonical account and contact identifiers while preserving source aliases. If identity is uncertain, mark it and prevent the memory from influencing external action. A precise memory attached to the wrong person is more dangerous than an incomplete record because its precision encourages trust.

Store the smallest useful statement. Avoid retaining an entire conversation simply because extraction is inconvenient. A confirmed requirement, the relevant evidence, and the authorized follow-up may be enough for the next step. Raw transcripts can contain unrelated personal details, credentials, or sensitive discussion. Their retention and access should follow a separate policy, and summaries should not broaden access to material a user could not otherwise see.

Restrict who and what can write

Reading context and creating durable memory are different permissions. A research agent may propose a fact record from an approved source but should not create a buyer commitment. An outreach agent may draft a summary but should not rewrite an opt-out. A human seller may confirm a call outcome, while certain policy or consent fields may be controlled by systems of record. Enforce those boundaries at the write service rather than relying on instructions in a prompt.

Use field-level and class-level permissions. For each writer, define which memory classes it can propose, create, amend, or invalidate. Automated writers should include the tool version and operation identifier. High-consequence writes can enter a pending state until another rule or authorized person confirms them. A rejected proposal should remain visible for audit without becoming retrievable as active context.

Prevent indirect writes. A retrieved web page or email can contain text that tells an agent to change a record, reveal data, or ignore policy. Treat source content as evidence, not authority. OWASP's GenAI security guidance catalogs risks relevant to LLM and agentic systems; the concrete sales control is to ensure untrusted text cannot grant itself a memory class, permission, or retention period.

Set expiry by meaning, not storage cost

A single retention period is too crude. Company identity may remain stable, a role assignment may age quickly, a campaign response may be relevant briefly, and an explicit suppression state may need to persist as long as policy requires. Set a default time-to-live for each class and field, then allow narrower overrides when the evidence warrants them.

Expiry should change behavior. An expired hypothesis should no longer appear in drafting context. An aging observed fact may remain visible to researchers but require confirmation before external use. A commitment reaching its due date should create a review event, not automatically authorize a message. The system must distinguish expired, superseded, corrected, disputed, deleted, and active records rather than collapsing them into present or absent.

Refresh does not mean copying the old statement with a new timestamp. The refresh process must revisit the source or obtain new evidence. If an account page no longer lists a facility, preserve the prior observation as historical and add the new state. If the source cannot be reached, mark the record unresolved; do not extend its life because no contradiction was found.

Design retrieval as a governed tool

Microsoft's guidance on agentic retrieval describes an agent deciding which retrieval tools to call, evaluating intermediate results, and iterating until it has sufficient context. It also notes added latency, token use, and complexity. For an AI SDR, retrieval should be bounded by the active task, account, permission, and memory class. More context is not automatically better context.

Define retrieval policies for each action. Research may retrieve current observations and hypotheses. Qualification may retrieve required evidence and active commitments but exclude expired summaries. Drafting may receive only externally usable facts and buyer preferences, with source links and uncertainty. Sending should recheck commitments and restrictions from authoritative records rather than trust the draft's embedded context.

Log the query intent, filters, returned memory identifiers, and downstream action. Avoid logging sensitive content redundantly; identifiers and policy decisions often provide enough traceability. Set limits on retrieval depth and iteration so an agent cannot expand from one account into unrelated records. Review retrieval failures as carefully as write failures, because missing a suppression or commitment can be consequential.

Make correction and deletion first-class workflows

A seller, buyer, source update, or automated check may reveal that a memory is wrong. Correction should create a new record or event linked to the original, identify the authority and evidence, and invalidate derived summaries. Downstream queues should be notified when the correction changes eligibility, messaging, or ownership. Silent in-place edits destroy the ability to understand prior decisions.

Deletion needs clear semantics. Some requests require removing content; others require preserving a minimal restriction so the system does not reacquire and reuse the same information. Legal and privacy owners should define the policy. Operationally, the workflow needs to propagate deletion to indexes, caches, embeddings, exports, and generated summaries, then record completion without retaining the deleted substance in a log.

Test deletion before claiming it works. Create a synthetic record, let it flow through every permitted store, delete it, and verify each copy is gone or transformed according to policy. Repeat after architecture changes. A delete button attached only to the primary database is not a deletion system if retrieval still returns an embedding or cached summary.

Measure memory quality and risk

NIST's AI RMF Playbook recommends detecting, tracking, and measuring known risks, errors, incidents, and negative impacts, defining acceptable performance limits, documenting what cannot be measured, and comparing performance before and after deployment. Translate that discipline into memory-specific measures: unsupported-memory rate, stale retrieval rate, identity conflicts, unauthorized-write attempts, correction latency, deletion completion, summary invalidation, and the share of drafts changed because memory was inappropriate.

Sample by class and writer. A low overall defect rate can hide a severe problem in commitments or a new automated writer. Review whether retrieved memories actually helped the task, because accurate but irrelevant context adds cost and can anchor the model on old narratives. Measure the operator burden needed to maintain quality. If the ledger requires constant repair, reduce what the system persists or narrow write authority.

Set stop conditions. Pause a writer when it creates unsupported facts, repeatedly attaches records to the wrong entity, or fails to honor invalidation. Disable a retrieval path when it surfaces expired or unauthorized memories. Preserve the evidence needed for diagnosis while preventing further external action. The system should fail into a controlled review state, not continue with a warning hidden in logs.

Implement the ledger in four weeks

During the first week, inventory every store currently acting as memory: CRM fields, call notes, sequence history, vector indexes, model threads, spreadsheets, and caches. Choose the four classes and identify authoritative systems for identity, consent, ownership, and commitments. Trace several real decisions backward to discover hidden copies.

During the second week, define envelopes, writers, retention defaults, and correction states. Migrate a small account cohort and mark uncertainty rather than forcing every old note into a clean class. Create tests for wrong identity, contradictory facts, expired hypotheses, changed commitments, and untrusted instructions inside source text.

During the third week, put retrieval behind task-specific policies and instrument the decisions. Run in shadow mode: show what memory would have been supplied without allowing it to drive outreach. Review omissions and inappropriate inclusions with sales, RevOps, security, and privacy owners.

During the fourth week, enable bounded writes and retrieval for one workflow. Require review for commitments and external-facing facts until the evidence supports narrower oversight. Run a correction and deletion drill. Expand only when the team can explain what was remembered, why it was available, who wrote it, and how it can be changed.

Remember less, but remember deliberately

Useful AI SDR memory is selective. It preserves durable, supported context; expires speculation; protects commitments; and makes summaries subordinate to evidence. The objective is continuity with accountability, not an endless dossier.

Create a one-page memory policy before adding another long-term store. List the four classes, their permitted writers, default expiry, retrieval scopes, correction path, and deletion behavior. Then inspect one week of active memories. Any record that cannot answer those questions should not be allowed to shape the next buyer interaction.