Integrating Agent Memory with MCP Context
I. The Core Role of Memory in Agent Systems
What makes an Agent intelligent is not only its ability to call Skills to complete tasks, but also its ability to remember the past, understand the present, and predict the future. Memory is the foundation for Agents to achieve continuous conversation, personalized service, and continuous learning.
In traditional Agent architectures, memory is typically stored as conversation history within the Agent framework. Each user request and Agent response is appended to a message list, serving as context for the next reasoning round. This short-term memory is simple and effective but has obvious limitations: memory cannot be shared across sessions, each new conversation starts from scratch; memory cannot be accessed by Skills, Skills only receive current call parameters and cannot see previous interactions; memory lacks structured management, making it impossible to distinguish important information from trivial details or to enable long-term storage and retrieval.
MCP’s Context mechanism provides a natural carrier for standardizing Agent memory. Context is the contextual information carried with each Action call, passed from Agent to Skill and optionally updated and returned by Skills. Integrating memory into Context means memory can cross the boundary between Agents and Skills, achieving true integrated design.
This chapter will explore the types of Agent memory, their mapping to MCP Context, how to carry and update memory in Actions, and practices for memory security and privacy protection.
II. A Typology of Agent Memory
Before designing a memory system, we need to understand what types of memory an Agent needs. Based on storage duration and usage scenarios, Agent memory can be divided into three categories.
Short-term memory corresponds to the interaction history within the current session. It includes user questions, Agent thought processes, Skill call records, intermediate results, and more. Short-term memory is characterized by limited capacity, strong timeliness, and frequent updates. In the MCP system, short-term memory is best placed in Context and passed with each Action.
Long-term memory is information that is persisted across sessions. It includes user preferences, historical behavior patterns, knowledge base fragments, previously solved problems, and more. Long-term memory is characterized by large capacity, retrieval rather than full usage, and the need for indexing and query mechanisms. Long-term memory is not suitable for direct transmission in Context; rather, it should be accessed through dedicated memory Skills.
Working memory is the intermediate state of the Agent’s current task. It is like a scratchpad for human thinking, used to temporarily store partial results, record to-do items, and track task progress. The lifecycle of working memory is typically within a single task and can be discarded after task completion. Working memory can be placed in Context, but care must be taken to control its size to avoid bloat.
III. Mapping MCP Context to Memory
MCP Context is a structured set of key-value pairs passed between Agents and Skills. Integrating memory into Context requires designing clear field conventions.
Short-term memory can be mapped to the conversation_history field in Context. This field is a list of messages, each containing role, content, and timestamp. To control Context size, conversation history can be truncated or compressed with summarization. When history exceeds a certain length, a dedicated summarization Skill can be triggered, and the summary result placed back into Context.
Working memory can be mapped to the working_memory field in Context. This is a key-value map storing temporary variables for the current task. For example, in an order processing task, it can store the current order number being processed, user information already verified, and the next operation to be performed.
Long-term memory is not placed directly in Context but is referenced through the memory_refs field. This is a list of memory identifiers. Skills can retrieve the complete content from long-term memory storage based on these identifiers. This approach keeps Context lean while allowing Agents to access rich historical information.
IV. Carrying and Updating Memory in Actions
When an Agent calls a Skill, it should place available memory into Context. Short-term memory and working memory go directly into their respective fields. Long-term memory is passed through reference identifiers.
During Skill execution, the Skill can read memory from Context to guide its behavior. For example, a recommendation Skill can read user historical preferences to adjust recommendation results. An order query Skill can read the order number currently being processed, eliminating the need for the Agent to pass it again.
More importantly, Skills can update memory. After Skill execution completes, it can write new information back to specific fields in Context. For example, a payment Skill can write the payment result to working memory for use by subsequent Skills. A user profile Skill can write newly discovered behavioral patterns to long-term memory.
The MCP protocol itself does not specify memory update mechanisms, but the Peta control plane provides a standard pattern: Skills can include a memory_updates field in the ActionResult. The gateway updates memory in Context based on this field and returns the updated Context to the Agent. After receiving the ActionResult, the Agent merges the updates into its own memory storage.
V. Memory Security and Privacy Protection
Memory often contains sensitive information, such as user identity, payment credentials, and conversation content. Integrated memory design must thoroughly address security and privacy.
First, the principle of least exposure for memory. Skills should only access the memory they need, not all memory. When constructing Context, the Agent should, based on the target Skill’s permission declaration, only include memory relevant to that Skill. Peta’s policy engine can configure memory access rules, such as the price query Skill can read user preferences but cannot read payment information.
Second, memory desensitization and anonymization. For memory containing personally identifiable information, it should be desensitized before being placed into Context. For example, replace a user’s full name with a nickname or ID, and模糊化 addresses. Desensitization rules can be configured in Peta Console and automatically applied during Context construction.
Third, encrypted storage of memory. Long-term memory and memory in audit logs should be encrypted to prevent data leakage. Peta uses AES-256 encryption to store all memory data, with encryption keys managed by the customer.
Get Zhangshuang’s stories in your inbox
Join Medium for free to get updates from this writer.
Fourth, memory lifecycle management. Users have the right to delete their own memory. Peta provides a memory deletion API that can delete all related memory based on user identifiers, meeting compliance requirements such as GDPR.
VI. Typical Scenario Examples
Scenario one: Multi-turn conversation with customer service Agent
The user first says I cannot find my order. The Agent calls the query_order Skill, passing the user ID. The Skill returns a list of orders, and the Agent stores it in working memory. The user then says help me cancel the first one. The Agent retrieves the first order’s ID from working memory and calls the cancel_order Skill. The user then says refund to the original payment method. The Agent again retrieves order information from working memory and calls the refund Skill.
Throughout the process, the Agent does not need the user to repeat order information. Working memory maintains state across different Skill calls.
Scenario two: Personalized recommendation Agent
When a user first uses a recommendation Agent, the Agent calls a preference_discovery Skill to collect user preferences through conversation. The Skill writes preferences to long-term memory. The next time the user uses the Agent, the Agent loads preferences from long-term memory into Context. The recommendation Skill reads these preferences and provides personalized recommendations.
If the user changes their preferences, the Agent calls a preference_update Skill, which updates the corresponding entries in long-term memory.
Scenario three: Memory sharing in multi-Agent collaboration
In complex tasks, multiple Agents may need to share memory. The main Agent breaks down the task and passes part of its working memory to sub-Agents. After completing subtasks, sub-Agents return updated working memory. The main Agent merges the results from sub-Agents into its own working memory for subsequent decision-making.
MCP’s Context passing mechanism naturally supports this memory sharing. Sub-Agent calls are essentially Skill calls that can receive and return memory fields in Context.
VII. Engineering Practices for Memory Integration
In real engineering, integrating memory into MCP Context requires following these best practices.
First, standardization of memory fields. To avoid field name conflicts between different Skills, using namespaces is recommended. For example, preference.color, order.current_id, and payment.status. Peta provides a Schema registry where Skills can declare which memory fields they read and write, with runtime validation.
Second, memory size control. Context is transmitted over the network, and overly large Context affects performance. The length of conversation_history should be limited, with超出 messages summarized and compressed. Peta provides an automatic summarization Skill that can be triggered when Context size reaches a threshold to compress conversation history into a summary.
Third, memory conflict resolution. When multiple Skills update the same memory field simultaneously, conflicts may arise. Peta’s policy engine supports configurable conflict resolution strategies, such as last-write-wins, version vectors, or rejecting conflicting updates and requiring the Agent to retry.
Fourth, memory version evolution. As Agent capabilities grow, memory structures may need to change. Peta supports version management for memory schemas. Old memory data can be automatically migrated to new versions or compatibility-converted when read.
VIII. Summary: Memory Is the Carrier of Agent Intelligence
The core conclusions of this chapter can be summarized as follows.
First, memory is the foundation for Agents to achieve continuous conversation, personalized service, and continuous learning. MCP’s Context mechanism provides a natural carrier for standardizing memory.
Second, Agent memory is divided into three categories: short-term memory, working memory, and long-term memory. Short-term and working memory are suitable for transmission in Context, while long-term memory is accessed through reference identifiers.
Third, short-term memory maps to conversation_history in Context, working memory maps to working_memory, and long-term memory is referenced through memory_refs.
Fourth, Skills can read memory from Context to guide their behavior and can update memory through memory_updates in the ActionResult.
Fifth, memory security and privacy protection require following principles of least exposure, desensitization and anonymization, encrypted storage, and lifecycle management.
Sixth, engineering practices require standardizing memory fields, controlling memory size, resolving memory conflicts, and managing memory versions.
Memory is the carrier of Agent intelligence. Integrating memory into MCP Context, enabling memory to flow freely across the boundary between Agents and Skills, is a key step in building intelligent, coherent, and personalized Agent systems.
In the next chapter, we will discuss streaming Skill invocation, MCP’s support for long-running tasks.
