AIエージェントに永続記憶を持たせる設計：仮・確定・実働の3層 AIエージェントに永続記憶を持たせる設計：仮・確定・実働の3層

One of the most persistent frustrations in long-running AI agent deployments is context loss. No matter how capable the underlying model, each new session starts fresh — previous assumptions, user preferences, and accumulated knowledge simply vanish. This article tackles that problem head-on by proposing a three-tier memory architecture designed to give agents genuine, structured persistence across conversations.

The three tiers are labeled provisional, confirmed, and active memory. Provisional memory acts as a volatile scratchpad, capturing information generated within a single session without any guarantee of long-term retention. Confirmed memory is the durable layer — information that has been explicitly approved for storage, either by the user or by an operator-defined policy. Active memory is the runtime layer, dynamically assembled from confirmed memory based on the current task's needs. Think of it as the agent's working memory: contextually relevant, freshly composed, and discarded when no longer needed.

The value of this separation lies in what it makes independently optimizable. Each tier can apply different retention policies, access controls, and retrieval strategies without interfering with the others. Provisional memory can be aggressively pruned; confirmed memory can be versioned and audited; active memory can be tuned for low-latency recall. This modularity is difficult to achieve when memory is treated as a single undifferentiated store.

The design sits against a well-understood backdrop. Even as context windows have expanded dramatically — some models now supporting hundreds of thousands of tokens — stuffing entire conversation histories into every prompt remains impractical at scale due to cost and latency. RAG-based approaches using vector databases are now standard for external memory retrieval, but they often lack a principled mechanism for deciding what should be committed to long-term storage in the first place. The three-tier model offers an explicit decision boundary for exactly that question.

The timing is also notable given the growing adoption of MCP (Model Context Protocol), which standardizes how agents connect to tools and data sources. Implementing a memory store as an MCP server could allow multiple agents to share a common confirmed-memory layer — a pattern that would be particularly relevant for multi-agent pipelines or shared assistant deployments within an organization. Whether the article explicitly addresses MCP integration is unclear from the available context, but the architectural alignment seems natural.

The broader ecosystem is moving in the same direction. Projects like MemGPT and LangMem have explored hierarchical and self-editing memory systems for agents, and memory management is increasingly treated as a first-class concern in agent frameworks rather than an afterthought. The three-tier model described here offers a pragmatic, implementable structure that developers can adapt without committing to a specific framework.

For anyone building agents intended to operate autonomously over weeks or months, memory architecture is not a secondary concern — it shapes how the agent accumulates judgment, maintains consistency, and earns user trust over time. This article appears to offer a concrete starting point for thinking through that design deliberately.