In recent years, large language model applications have undergone significant changes. Models can understand longer texts, call more tools, and are increasingly being deployed in real-world scenarios such as customer service, operations and maintenance, R&D, and data analysis. AI is no longer limited to answering individual questions, but is gradually becoming involved in task execution, result analysis, and subsequent decision-making. As a single Q&A interaction evolves into an ongoing task, a new question emerges: How can an Agent remember the past?
Here, remembering goes far beyond simply storing chat history. An Agent needs to know where a task has progressed, which approaches have been tried, which methods have already failed, and what preferences the user has. It also needs to understand the business knowledge required to complete the task.
Take the R&D and operations of MARS3 as an example. If an Agent is to assist with explaining parameters, analyzing code, or troubleshooting issues, it needs to understand MARS3's architectural design, storage mechanisms, parameter definitions, and historical cases. This information may come from product documentation, design proposals, and technical articles, as well as from past discussions, tests, and incident-handling records. When such information can be continuously stored and organized, and then recalled during specific tasks, it becomes memory that the Agent can leverage.
Therefore, as AI begins to work continuously, memory is evolving from an auxiliary feature into a problem that needs to be addressed independently.
For one-off Q&A interactions, memory is not that important. The user asks a question, the model provides an answer, and the interaction ends. For an Agent, however, things are completely different. It may need to execute dozens of steps in succession, call databases, search engines, code repositories, and business systems, and continuously adjust its subsequent actions based on the results returned at each step. Some tasks may last for several minutes, while others may span several days or even need to be continued in the next session.
Once the task chain becomes longer, forgetting is no longer just an occasional wrong answer. For example, an Agent may fail to remember a preference that the user has explicitly stated; it may not know where the previous task stopped; it may repeatedly try approaches that have already been proven ineffective; and it may be unable to apply the experience gained from successfully troubleshooting one issue to a subsequent task.
One of the most straightforward approaches is to feed the entire conversation history back to the model, or attach a task summary to the prompt. But as an Agent works for longer periods, historical information becomes increasingly complicated. Which content is worth retaining, which is merely part of a temporary process, and which conclusions are already outdated soon cease to be simple prompt-engineering questions.
Whether an Agent can truly participate in ongoing work depends largely on whether it can gradually accumulate an understanding of the user, the business, and the task. If the process, results, and feedback from every execution disappear when the session ends, then what the Agent completes remains a series of isolated tasks, with no ability to accumulate experience from previous work. This is precisely why Agent Memory has begun to attract attention.
As large language model capabilities continue to improve, context windows are also growing rapidly. In the past, 128K was already considered a long context; today, mainstream models can process inputs at the million-token level. Several books or thousands of pages of materials can theoretically be provided to a model at once. This naturally raises a question: If models can already read a huge amount of content in a single pass, why do we still need dedicated memory systems?
We can think of context as a desk. The documents, conversations, and task instructions that the model currently needs can all be placed on this desk. But no matter how large the desk becomes, it is still just a desk. As the amount of content grows, old information needs to be trimmed, compressed, or replaced. Even when the context window is large enough, putting all historical content into it unchanged still introduces costs, latency, and information noise.
Memory, by contrast, is more like a well-organized archive system. As materials continue to accumulate, we still need to determine which content should remain at hand, which can be put away, and which has become obsolete. When work begins again, we also need to retrieve the truly relevant information from a large volume of historical records. This is the kind of work a memory system is responsible for: deciding what to retain, how to organize it, when to retrieve it, and when to update or delete it.
When it comes to finding relevant information from a large volume of historical data, it is easy to think of RAG. But RAG primarily addresses external knowledge retrieval, which is still different from Agent Memory. RAG is better suited to finding information needed for the current question from product manuals, knowledge bases, and business documents. For example, when a user asks about refund policies, the system can retrieve the corresponding policy documentation. Agent Memory also needs to handle information generated during operation: user preferences, tool call results, task progress, historical decisions, and execution feedback. A knowledge base tells an Agent "how things are generally supposed to be done," while memory also needs to tell it "how this user has asked for things to be done before," "what has already been done in this environment," and so on.
Over the past two years, projects focused on long-term memory for Agents have begun to emerge. Their implementation approaches vary, but all are attempting to enable Agents to go beyond a single session and retain and leverage past information and experiences. The emergence of these projects indicates that memory is gradually evolving from an optional module within an Agent framework into a foundational capability that needs to be designed and managed independently. Cognee is one representative open-source project in this area.
In short, Cognee is a memory infrastructure designed for AI applications and Agents. It organizes documents, business data, and information generated during Agent execution into memories that can subsequently be retrieved and used, and provides the model with context relevant to the current task during each model invocation. The two most important keywords here are organization and utilization.
Enterprises have already accumulated large amounts of product documentation, customer records, meeting minutes, incident cases, operation logs, and project decisions. At the same time, Agents continuously generate user preferences, tool call results, execution states, successful experiences, and reasons for failure while performing tasks. If all of this content is simply stored as-is, it remains nothing more than ever-growing data. Which information is worth retaining, what relationships exist between different pieces of information, when they should be retrieved, and how they should be updated when information changes are the problems Cognee focuses on. It aims to bring existing enterprise knowledge and new experiences generated during Agent operation into the same memory system, enabling Agents to not only find answers from existing materials but also leverage past interactions and execution results in subsequent tasks.
Cognee's core operations can be summarized as remember, recall, improve, and forget. Take a database operations and maintenance scenario as an example. Suppose an Agent is assisting with maintaining a production database. During daily operations, remember can be used to store product manuals, cluster information, historical tickets, operation records, and environment characteristics confirmed by the user.
Suppose that one day, the production database experiences another memory-related issue. The Agent can then use recall to retrieve memories relevant to the current problem: Has this cluster experienced a similar failure before? What troubleshooting steps were taken at the time? Which approaches were ineffective? And how was the issue ultimately resolved? Compared with simply querying a product manual, these real-world experiences from the specific environment are often more relevant to the current problem.
After the issue is resolved, improve can be used to further organize and refine existing memories, incorporating valuable Session information into long-term memory. Confirmed root causes, effective troubleshooting methods, and final resolutions can then be reused in subsequent tasks.
If it is later discovered that a particular judgment was incorrect, the cluster architecture has changed, or certain information should no longer be retained, forget can be used to delete the corresponding memory, preventing outdated or incorrect information from continuing to influence subsequent decisions.
These four operations together represent the complete lifecycle of a memory: remembering information during work, retrieving history when needed, improving experience based on results, and forgetting information once it becomes obsolete.
Product manuals can tell an Agent what a particular parameter means, monitoring systems can reflect the anomalies currently occurring, while historical tickets and operation records preserve real-world experience from a specific environment. What Cognee aims to do is ensure that this information does not disappear when a task ends, but instead becomes memory that can continue to be leveraged by subsequent tasks.
For Agent Memory, storing information is only the first step.
If every line of conversation, every tool response, and every intermediate process is retained permanently, memory will quickly become filled with duplicate, conflicting, and outdated information. As the retrieval scope continues to expand, genuinely valuable content can instead become buried in noise.
Memory itself is not necessarily reliable. It may come from documentation that is already obsolete, may simply reflect a user's temporary expression in a specific context, or may contain the model's incorrect interpretation of the original information. If such content is not filtered and updated, it may continue to influence an Agent's decisions in subsequent tasks.
Therefore, a truly usable memory system needs to handle information filtering, updating, and forgetting. It also needs to clearly identify where each memory comes from, whom it belongs to, and who has permission to access it. At this point, Agent Memory is no longer merely about context management. How data is organized, how it is retrieved, how long it is retained, and who can access it will all affect whether it can truly be integrated into business systems.
If the model determines what problems an Agent can handle, and tools determine which systems it can connect to and operate, then memory determines whether past work can create value for the next task.
Cognee is an open-source project worth following in this direction. It attempts to provide a layer of capability beyond the model for continuously forming, recalling, and managing memories, so that an Agent does not have to start over after every session ends.
Once documents, conversations, and execution experiences enter Cognee, how exactly are they organized into memories? How do semantic retrieval, knowledge relationships, Sessions, and different types of storage work together? In the next article, we will further break down Cognee's internal operating mechanisms.
AI Era Database Infrastructure: Exploring Vectorized Execution in PostgreSQL
In the AI Era, Parallel Query Is Evolving from “Faster Scanning” to “Faster Computing”
Cost Reduction of RMB 30 Million! YMatrix Helps Customer Save 100 Servers
Dahshenlin: Achieving Real-Time Finance-Operations Integration with a Modernized Data Foundation
From TCP/UDP to Tunnel: How YMatrix Breaks the Communication Bottleneck in Large-Scale MPP Clusters
