Memory Strategies and the Entropy-Reduction Philosophy of Context Engineering

Open-source project: TencentDB Agent Memory

Author: Tencent Cloud Database Team (腾讯云数据库团队)

Why does talking to AI so often feel like hard work?

With an old friend, a glance can be enough. With an AI assistant, the same request may require several paragraphs of explanation.

One useful way to understand this difference is through entropy: uncertainty about what a message means. A friend shares memories with you and can fill in what you leave unsaid. An AI assistant without that context faces many possible interpretations of even a simple phrase.

Context engineering helps bridge that gap. Instead of merely storing conversations, a layered memory system captures the situational information that would otherwise be lost. Drawing on Tencent Cloud's Memory engineering experience, this article explores how to reduce uncertainty before a model acts, moving from repeated clarification toward more precise execution.

1. Entropy reduction in context engineering: from formulas to intuition

1.1 A simple example: “Ask Li to meet us at the usual place”

Imagine that you are busy at work and say to a longtime colleague, without looking up: “Ask Li to come along. We'll meet at the usual place when it's time.”

Your colleague nods and gets on with it. You have not spelled out the details, but your shared history supplies them.

An AI assistant receiving the same request may have to ask several questions, or may make unsupported guesses:

• Who is Li: the manager in your contacts, someone in the next department, or the intern who joined this week?
• When is “when it's time”: nine tonight, ten tonight, or tomorrow morning?
• Where is “the usual place”: a restaurant, a park, or the office lounge?

These are different levels of uncertainty. More plausible interpretations mean higher entropy; a clear, well-grounded interpretation means lower entropy.

In a familiar human relationship, shared memories, the current situation, and established habits resolve references such as “that thing” or “Wang.” Without those signals, the same instruction can represent thousands of combinations.

Context engineering acts as a translation layer: it turns the implicit, ambiguous expressions people naturally use into context a machine can work with.

1.2 Improve the input before changing the model

At a simplified mathematical level, a language-model application can be represented as:

y = f(x)

• f is the trained model, with its parameters already set.
• x is everything supplied to it: context in the broad sense.
• y is the model's response.

For many applications, changing f frequently would be costly and risky. Much of the practical engineering work therefore goes into improving x:

• The user's current question or instruction.
• A system prompt defining the model's role and task.
• Cross-session memory of what happened before.
• Available tools and instructions for calling them.
• Retrieved passages from external knowledge bases through RAG.

Selecting, ordering, filtering, and compressing these inputs is context engineering.

The paper Context Engineering 2.0: The Context of Context Engineering frames it as a systematic process for collecting, storing, managing, and using context to bridge the cognitive gap between people and machines.

Can the model understand what you mean when you speak casually? Can it identify the important evidence when a business system supplies a pile of logs? These questions concern how we prepare context as well as the model's capabilities.

1.3 Reduce uncertainty in three steps

The entropy-reduction perspective treats context engineering as a process of making information less ambiguous. Here, entropy refers to informational uncertainty, rather than a literal thermodynamic calculation.

People communicate through emotions, hints, omissions, assumed knowledge, and pauses. We leave many things unsaid because we expect the listener to fill them in. A machine receiving a token sequence cannot reliably reconstruct all of that missing context. Supplying an unfiltered stream of real-world information can leave it with too much noise and too little structure.

The process can be divided into three steps:

• Collect: capture relevant signals from people and their environment without losing critical clues.
• Organize and abstract: structure and compress the information, filtering out noise.
• Use: select the small subset that matters to the current task and supply it to the model.

The earlier formula then becomes:

y = f(g(context))

Here, f is the language model, while g represents context-engineering strategies: knowledge retrieval, tool use, and the memory storage and retrieval methods discussed in this article.

1.4 A formal view of context

The paper describes a world of entities: users, applications, tools, environments, memory modules, and other objects. Each entity e has characterization information, written as Char(e): who a user is, what time it is, or how an application is configured.

For a particular interaction, select the relevant entity set E_rel and combine their characterization information:

C = ⋃ { Char(e) | e ∈ E_rel }

In plain language, the context for a task combines its relevant entities with information describing their current state. Memory supplies a portion of that characterization that is particularly easy to lose and difficult to maintain over time.

1.5 Memory reduces uncertainty about people and time

Context also includes system instructions, tool results, and knowledge-base documents. Memory has a more specific role.

A knowledge base helps a model understand the world. Memory helps it understand a particular person and a particular ongoing task.

Its job is to turn large numbers of fragments about a person, a relationship, or a task into a small amount of ordered, reusable context. Without that history, each conversation starts with substantial uncertainty. With it, the assistant has a basis for interpreting what a short reply such as “Okay” refers to.

2. Memory as intent recognition and selective information supplementation

A powerful language model with no useful persistence can resemble an exceptionally capable colleague who keeps forgetting the conversation. Giving it a notebook helps, but a memory system needs to do more than save a few chat messages.

2.1 From a passive archive to an active context layer

Memory is often imagined as a warehouse: put the user's words in, then look them up later. In a context-engineering pipeline, it is a dynamic layer centered on people and long-running tasks.

It serves two purposes.

Reduce uncertainty about intent. Consider the shopkeeper downstairs who knows a regular customer's usual purchase. Without that history, the customer has to describe the exact product and accessories every time. With it, a nod may be enough. Memory maps an ambiguous signal to an intent grounded in prior interactions.

Supply missing background selectively. When discussing a code change, memory should not insert all 100,000 lines of a project into the prompt. That would contaminate the context. It might instead provide one timely reminder: “This module previously used OAuth 2.0 for authentication; preserve that behavior.”

Restraint matters. Supply the high-value background missing from the current decision; irrelevant additions are noise.

2.2 Five kinds of demand for memory

Requests for memory features can seem scattered. Look more closely, and they reveal five recurring needs.

Keep roles and instructions stable. An agent may lose its assigned persona or forget an initial constraint such as “Respond only in JSON” after many turns. Users want stable role definitions and critical constraints to persist, instead of repeatedly resetting the assistant's identity.

Build personalization and user profiles. In education, an AI tutor should recognize that a student has made the same sign error three times, rather than treating each wrong answer in isolation. In customer service, an assistant might remember a previous purchase and recognize when a replenishment could be useful. Such personalization must be explainable: understanding a user should not feel like intrusive surveillance.

Maintain continuity in long-running tasks. A coding session lasting several hours, or a complex support case, should not feel like starting over each time a new agent or representative takes over. Memory acts as a relay baton, carrying task state through collection, compression, and reuse.

Turn interactions into reusable assets. Enterprise customers see value in conversations, file changes, and other interactions. Recommendation systems extract patterns from structured clickstreams; memory systems must also work with unstructured text. They can use existing information to serve the user while extracting new profile information from the service process, creating a feedback loop.

Remember relationships as well as facts. Remembering “Your name is Bob” is different from remembering that Bob has recently been under pressure at work and may need encouragement. Relationship continuity depends on accumulated understanding of attitudes, emotions, and concerns, rather than isolated factual labels alone.

2.3 Memory's role in the pipeline

Memory reduces uncertainty on the human side of context engineering. It compresses fragments about a person, a relationship, and a task into structured context that can be reused, preparing the model to understand the user before it begins answering.

3. What Claude's chat and coding experiences suggest about memory

Some users find Claude particularly effective with complex context. Alongside the model's reasoning abilities, context-engineering choices provide a useful lens for examining that experience. Chat and coding applications emphasize different forms of memory.

3.1 Chat: continuity around people and conversations

Anthropic's chat search and memory documentation describes memory of professional context, ongoing work, communication preferences, and technical preferences. Project memory can keep one project's context separate from other projects and standalone conversations. Users can manage memory and use incognito chats that do not contribute to it.

Viewed through entropy reduction, conversational memory addresses three questions:

• Who is speaking, and in what role: student, product manager, developer, or customer?
• Which ongoing project or topic are we discussing, and what has already been agreed?
• What style should this answer follow: explanatory prose, a formal proposal, a list, or code?

Project context, summaries, and editable memory provide continuity. Returning after several days to ask “Where did we leave off?” or “Continue in the same style” should not require rebuilding the entire background.

In this setting, memory primarily reduces uncertainty about people and ongoing narrative threads.

3.2 Coding: continuity around repositories and tasks

In Claude Code, the emphasis shifts toward the repository and the work underway.

Persistent instruction files such as CLAUDE.md describe project conventions, structure, boundaries, and quality expectations. Auto memory can retain useful lessons about commands, preferences, and workflows. These serve as project and working-environment context rather than a comprehensive personal profile. See Claude Code's memory documentation.

Coding memory addresses three kinds of uncertainty:

• Repository structure and boundaries: important modules, dependencies, and generated directories that should not be edited.
• Task progress: completed refactoring or debugging steps, rejected approaches, and current hypotheses.
• Constraints: architectural rules, testing requirements, and security or compliance boundaries.

Context isolation also matters. Subagents can work in separate context windows with scoped tools and tasks, returning useful results to the main conversation. This reduces the burden of keeping every tool result and subtask detail in one large context.

3.3 The design lesson

Memory is a scenario-specific design problem:

• Chatbots need intent memory, maintaining identity and conversational continuity.
• Coding agents need state memory, maintaining task progress and handling system complexity.

The guiding question is which uncertainty causes the most damage in the current scenario. Is the assistant forgetting who the user is, or misunderstanding code dependencies? Recognizing that difference is more useful than simply increasing the amount stored.

4. “Attention before Attention”: storage and retrieval challenges

Building Tencent Cloud's Memory product has exposed many practical limits to the theoretical picture. Memory engineering involves allocating attention under constraints on compute and latency.

Self-attention determines what the model focuses on within its input. A memory system must first decide which information enters that input at all. This is “Attention before Attention”: a good selection helps the model, while a poor one can make memory itself the largest source of noise.

4.1 Storage: preserve details without losing structure

Personalization creates an incentive to capture user history. But merely storing more information, without a schema, increases uncertainty rather than producing usable memory.

Three failure modes are especially important.

Over-sparsity. A system records every conversational turn as an Event but loses the higher-level task structure. Retrieval then searches thousands of loosely related fragments. Without a coherent context chain, the model cannot reconstruct what happened. Storage needs a schema that retains relationships and task structure.

Over-abstraction. To save tokens and storage, a system compresses a hundred turns into a short conclusion. Intermediate evidence disappears. In coding or teaching, “The user tried this approach and it failed” may matter more than the final outcome. Losing that information causes the assistant to recommend failed approaches again. Summaries should retain the intermediate state needed to continue the task.

Isolated memories. An Event has no Scene ID or Task ID anchoring it to a situation. Retrieval may then bring a coding preference into a cooking conversation, or otherwise mix unrelated contexts. Group fragments into blocks with explicit situational boundaries. Isolation is fundamental to retrieval accuracy.

4.2 Retrieval: relevance, latency, and generalization

Retrieval is where many of the strongest business concerns appear. Practical systems face competing demands for quality, speed, and generalization.

Avoid context contamination. Enterprise users often prefer retrieving less information to retrieving something misleading. Bringing an obsolete price into a new quotation, for example, increases uncertainty and can corrupt the answer. Relevance alone is insufficient; memories must also be unambiguous in their applicability.

Avoid the vector-similarity trap. A strategy overly dependent on similarity to the current query can miss its deeper references. “That old problem again” may refer to a database deadlock discussed last Tuesday. Surface-level similarity does not resolve that reference. Memory needs situational reasoning and, for some questions, multi-hop retrieval.

Handle multi-hop retrieval within a latency budget. Valuable memories can be connected indirectly. Candidate retrieval, reranking, and a small agentic search process all add work. The engineering discussion here uses a 500 ms budget for the responsive retrieval path; fitting these operations into it is an architectural challenge. Deeper agentic searches may take longer.

Return information the model can use. Retrieval should not insert unexplained fragments from an old conversation. Results need concise wording, clear context, and enough background to explain why they matter now.

The goal is to select the few memories that reduce uncertainty in the current decision, within the available time.

4.3 What “Attention before Attention” means

Think of the model's attention as deciding whom to listen to in a room. Memory's attention decides who enters the room.

The source article illustrates the cost of attention using the quadratic O(N²) relationship of standard dense self-attention. A memory system works earlier in the pipeline, screening input before it reaches the model's finite context window.

Its job is to admit useful signals and keep out noise. The 500 ms figure is an engineering budget discussed in this design, rather than a universal latency guarantee for every retrieval operation.

5. Turning layered memory into an engineering architecture

Keeping complete information, retrieving precisely, reasoning deeply, and responding quickly create competing requirements. Adding a vector database alone does not resolve them.

The approach explored in Tencent Cloud's Memory engineering work uses information hierarchy: three storage layers and three retrieval paths, balancing preservation with efficient use.

5.1 Three storage layers: Event, Scene, and Record

The system progressively organizes information rather than simply dumping conversations into storage. Events retain details, MemoryBooks preserve task context, and Records capture dense, reusable information.

Event: the original evidence layer. This layer records who said or did what, and when, in chronological order. It avoids lossy compression of the original content and serves as the source of truth for higher layers. If a summary leaves out an important detail, the system can return to the original evidence.

Scene: the task and situation layer. Events are grouped by task or situation into MemoryBooks. A MemoryBook contains Scenes, such as “March 1, 2025 mathematics lesson: adding and subtracting fractions.” Each Scene links key source passages with intermediate conclusions.

Retrieval can then return both a statement and its situational background: which lesson it came from, or which project discussion established it. That structure helps prevent context from unrelated situations being mixed together.

Record: the long-term information layer. High-value information is extracted across MemoryBooks: user profiles, stable preferences, and important timeline events. Schemas can be customized for the business, such as learning progress in education or brand preferences in commerce.

This turns extensive interaction history into a compact, structured profile that supports intent interpretation at the start of a conversation.

The source architecture also depicts situation recognition, scenario-based extraction and merge policies, and multiple indexes: temporal, semantic, and graph-oriented. Retrieval has both a fast candidate-selection and ranking path and an agentic path that plans, searches, reflects, and constructs an answer.

5.2 Three retrieval paths: from recent context to deeper history

Current conversation: use recent Events. The most recent turns can be supplied directly to the context window. This preserves the immediate exchange and reduces the need to repeat requirements within a short conversation.

Task context: reactivate a MemoryBook. When a task spans turns or days, a Session ID or Task ID identifies its continuing context. The MemoryBook carries progress forward.

An important technique is asynchronous prefetching. Before the next question arrives, the system may use the current situation to load likely relevant material. Entering a student's final-exam review, for example, can trigger retrieval of earlier mistakes. Moving work out of the immediate request path helps meet a tight response budget.

Long-term records: combine a fast path with deeper agentic search. Vector and keyword retrieval can quickly select relevant Records, such as a preferred form of address or a dietary restriction.

More complex requests, such as “What was I doing on this day last year?” or “Summarize my coding style over the past month,” may need several retrieval and reasoning steps. A small internal agent can search iteratively and connect evidence. This path takes longer but addresses questions a single retrieval pass cannot resolve.

5.3 Observations from internal evaluation

The source article reports three outcomes from internal evaluation of this layered approach.

Temporal recall. On time-sensitive questions such as “What was I doing on this day last year?”, the reported accuracy was approximately 45% using the base Qwen3-coder model and 88% after adding layered Memory. These are results reported for that internal evaluation; the article does not supply a public benchmark protocol or sample size, so they should not be generalized into an accuracy guarantee.

Less repetition in long-running work. In coding and teaching scenarios, users needed to repeat requirements and constraints less often. Memory helped preserve the task's structure across sessions spanning multiple days.

More stable personas and continuity. Role drift and breaks between sessions were reduced. Memory acted as persistent support for an agent's assigned role instead of a collection of disconnected fragments.

These observations concern the design and evaluation described in the original article, not a benchmark claim for every deployment of the open-source project linked here.

6. From memory engineering to digital presence

Stepping back from implementation, context engineering raises broader questions about how people and machines share understanding.

6.1 Who will perform entropy reduction?

Context Engineering 2.0 sketches a possible shift in responsibility as machine intelligence develops.

Today, engineers build scaffolding around models: memory systems, knowledge bases, tools, prompts, and storage strategies that filter noise and supply context. In the paper's prospective CE 3.0 and CE 4.0 stages, more capable machines could increasingly perceive, infer, and construct context themselves.

Memory could then become an active part of attention: discovering useful connections in large amounts of history, including connections people have not explicitly identified. This is a proposed direction of development, rather than a feature available in all current systems.

6.2 Digital presence: a structured representation of a person

An ambitious vision for context engineering is “digital presence.” A well-designed memory system can represent aspects of a user's knowledge, habits, decision-making style, and emotional preferences, rather than merely retaining logs.

Such a representation gives an assistant a basis for understanding the user over time. Interactions can feel continuous instead of a series of disconnected computations. The value comes from being understood, rather than from storage alone.

6.3 A question beyond engineering

When designing memory hierarchies and reducing uncertainty for a machine, we are trying to make interactions smoother and more useful. At a longer time scale, we may also be constructing a computational form of self-narrative: a stable representation of “who I am.”

How do we make machines useful while preserving a person's freedom to change, remain open-ended, and resist being reduced to a fixed profile? That may become a central philosophical question for future context engineering.

7. Three questions to ask before building a memory system

7.1 Which uncertainty matters most?

Resources are finite. Identify the main business problem before trying to solve every form of uncertainty at once.

Intent uncertainty. The model struggles with user identity or implicit needs and repeatedly asks for clarification. Optimize for understanding who the user is, their preferences, and what the current message implies. Relevant scenarios include personal assistants, companionship applications, and personalized recommendation agents.

Knowledge uncertainty. Documents, logs, and databases contain extensive information, but retrieval returns noise or fails to locate the useful passage. Optimize for supplying the evidence the current task actually needs. Examples include enterprise search, document question answering, and support knowledge bases.

Process uncertainty. In a long task, the assistant forgets initial constraints or loses track of its progress. Optimize for stable task state and forward movement. Coding assistants, AI tutors, and complex ticket workflows are typical examples.

7.2 Does the architecture address the key engineering questions?

Hierarchy. Distinguish raw Events, task or Scene context, and long-term profiles. A flat store makes retrieval harder to organize; use layered storage and retrieval where the use case calls for it.

Namespaces and isolation. Keep users, projects, and business lines appropriately separated. Preventing cross-user and cross-project contamination is essential to both security and retrieval accuracy.

Storage versus use. Separate frequently needed context from infrequent detail. Core role definitions and critical constraints should be readily available; historical conversation detail belongs in a MemoryBook or another retrievable store until it is needed.

Monitoring and feedback. Capture and correct mistaken memories. When a user identifies an error, the system should use that signal to update the relevant information instead of allowing it to accumulate and be reused.

7.3 Can you explain the business value?

“We are adding vector storage” describes an implementation. “We are reducing uncertainty in this workflow” describes a user benefit:

• Teachers do not have to repeatedly reconstruct each student's learning history.
• Support representatives can take over a transferred case without rereading every earlier ticket.
• Users do not have to restate their identity and requirements every few turns.

Building the underlying system from scratch takes substantial work. Tencent Cloud's Memory product offers a practical reference for the layered approach discussed here: MemoryBooks maintain task continuity, long-term profiles accumulate preferences, and fast retrieval works alongside deeper agentic search.

The aim is to reduce repeated infrastructure work so teams can focus on the value of their applications. For the cloud product discussed in the original article, see the Tencent Cloud Memory documentation.

Open-source project: TencentDB Agent Memory

Source: Original Chinese article by the Tencent Cloud Database Team