Memory and Context Management for Research Agents

Human memory did not evolve to hold everything simultaneously. It evolved to compress, abstract, and selectively forget, because the cognitive load of maintaining an unbounded working memory would be prohibitive. That layered structure, distinct systems handling different timescales and different types of information, is not a limitation of biological hardware. It is an engineering solution to the same resource problem research agents now face.

The cognitive science lineage here is specific, and it matters that it is specific. Alan Baddeley and Graham Hitch's 1974 working memory model established that active reasoning operates through a limited-capacity buffer, not through some undifferentiated pool of knowledge. Endel Tulving's 1972 distinction between episodic and semantic memory separated the record of personal experience from general world knowledge, recognizing that remembering what happened last Tuesday and knowing that Paris is the capital of France are handled by different systems for good functional reasons. Larry Squire's 1987 work added procedural memory, knowledge encoded in habits and skills that operates below conscious recall. Three researchers, across three decades, converging on the same basic insight: memory is not monolithic, and treating it as monolithic is a mistake.

Princeton researchers formalized this lineage into agent architecture through the CoALA framework (arXiv:2309.02427, 2023), which remains the canonical taxonomy the field works from. The framework did something more important than borrow terminology: it treated the cognitive analogy as architectural prescription. Different memory types require different storage backends and different retrieval strategies, not because human cognition is a perfect model for AI systems, but because the functional demands that drove the evolution of distinct human memory systems are the same functional demands research agents face. A unified store attempting to serve all of them is the computational equivalent of expecting working memory to handle long-term autobiographical recall.

That is not a tuning problem. It is a design problem. The field took longer than it should have to recognize the distinction.

The Four Core Memory Types Every Research Agent Needs, and What Each One Actually Stores

Working Memory

Working memory is the live context window: what the agent is actively reasoning over right now. Fast, finite, ephemeral. It handles multi-step planning and tool orchestration happening in the current session and was never designed to persist anything beyond that. Treating it as a substitute for persistent memory is the category error that produces agents unable to function across sessions, a failure that also undermines retrieval-augmented generation pipelines built on top of them. It remains, frustratingly, among the most common errors in production deployments, often because memory architecture feels like a later problem when a team is moving fast. The problem never actually becomes a later one; it becomes an urgent one.

Episodic Memory

Episodic memory is the agent's record of specific past interactions, bound to time and context. What did the user ask last week? What did a tool return during a failed run three sessions ago? What source did the agent already consult and reject? Without this layer, what looks like reflection is actually simulation: the agent producing plausible-sounding continuity rather than drawing on what actually happened.

Implementation typically means turn-by-turn interaction logs, periodically compressed into summaries and stored in a dedicated summarization store. Compression triggers can be token-limit thresholds, importance heuristics, a fixed schedule, or an agent-invocable tool that decides when to consolidate. What matters is that compression happens systematically rather than being deferred until the context overflows.

Semantic Memory

Semantic memory is the stable world model the agent reasons against: factual knowledge, conceptual understanding, relationships between entities. It changes slowly relative to episodic memory and is not tied to specific events. An agent's knowledge that a particular API requires OAuth authentication is semantic; the record of the specific session when that authentication failed is episodic, and a knowledge graph is the natural structure for representing the former. Conflating them produces systems that cannot distinguish between what is known and what happened. That failure is subtler than it sounds and harder to debug once it compounds across a long workflow.

Knowledge graphs and relational databases are the natural implementation here because semantic memory is fundamentally relational. Entities have properties and relationships, and queries often require traversing those relationships rather than retrieving semantically similar documents.

Procedural Memory

Procedural memory encodes how to act, not what to know. Successful task strategies, preferred tool-use patterns, formats that have worked for particular query types: these are behavioral rules that allow an agent to improve over time rather than re-deriving the same approaches each session. This memory type is also the one most directly connected to autonomous improvement. An agent with robust procedural memory can update its own working strategies based on experience rather than waiting for a human to notice the pattern and intervene. That matters more in long-horizon research workflows than most initial designs account for.

The Emerging Extended Taxonomy

A June 2026 technical guide published by MarkTechPost identifies at least seven memory types, extending the core four to include retrieval memory, parametric memory, and prospective memory. Prospective memory tends to be the most underappreciated in production designs: the held intention to follow up on a stalled source, to revisit a claim when new data arrives, to send the Friday summary. This forward-looking persistence is what distinguishes an agent capable of week-long research workflows from one that resets at each session boundary. Most teams building research agents today are not explicitly designing for it. The absence is obvious when it manifests.

Why the Same Retrieval Strategy Cannot Serve All Four Memory Types

The most common architectural mistake in production agent systems is treating all memory as a single retrieval problem and defaulting to vector search for everything. The reasons are understandable. Vector databases, including purpose-built stores like Pinecone and Weaviate, are fast, well-documented, and the tooling around them is mature. Per Pinecone's published benchmarks, the full retrieval-augmented generation pipeline, including embedding, reranking, and LLM invocation, runs in the range of 200 to 500 milliseconds. That speed is genuinely useful. The appeal of one coherent system is real.

Vector retrieval breaks down on relational and multi-hop queries. A question like "who manages the person who approved the API deployment?" requires traversing a relationship chain, the kind of multi-hop query that has no natural representation in embedding space. A vector store returns documents semantically similar to the query; semantic similarity does not guarantee correct relationship traversal. The failures here are often silent: the system returns something plausible rather than something correct. That is the harder failure mode precisely because it takes longer to find. Multi-step reasoning, entity tracking across time, and provenance queries all stress vector retrieval beyond what it was designed to handle, and the plausibility of the wrong answers tends to mask the problem.

Graph-based retrieval addresses this gap. Comparative benchmarks from 2024 showed recall and precision figures for graph-based methods meaningfully above those for standard RAG approaches on multi-hop queries, which is why graph retrieval emerged as a distinct architecture track in 2024 and 2025, not as a replacement for vector methods but as a necessary complement for the query types vector methods cannot handle correctly.

Weaviate's 2025 context engineering framework makes the retrieval differentiation explicit, distinguishing three layers with distinct primary signals: historical interactions require temporal proximity as the dominant retrieval signal; domain knowledge requires semantic relevance; current working state requires freshness. Applying a single strategy across all three is not merely a performance trade-off. An agent retrieving episodic history by semantic similarity may surface the most thematically relevant past session rather than the most recent one. That is the wrong answer when the question is what actually happened, and it will look like correct behavior until the workflow is long enough to expose the discrepancy.

Context Engineering as the Discipline of Deciding What Information an Agent Sees and When

Prompt engineering asked what words produce the best output. Context engineering asks a different question: what configuration of context is most likely to produce the desired behavior across ongoing, multi-session interactions? The shift is not semantic. It reflects a real change in the nature of the problem as agents moved from session-bounded chat to persistent, tool-using workflows.

The term gained institutional traction in June 2025, when Shopify CEO Tobi Lütke and former OpenAI researcher Andrej Karpathy both endorsed the framing publicly. Gartner followed, advising AI leaders to build context-aware architectures with dynamic data assembly rather than static prompts. A 2026 survey found the large majority of IT and data leaders agreeing that prompt engineering alone is no longer sufficient for production AI, with nearly all data teams planning investment in context engineering capability.

LangChain's Lance Martin formalized the discipline into four strategies: write, authoring instructions for what the agent should do; select, choosing the relevant subset from available context; compress, reducing token waste without losing signal; and isolate, keeping unrelated context separate to avoid cross-contamination. These are distinct engineering concerns, and each interacts with memory design differently. Martin's framing is useful precisely because it treats all four as equal-weighted concerns rather than implying that selection or compression is somehow preliminary to the real work. In practice, compress and isolate are where most teams underinvest.

Model Context Protocol (MCP) functions as infrastructure for the select strategy. By late 2025, more than 10,000 public MCP servers had been deployed. MCP externalizes context sources so agents pull what they need rather than receiving everything pre-loaded, which makes selective context assembly tractable at scale.

The deeper point is that context engineering treats agent memory as one input variable in a broader context assembly function, and memory retrieval and context assembly are co-designed decisions, not sequential ones. For a research agent coordinating sources across a multi-day workflow, the question of what to retrieve and the question of how to assemble what is retrieved into a coherent reasoning context are not separate engineering problems. They compound each other. Solving one without the other produces a system that is half-optimized in ways that stay invisible until the workflow runs long enough to expose them, which is usually the worst possible moment.

What the Leading Memory Frameworks Actually Do Differently from Each Other

Production deployments almost always separate the memory platform from the storage layer. No single tool currently handles both extraction and retrieval at scale without trade-offs that matter in practice. The differences between frameworks are consequential enough that a misaligned choice tends to surface as a correctness problem rather than a performance problem, which is why it often goes undiagnosed longer than it should.

Mem0

Mem0 uses a three-tier scope model spanning user, session, and agent levels, backed by a hybrid store combining vector embeddings, graph relationships, and key-value lookups. Its defining behavioral feature is conflict resolution: when new facts contradict stored ones, Mem0 self-edits rather than appending. The memory store stays lean over time rather than accumulating contradictions that silently distort later reasoning.

An ECAI 2025 paper (arXiv:2504.19413) benchmarked Mem0 on LOCOMO and reported a 67.13% LLM-as-a-Judge score, p95 search latency of 0.200 seconds, and roughly 1,764 tokens per conversation compared to approximately 26,031 for a full-context baseline. Token reduction exceeding 90% for the same task is not a theoretical economy; at the cost profile of enterprise inference, it is a budget line. An April 2026 algorithm update introduced single-pass hierarchical extraction and multi-signal retrieval, with the largest reported gains on temporal queries and multi-hop reasoning. The State of AI Agent Memory 2026 report cited more than 100,000 developers using Mem0 by late 2025.

Zep and Graphiti

Zep, with Graphiti as its open-source component, treats time as a first-class property of the knowledge graph. Facts carry temporal metadata, so temporal reasoning about who held a budget role in February versus who holds it now is a native operation rather than a string-similarity approximation. For research workflows where facts change over time and the history of those changes is itself informative, this is a meaningful architectural advantage.

On the LongMemEval benchmark using GPT-4o, Zep scored meaningfully higher than Mem0 on temporally complex queries. Mem0's benchmark paper prompted a rebuttal from the Zep team claiming their system had been misconfigured in the evaluation and that a corrected score would be substantially higher. The dispute has not been definitively resolved. It is worth sitting with that for a moment: two serious teams cannot agree on what a controlled evaluation showed. Benchmark conditions matter as much as benchmark numbers, and anyone selecting a memory framework based primarily on published scores should read the methodology as carefully as the headline figures, because the headline figures are often the least informative part.

Letta

Letta, formerly MemGPT, takes a philosophically different approach. Its architecture is OS-inspired: main context functions as RAM, archival memory functions as disk, and the agent itself manages memory allocation, deciding what to retain and what to move to slower storage. Memory management is not abstracted away from the agent; it is part of the agent's reasoning loop. This is a specific thesis worth taking seriously: that LLM-managed tiered memory is more robust than externally managed tiered memory. It also introduces complexity that external management approaches deliberately avoid. Whether that complexity is justified is genuinely task-dependent, and the answer probably differs more between teams than between task types.

LangMem

LangMem, part of LangChain's ecosystem, supports episodic, semantic, and procedural memory types through the LangMem SDK and LangGraph's persistent store layer. Its distinguishing feature is procedural memory implementation: agents can update their own system instructions within the reasoning loop. Behavioral improvement is not post-hoc fine-tuning; it is in-session adaptation based on experience. For teams already embedded in the LangChain ecosystem, this integration is practically significant rather than abstractly interesting. For teams that are not, the switching cost of adopting it is real.

Cognee

Cognee builds knowledge graphs directly from raw unstructured data as the primary storage mechanism rather than layering graph structure on top of a vector store. For document-heavy research workflows where entity relationships matter as much as raw semantic similarity, this architecture avoids the representational loss that occurs when relational structure is approximated through embedding similarity. For provenance-heavy research tasks, that loss is often not negligible, even when it is invisible in early testing.

Benchmarks Worth Tracking

Three benchmarks currently define comparative evaluation in this space. LoCoMo covers more than 1,500 questions spanning single-hop, multi-hop, open-domain, and temporal recall. LongMemEval covers 500 questions including knowledge updates and multi-session recall. BEAM operates at one-million and ten-million token scale, the regime most relevant to production research agents. None of them is definitive, and reading them in the abstract is less useful than mapping them against the specific query distributions that actually matter for a given deployment.

Practical Techniques for Managing Context Across Long-Horizon Research Workflows

Techniques for managing context across extended workflows divide into two categories: intrinsic approaches built into the model's reasoning loop, and external memory mechanisms the agent queries as separate systems. Both are necessary. The tendency to pick one and call it done is where many production systems quietly fail, usually not catastrophically, just incrementally, in ways that accumulate across sessions until the workflow is unreliable for reasons no one can precisely locate.

Intrinsic Optimization

Some models, including DeepSeek-V3.2 and GLM-4.7, integrate context pruning and observation space compression directly into inference, reducing redundant trajectory history without external system dependencies. The trade-off is real: intrinsic compression limits memory to what fits in the compressed context. It reduces bloat efficiently but does not solve the persistence problem across sessions. A useful floor; not a ceiling, and not a substitute for explicit long-term memory architecture.

Summarization as Compression

Periodic summarization of ongoing interactions into concise representations stored in a dedicated summarization store is the most broadly applicable compression strategy available. The Mem0 token comparison makes the stakes concrete: the same research task completed with summarization and selective retrieval consumed a small fraction of the tokens required by a full-context approach. At enterprise inference cost, that difference is a budget line.

Trigger conditions for summarization can be token-limit thresholds, importance heuristics, time-based schedules, or an agent-invocable tool. Time-based schedules suit predictable research cycles; importance heuristics suit workflows where information density is variable and not all content warrants compression at the same threshold. The choice requires a considered opinion about the workflow rather than a default, and revisiting that opinion as the workflow matures tends to pay for the time it costs.

Tiered Retrieval

Flat retrieval applied uniformly across all memory types produces the correctness failures described earlier. Tiered retrieval assigns different primary signals to different memory layers: temporal proximity for episodic history, semantic relevance for factual knowledge, freshness for current working state. The implementation overhead is real. The alternative is an agent that consistently retrieves the wrong kind of right answer, which tends to be harder to diagnose than an agent that retrieves nothing at all.

For multi-hop queries, graph-based retrieval should layer on top of vector retrieval rather than replace it. Vectors handle semantic lookup efficiently; graphs handle relationship traversal correctly. A production research agent tracking provenance, identifying conflicting sources, and following entity relationships across a large document corpus needs both. The decision to use only one is usually made early in a project, under time pressure, and reconsidered at the worst possible moment, after a long workflow has been returning plausible wrong answers long enough that fixing the architecture means re-running substantial work.

Prospective Memory as a Design Primitive

Long-horizon research workflows involve deferred intentions. Follow up on this source when new data arrives. Revisit this claim after the dataset is updated. Send the summary on Friday. These are not retrieval problems in the conventional sense; they are scheduling and intention-tracking problems, and they require prospective memory as an explicit design component. An agent without it can retrieve the past reliably and still fail to complete a week-long research task because it has no mechanism for maintaining forward-looking commitments. When that happens, it looks exactly like the agent forgot. Because it did.

Where Production Failures Actually Live

The production reliability of research agents appears to be less a function of model capability than of memory architecture. The models have improved dramatically; the architectures surrounding them have often not kept pace. What I have seen repeatedly is that teams diagnose failures at the model level, iterate on prompts, and continue missing the underlying architectural gap, because model-level failures are visible and architecture-level failures masquerade as something else.

Whether memory architecture becomes a lasting differentiator between teams or eventually gets abstracted away by better tooling is genuinely unclear to me. What does seem clear, from watching systems succeed and fail at scale, is that treating memory architecture as a first-class design decision rather than a configuration detail changes what gets built, and changes it early enough to matter. The teams that have internalized that are building different systems. Not necessarily more complex ones; more deliberate ones.