FIG. 1 - R1 Updated 2026-06-20
Interactive scorecard / shareable result URL

Score memory readiness before you trust agent recall.

Memory readiness means your agent can recall useful facts without becoming a black box. Score the memory layer on inspectability, supersession, forgetting, portability, source breadth, and tenant isolation; then share the URL with the exact answers preserved for a technical review or vendor shortlist.

Fig. 2 six-dimension rubric / URL state
FIG. 2

How ready is your memory layer?

Answer each dimension with yes, partial, or no. The score updates in the browser and the result URL preserves only those six answers, so it can be shared without creating an account or storing personal data.

D.01 Inspectable

Can a human inspect why this memory was recalled?

Ready memory exposes the retrieved source, scope, rank, and reason before a team has to trust the answer. If the agent cannot show the memory trail, debugging becomes guesswork.

NIST frames trustworthy AI as something organizations manage and evaluate, not a vague promise. For agent memory, that means the product needs visible evidence: source artifact, retrieval trace, current-state signal, and tenant scope.

Read C2: Inspectable Agent Memory
Fix first

Add a retrieval log and a user-facing memory inspector before expanding the memory store.

D.02 Supersession-aware

Does memory handle facts that changed?

Ready memory keeps old facts legible as history while marking newer sources as current. It does not rely on recency alone or let stale memories compete equally with replacement facts.

Agent memory fails quietly when a product plan, policy, price, owner, or ticket status changes. Supersession metadata lets teams see what replaced what instead of treating every remembered fact as equally valid.

Read C3: Supersession-Aware Memory
Fix first

Track source versions, current-state flags, and supersedes relationships before promising temporal graph behavior.

D.03 Provably forgettable

Can you prove the agent forgot a memory?

Ready memory has a deletion path that reaches source artifacts, summaries, embeddings, retrieval caches, and derived records controlled by the product. The proof is an auditable trail, not a support ticket.

GDPR Article 17 defines erasure rights for qualifying personal data, and the EU AI Act raises logging expectations for high-risk AI systems. Even outside those regimes, buyers expect memory lifecycle controls.

Read C4: Provable Forgetting
Fix first

Create delete handles, tombstones, and verification checks before calling memory erasure complete.

D.04 Portable

Can memory move across agents and frameworks?

Ready memory is not trapped inside one model, IDE, or framework. It has a documented interface, export path, and source-level evidence so teams can move clients without rebuilding trust from scratch.

The Model Context Protocol exists to standardize how LLM applications connect with external context and tools. Portability is the practical buyer question: can the same memory serve Claude Code, Cursor, and future clients?

Read the glossary: Memory portability
Fix first

Expose memory through an open interface and keep exportable source identifiers with each remembered fact.

D.05 Multi-source

Can memory span more than chat history?

Ready memory can combine documents, tickets, pages, conversations, and tool outputs while keeping their provenance separate. It should not flatten every source into anonymous text chunks.

Useful work agents answer from messy operational sources. Multi-source memory needs consistent metadata, source type, version, and permission boundaries so retrieval does not trade breadth for ambiguity.

Read C1: Agent Memory guide
Fix first

Normalize source metadata first: source system, artifact id, version, owner, timestamp, and allowed scope.

D.06 Tenant-isolated

Is memory isolated by tenant, workspace, and user scope?

Ready memory applies access scope before retrieval, not after an answer is drafted. A tenant, workspace, library, or user boundary should be part of every write, read, deletion, and audit event.

Memory is higher-risk than ordinary search because recalled facts can silently shape future answers. Tenant isolation prevents one customer, workspace, or user context from leaking into another agent's result.

Read the glossary: Tenant isolation
Fix first

Make tenant and permission scope required query predicates and log the scope used for every recall.

Fig. 3 score bands / pilot gates
FIG. 3

What should the score change?

This is a readiness rubric, not a benchmark. Treat the score as a way to decide which control should block a pilot, procurement review, or migration plan.

0-2 / 6

Not ready for durable agent memory

The agent may remember things, but the memory layer is not reviewable enough for production decisions. Start by adding inspection, scope, and deletion evidence before broadening sources.

Next step

Pick one production workflow and instrument the recall path before adding more memories.

2.5-4 / 6

Partially ready, with procurement gaps

The foundation is usable, but one or two weak dimensions can still break trust. Buyers should treat the missing controls as explicit evaluation tasks, not roadmap assumptions.

Next step

Turn every partial answer into a concrete acceptance test for your shortlist.

4.5-6 / 6

Ready for an inspectable memory pilot

The core control plane is present enough to run a focused pilot. Keep benchmark and accuracy claims out of the decision until you test against your own sources.

Next step

Run a pilot with real tenant-scoped sources, deletion checks, and recall inspection.

Fig. 4 shareable state / no server storage
FIG. 4

Which result URL should you share?

The link below stores the six checklist answers as query parameters. Opening that URL reproduces the same yes, partial, and no choices in any browser.

Fig. 5 official references / internal vocabulary
FIG. 5

What sources ground the rubric?

The six dimensions combine Answer Engine's vocabulary posts with public control-plane references for AI risk, MCP portability, erasure, and traceability.

GDPR Article 17

Article 17 is the regulatory anchor for right-to-erasure thinking in memory lifecycle design.

Fig. 6 comparison hub / same columns
FIG. 6

Which systems should you compare next?

Once the missing controls are clear, compare memory systems on the same columns instead of brand language or unverified performance claims.

Fig. 7 FAQPage schema
FIG. 7

What do teams ask about the checklist?

What is a good memory readiness score?

A score above 4.5 out of 6 is ready for a focused pilot, not a universal benchmark. The goal is to prove inspectability, supersession, forgetting, portability, multi-source recall, and tenant isolation on your own sources.

Does this checklist measure memory accuracy?

No. It is a readiness rubric for controls and buyer evidence. Do not treat it as an accuracy benchmark or publish a performance number from it.

Why does the URL include my answers?

The page encodes only the six yes, partial, or no answers in the query string so a shared link can reproduce the same result without storing user data server-side.

Should every team weight the six dimensions equally?

No. Equal weighting makes the public rubric easy to share. Regulated, multi-tenant, or customer-facing agents should usually weight deletion proof and tenant isolation more heavily in their internal review.