A durable memory store's enumerated action list is its real retention control, not the policy document filed beside it. Read the verb list before you read the policy.
I run security and DevOps for a fintech platform that answers to more than 1,500 financial institutions, so I sit in a lot of AI architecture reviews. The first artifact I ask for has changed. It used to be the data-flow diagram. Now it is the tool manifest, the literal list of actions the system exposes to callers, because that list is what it will actually permit. The retention paragraph in the design doc is intent. The manifest is the machine.
Agent memory is where the gap between those two has gotten widest. The pattern has settled into something sensible: stand up a durable store outside any single AI product so context captured in one tool is reachable from another, wire it in over MCP, let semantic search find records by meaning rather than exact phrasing. I have recommended that architecture. But these stores reach their clients through a fixed menu, and I have read enough of those menus to know the shape before I open one: a verb that writes a record, a verb that searches by meaning, a verb that lists what is recent, a verb that counts what is stored.
Capture, search, list, count. Four verbs, and none of them is delete.
The manifest is the boundary, which is exactly why a missing verb is a finding
Start with the mechanics, because they are stricter than people assume. Under the Model Context Protocol tools specification (opens in new tab), a client discovers what a server can do by sending tools/list, and a server declaring the tools capability must respond with the set of tools currently available to that caller. Invocation goes through tools/call by name. Ask for something not on the list and you get a JSON-RPC protocol error, code -32602, message Unknown tool. No escape hatch, no generic query verb, no raw pass-through unless somebody built one.
Read that as a security engineer and your first reaction is relief. An enumerated tool list is a genuine access control, which is more than most things in the agent stack can claim. It is least functionality at the protocol layer, and it beats the alternative I still find in production: a database credential handed to a model with a paragraph of prose asking it to be careful. A wall written into a prompt is an instruction. A wall written into the manifest is a wall.
The problem is that a fence is also a ceiling. Whatever is absent from the manifest is a capability the system does not have on that path, for anyone. So when the design doc says records are purged after ninety days and a data subject's records come out on request, and the manifest says capture, search, list, count, the policy describes an operation the interface cannot perform. That is not a roadmap gap. In my notes it goes down as a control that does not exist.
Capture, search, list, count is a system of record with no eraser
Sort those verbs by what they do to a record's lifecycle. One creates. Two read. One counts. Zero modify, expire, redact, or remove. It is not an unfinished product. It is a finished product for a use case that never contemplated getting anything back out: defensible for a personal scratchpad, disqualifying the moment the store holds anything about a customer.
Under the GDPR (opens in new tab), Article 17 gives a data subject the right to obtain erasure of personal data from the controller on any of several enumerated grounds, and Article 19 obliges the controller to communicate that erasure to each recipient the data was disclosed to unless doing so proves impossible or disproportionate. California is more prescriptive. Cal. Code Regs. Tit. 11, § 7022(b)(1) requires a business to comply with a deletion request by permanently and completely erasing the personal information from its existing systems (opens in new tab), deidentifying it, or aggregating it, and § 7022(b)(2) requires notifying its service providers and contractors to delete it from their records too. Neither obligation is satisfiable by a store whose interface stops at count, and both reach the record wherever it sits. Nothing is waived because somebody called the store context rather than a database.
The objection arrives within a minute every time: we will just run a delete against the table. Of course you can. Look at what you just built. Your deletion control lives outside the interface you documented, executed by a human holding a privileged credential, producing no receipt where every other interaction with that store is logged. When I argued that agent memory is a data-residency problem, the ask was to bound retention and prove deletion. I would sharpen it now. Prove it at the interface, or you have not proven it, you have promised it.
Two menus, and the second one is what your examiner is asking about
The fix is not handing the model a delete verb. A semantic-search-driven agent choosing which memories to destroy is an incident report I do not want to write. The spec already provides the seam: the same tools page states that the returned set may vary by the authorization presented on the request, so a server can return only the tools the caller's granted scopes permit. The tool list is a function of credentials, which means you can have two manifests. Keep the agent-facing one narrow. Put the lifecycle in the operator-facing one, and require it before the store takes its first production write, while these verbs are still cheap.
delete_by_id: remove the record and its embedding together, hard. A soft-delete flag that leaves the vector searchable is not deletion, it is a filter you are trusting the query path to honor.purge_by_subject: remove every record about a named person or account, which forces you to have stored who each record is about, the difference between a request you can answer and one you can only apologize for.export_by_subject: produce everything the store holds on one subject in a documented format, because access requests arrive alongside deletion requests.list_expired: enumerate records past their retention date, so the schedule in your policy has a query behind it, not a paragraph.redact_in_place: strip a classified element from a record without destroying the surrounding decision history, for when a card number lands inside an otherwise legitimate note.- A receipt on every one: who called it, with which credential, against which records, when, with what result. Evidence should fall out of the operation, not get assembled from screenshots.
A retention rule nobody can read at the call site is a comment
The most useful governance guidance in the MCP spec sits in its non-normative notes on stateful tools: because handles outlive any single connection, the server's retention policy should be stated in the creation tool's description so the model can see it when it decides to create state. That inverts how most memory designs treat retention, which is not only a property of the store. It is information the caller needs at the moment it writes.
If your capture verb's description does not say how long the record lives, which classes of content are permitted, and what happens at expiry, the model writing to it cannot reason about any of that, and neither can the reviewer reading the manifest. I have watched a well-intentioned agent fold a support thread into durable memory because the tool it was handed was called capture and described as saving something useful for later. It did exactly what the description invited. A tool description is not documentation. It is the only policy the model will ever actually read.
Bringing the store in-house moves custody, it does not remove the sub-processor
Here I want to correct something I published earlier this month. In context custody is a concentration risk I argued that owning the context store is the cheap version of owning the harness, and that most companies should do the cheap version first. I still believe it, but I did not qualify it carefully enough.
Semantic search is what makes these stores worth building, and it works by turning text into vectors. That means an embedding call on every write and, less obviously, on every read, because the query has to land in the same vector space as the corpus. If that embedding model is a hosted API rather than something inside your boundary, every sentence you save and every question you ask crosses your tenant boundary before the store can do its job. You did not remove the third party. You moved it from the front of the system into the middle, where it is easier to leave off a data map.
The consequence is specific. An embedding provider processing personal data on your behalf belongs in your Article 30 records of processing, and where your own company is itself a processor for its customers, that provider is a sub-processor, which under Article 28(2) cannot be engaged without the controller's prior specific or general written authorisation. A store you built yourself, on infrastructure you pay for, can still be a sub-processor arrangement that belongs in the DPA. The vectors are also derived assets, the category I said was missing from most AI contracts. Regenerating a year of embeddings after a model is deprecated is a migration project, and if the vectors are all you kept, an impossible one.
The same test applies to the markdown file on somebody's laptop
Run the verb-list test on the low-tech version and it fails harder. The advice going around is to keep one context file with your project history, your last decision, the reviewers, and what the client approved, then point every AI tool at it. It works, which is the problem. It spreads because it produces visibly better answers, and it generates a class of record nobody registered.
Look at what accumulates in that file. Approvals. Decisions with customer impact. Reviewer sign-offs. Commitments made to a counterparty. Those are control records, and control records have four properties: a named owner, a retention schedule, tamper evidence, and reachability when somebody with subpoena power asks. A personal markdown file has none of the four. Its verb list is whatever the owner feels like doing that afternoon, the broadest possible manifest and the least accountable one.
The sharp edge is preservation. Rule 37(e) of the Federal Rules of Civil Procedure (opens in new tab) reaches electronically stored information that should have been preserved in the anticipation or conduct of litigation, was lost because a party failed to take reasonable steps to preserve it, and cannot be restored or replaced through additional discovery. On a finding of prejudice the court may order measures no greater than necessary to cure it, and on a finding of intent to deprive another party of the information's use it may presume the lost information was unfavorable, instruct the jury to presume it, dismiss the action, or enter default judgment. A hold notice that reaches mail, chat, and the document system but not the file where the approval was recorded is a preservation program with a hole in the middle.
Offboarding is the quieter edge. Somebody leaves, the laptop is wiped on schedule by a process working exactly as designed, and the record of what a client approved in March goes with it. Nothing alarms. The team's AI answers just get worse and nobody attributes it correctly for a quarter. I wrote about where the shadow-AI line actually falls and named the crossings that should trigger review: customer data, a login, durable storage, sharing. A prose file of decisions trips almost none of them, which is why it never gets registered, and why that list needs a fifth crossing about record class.
None of this is the employee's failure. It is ours. An organization that has not supplied a shared, owned, retention-scoped context store has decided by default that its decision record lives on laptops. Two controls, narrow enough to survive a policy review: name the record classes that may never be authoritative in a personal context file, approvals and customer commitments at the top, and supply the sanctioned store with an owner, a retention line, and a delete verb, so the governed path is the convenient one.
Ask for the manifest before you ask for the policy
This is a five-minute review you can run on something already in production. Call tools/list on every memory server your teams have wired up and write the verbs down. Put that list beside your retention schedule and your data-subject-request runbook and check whether those obligations have operations behind them. Where a verb is missing, log it as an open finding with an owner and a date rather than a feature request, because the difference between those two words is what an examiner reads off your risk register. Then push it into procurement, since each verb is a question a vendor can answer in a sentence.
I would genuinely like to hear from anyone who has run this against a vendor-hosted memory product and gotten a straight answer, because what I keep hitting is a support reply that describes a policy where a verb should be. And if you have built the two-manifest split, agent-facing menu narrow and operator-facing menu complete, tell me how you scoped the credential that gets the second one. That is where my own designs still feel one revision short.