Persistent AI Agent Memory: From MCP Tool Calls to Lifecycle Hooks
Ray Smets ·
Persistent AI agent memory has two separate problems: keeping useful information, and making sure the next agent actually reads it. A durable store solves the first. Connecting that store through MCP does not, by itself, solve the second.
If retrieval and persistence exist only as tools the model may select, the agent must decide to use them. It can answer without looking up a previous decision, or finish without saving the reason behind a change. Better instructions help. They do not establish an execution boundary.
My architectural preference is straightforward: put required memory operations in the host’s control flow. Keep discretionary exploration available as tools. Lifecycle hooks can provide that boundary, but only when the host supports them and the plugin actually registers executable behavior.
MCP is the interface; tool selection is a policy
The MCP tools specification describes model-controlled tools while explicitly allowing other interaction patterns. An application can issue a tools/call request deterministically. Nothing about MCP requires waiting for a language model to suggest it.
The fragile arrangement is narrower: expose a memory service only through model-selected calls and rely on instructions to make every necessary call happen. The model has incomplete context, competing tasks, and no direct evidence of what it has not retrieved. Asking it to recognize the relevance of an unseen decision creates a circular dependency.
Those calls also often add steps to the foreground agent loop: infer a tool request, execute it, return the result, then continue inference. Parallel calls and host optimizations can change that sequence. Moving retrieval into application code can remove the selection step; it cannot remove the retrieval work or its latency.
What AI agent memory plugins actually add
A plugin can distribute connection settings, task instructions, commands, and specialist agents together. These are useful: the user gets a coherent workflow instead of a bare list of tools. Executable lifecycle hooks are a separate capability.
Claude Code, for example, documents plugin hook configuration and UserPromptSubmit hooks that can add context before a prompt is processed. This is a host-specific contract, not a portable property of every plugin system.
With an enabled, correctly registered hook, the triggering event invokes the handler without model tool selection. That is deterministic invocation. The event still has to occur, the process has to run, credentials have to work, and the handler has to return usable data. None of this guarantees correct memory.
| Arrangement | Invocation | Ordering |
|---|---|---|
| Model-selected MCP memory | The model chooses a tool | Retrieval follows that choice |
| Skills and MCP configuration | Instructions guide tool use | No lifecycle guarantee from packaging alone |
| Lifecycle handler calling MCP | The host dispatches a configured event | Host policy can await required retrieval |
What AgentleFS implements today
The AgentleFS plugin in this repository contains an HTTP MCP connection with OAuth, skills, commands, and agent instructions. It contains no lifecycle hook configuration or executable memory scripts. Installing it does not automatically retrieve context before inference or save conversations when a session ends.
The existing workflow is explicit and useful. On a catch-up request, the plugin’s instructions call brief_me once, use the returned work context to aim search, and read a few relevant documents. The brief includes things such as open work, messages, and changes near the identity’s work. It is orientation, not a summary of every document.
When the user asks to save the conversation, the sync-conversation-summary skill first browses accessible folders. It uses the destination the user named, an existing summary’s location, or the previous sync location; otherwise it asks. It writes a summary of at most 500 words from the conversation already in context. No AgentleFS tool fetches the chat history.
A new summary uses doc_create with action document, folder_path, name, and content. An existing summary uses doc_update with action replace, location, and content. The agent reports the returned citation and checks whether the write created an unexpected folder. Writing makes the document available within its existing permissions; it does not grant new access.
This provides a concrete handoff: save a decision and its reasoning into a chosen folder, then retrieve it during the next catch-up. It still depends on the request and the agent following the skill. The connection guide and AgentleFS documentation describe the available product; the lifecycle design below is a proposal.
Await retrieval; separate capture from maintenance
Required retrieval belongs before the inference that depends on it. A host adapter could resolve the authenticated identity and task, retrieve a bounded context set through MCP, validate the result, and attach cited content before invoking the model. If that retrieval is genuinely required, failure must prevent the dependent inference or explicitly move the task into a mode that does not require it.
Synchronous execution here means the host awaits completion. It does not mean zero latency, nor does awaiting network I/O require blocking the JavaScript event loop. The user still waits for the dependency. The engineering question is whether that wait buys information necessary to do the task correctly.
- Host receives the task
- Lifecycle handler retrieves authorized context through MCP
- Validate freshness and attach citations
- Run inference, or apply the failure policy
- Capture an approved memory candidate
- Commit capture and acknowledge it
- Worker summarizes and indexes asynchronously
- Later retrieval reads a versioned result
Persistence has a different boundary. Capture an authorized, bounded record durably before claiming it is saved. Then let workers summarize, classify, or index it asynchronously. A durable queue or transactionally recorded work item can survive the foreground process. An unawaited promise cannot make that promise.
AgentleFS already separates document commits from some derived work: its ingestion path queues real-model embedding jobs in the write transaction, and workers call the embedding service outside that transaction. That is existing asynchronous index maintenance. Automatic conversation capture and background summarization would be additional features.
Capture needs an explicit retention and permission policy; it is not permission to upload a transcript. A lifecycle event does not expand what the user authorized. AgentleFS’s current summary workflow intentionally sends only a compact summary. Any automatic capture feature would need its own opt-in scope and deletion behavior.
Claude Code’s asynchronous hook documentation distinguishes background execution from waiting. Background execution alone is not a durable queue. Required pre-inference context cannot arrive after inference and retroactively improve that decision.
The failure policy is part of the memory design
Set a retrieval deadline and a context budget. On timeout, optional background knowledge might permit a visibly degraded answer. Required operational instructions might require stopping. Merely awaiting a hook does not establish either policy: check the host’s timeout and error semantics for the specific event.
Retry transient failures within a bounded budget, with backoff. Treat a timed-out write as an unknown outcome, since the server may have committed before the response was lost. A retry should reuse a stable operation identifier. The key needs a defined scope, retention period, and payload-mismatch policy; a random new key on every attempt defeats deduplication.
AgentleFS already exposes idempotency_key on document writes and expected_commit for optimistic concurrency. Those primitives help callers handle retries and stale edits. They do not constitute a hook delivery guarantee, nor should they be generalized into an exactly-once guarantee for every tool.
For concurrent updates, read the current document, carry its expected commit into the write, and handle a conflict by rereading and reconciling. Blindly replacing one shared summary lets the last writer erase another agent’s reasoning. Independent immutable captures with a separate consolidation step are a useful proposed alternative, with their own storage and cleanup costs.
Staleness also has several meanings. A source connector can lag, an index can lag behind a committed write, and retrieved context can become outdated before an action. Preserve provenance and versions. Revalidate decisive facts near the action that consumes them. Search results in AgentleFS carry freshness and citation information; callers still have to interpret it.
Finally, instrument invocation, retrieval success, capture acknowledgement, processing lag, and conflicts separately. A hook that ran and returned irrelevant text is a successful invocation and a failed memory outcome. One green counter conceals that distinction.
When a simple MCP connection is enough
If the user explicitly asks to search a team document or save a note, a direct MCP connection can be sufficient. It is also reasonable when memory is optional, occasional misses are tolerable, or the application already controls retrieval deterministically. A plugin can improve discoverability and instructions without adding hooks.
The practical AgentleFS next step today is to connect a client, choose a folder with the intended readers, save one useful handoff summary, and verify that a later session can retrieve it. Check the stored document, not just the assistant’s acknowledgement.
For a future lifecycle integration, start with one host and one required context boundary. Specify the deadline, failure policy, authorization, and retry identity before adding automatic persistence. Persistent AI agent memory becomes dependable when the system makes its obligations explicit, and can show which of them actually completed.