Form memory deliberately
Extract bounded candidates, preserve exact source evidence, process PII first, and separate proposals from committed writes.
Enterprise AI agent memory evaluation guide
How to evaluate memory for an AI agent that can take action.
A practical security, architecture, and procurement checklist for teams moving voice, support, and workflow agents from pilot to production.
Updated August 19, 2026 · 18 minute read
Executive answer
Do not evaluate agent memory as a better vector search.
Evaluate the whole path from untrusted conversation to persistent memory to tool execution. The system should prove who owns the memory, where it came from, whether it is current, whether the agent may act on it, and what the host reports afterward.
The minimum production record
user partition + source + confidence + validity + policy version + action decision + evidence IDs + request ID + execution receipt
Contents
Use this guide in architecture and security review.
1. Buying triggerWhen persistent memory becomes infrastructure
2. Reference architectureWhere memory sits in the stack
3. Threat modelWhat can fail across sessions
4. Control checklistQuestions for vendors and internal builds
5. Evaluation planTests before production approval
6. ContextDB mappingAvailable, alpha, and planned
1. Buying trigger
Persistent memory needs controls when agents act.
A support chatbot remembering a preferred language is one problem. An agent using remembered details to refund a payment, book a service, alter a plan, dispatch a worker, or update an account is a different problem.
You need a governed memory layer when:
- The same customer returns across calls, chats, or workflows.
- More than one agent or channel consumes the same context.
- Remembered details influence writes to a business system.
- A tentative statement must not become a permanent instruction.
- Security review asks who, what, when, why, and what happened next.
A generic memory API may be enough when:
- The agent only personalizes low-risk responses.
- Memory never leaves one application session.
- No tool changes money, access, schedules, plans, or records.
- Your team can accept application-level logs and manual deletion.
2. Reference architecture
Put memory between the agent and your database.
The model interprets language. The memory layer stores durable context and evaluates whether it may support an action. The host enforces the result. The CRM, booking system, payment system, or operational database remains authoritative.
Channelsvoice, chat, workflow
Agent runtimemodel + tools + orchestration
Memory controlscope + provenance + policy
Tool hostenforce decision
Systems of recordCRM, payments, scheduling, data
Separate conversation context from action evidence
Broad recall can make a conversation natural. Consequential tools should use a stricter action gate.
Keep enforcement in your host
The host executes only after an allowed decision, then reports succeeded, failed, or skipped with an idempotent receipt.
3. Threat model
Test the failures that appear after the original conversation is over.
Persistent memory changes the time horizon of an attack. A bad write can influence an unrelated session days later, when the original malicious input is no longer visible in the active prompt.
Cross-customer memory leakage
Failure: an observed memory ID or user identifier retrieves another customer or project.
Test: replay real identifiers with a different project key and user partition. Expect 404, never an empty-but-successful cross-scope response.
Memory and context poisoning
Failure: attacker-controlled or weakly sourced content becomes durable trusted context.
Test: inject an instruction through a transcript, third-party source, or tool result. Inspect whether it is rejected, marked suspect, or held for confirmation.
Provenance collapse
Failure: user-stated, agent-inferred, and imported data become indistinguishable after extraction.
Test: submit the same claim through three source types and compare confidence, confirmation, and action eligibility.
Stale or conflicting memory
Failure: an old preference or superseded instruction continues to drive actions.
Test: write a conflicting fact to the same stable slot. Verify which generation is current and whether the conflict blocks action.
Tool execution after ask or abstain
Failure: the model or host ignores the gate and calls a consequential tool anyway.
Test: force an ask or abstain result, simulate execution, and verify the receipt is retained as a policy violation.
Ambiguous retries
Failure: a network timeout creates duplicate memories, confirmations, or downstream actions.
Test: repeat each mutation with the same idempotency key and payload, then with the same key and a changed payload.
OWASP identifies Memory and Context Poisoning as ASI06 in its Top 10 for Agentic Applications 2026. Use that framework alongside your existing application and identity threat models.
4. Control checklist
Questions to ask before approving an enterprise memory service.
| Area | Question | Evidence to request |
|---|---|---|
| Tenancy | Is organization and project scope derived from the server credential? | Cross-org and cross-project replay tests. |
| User partition | Can a caller override or wildcard another customer's partition? | Identifier validation and cross-user 404 tests. |
| Credentials | Are API keys shown once, hashed at rest, scoped, and revocable? | Key lifecycle API and revocation test. |
| PII | Does detection and encryption happen before embeddings or model formation calls? | Data-flow diagram and stored annotation inspection. |
| Provenance | Does every fact preserve source type, confidence, and evidence? | Memory schema and conflicting-source test. |
| Formation | Can extraction propose candidates without committing them? | Propose/commit modes and bounded provider failures. |
| Action policy | Can conversational context be excluded from consequential tool decisions? | Separate recall and pre-action gate APIs. |
| Confirmation | Is human attestation scoped to the exact memory and customer? | Pending queue, confirm API, actor record, and foreign-ID tests. |
| Execution | Can the host report what it actually attempted? | Decision ID, terminal receipt, idempotency, and policy-alignment field. |
| Audit | Can an authorized customer independently verify an export? | Real entries, hash chain, asymmetric signature, published public key. |
| Logging | Are memory content, queries, credentials, and webhook URLs excluded? | Forbidden-field tests and sample structured logs. |
| Failure posture | What happens when metadata, memory, encryption, or audit storage is unavailable? | Fail-closed tests and readiness behavior. |
| Deletion | Can the vendor prove scoped deletion and retention behavior? | Deletion API, verification job, retention policy, and current limitations. |
| Identity | Does the service support your IdP, service identity, and provisioning model? | SSO, SCIM, workload identity, and roadmap status. |
| Encryption keys | Who controls the master key and its rotation? | KMS architecture, per-project data keys, BYOK policy, and revocation test. |
| Operations | What availability, backup, recovery, and data-location commitments exist? | Published commitments, status history, backup tests, and contract language. |
5. Evaluation plan
Run a narrow evaluation that can fail for a named reason.
Pick one workflow with an observable action. Do not start with a broad “remember everything” requirement.
- Define scope. One project, one user identifier scheme, one action, one operational system.
- Define allowed memory. List durable facts, forbidden data, source types, confirmation rules, and validity windows.
- Integrate the four-call loop. Remember, evaluate action, confirm when required, report execution.
- Run boundary attacks. Cross-user replay, foreign project key, poisoned transcript, conflicting fact, stale fact, duplicate retry.
- Trace one action. From conversation turn to memory candidate to decision to receipt to external reference.
- Verify operations. Revoke the key, stop a dependency, inspect readiness, and verify a signed audit export.
Suggested pass criteria
- Foreign project and user identifiers never return a scoped resource.
- Unconfirmed or contested memory does not produce
act. - Every tested consequential action has a decision ID and terminal receipt.
- Changing an idempotent retry payload returns a conflict instead of another write.
- Audit export entries contain no customer content and verify offline.
- The team can name which missing controls block production approval.
6. ContextDB mapping
How the current hosted alpha maps to the checklist.
Memory and action boundaries
- Org, project, and user partitions
- Source, confidence, confirmation, and stable slots
- Recall and separate pre-action evaluation
- Decision IDs and execution receipts
- Idempotent protected mutations
- Scoped memory, slot, and verified partition erasure
Operator and audit controls
- Owner, operator, and viewer roles
- Invites and scoped API-key lifecycle
- Metadata-only signed webhooks
- Entitlement-gated organization audit log
- Ed25519-signed export with real entries
Controls not available today
- SSO and SCIM
- KMS, key rotation, and BYOK
- Private connectivity and IP allowlists
- Residency and contractual retention
- Availability and recovery commitments
ContextDB has no compliance certifications or uptime commitments today. See the security page and current control table before beginning an evaluation.
Sources
External frameworks and buyer research used in this guide.
- NIST AI 600-1, Generative AI Profile: governance, provenance, pre-deployment testing, and incident disclosure.
- OWASP Top 10 for Agentic Applications 2026: agentic application threat categories, including Memory and Context Poisoning.
- Okta / AlphaSights enterprise buyer survey, January 2026: identity, least privilege, revocation, and audit requirements.
- PwC AI agent survey, May 2025: adoption, business functions, and trust in high-stakes agent tasks.
- CCW Digital / NiCE AI memory research: the customer effort created by cross-channel systems that forget.
Use the checklist on one real workflow.
Bring the architecture, action, data boundaries, and controls your review requires.