Memory Layer vs Context Window: Key Differences Explained

Quick comparison: context window vs memory layer vs context layer

Dimension	Context Window	Memory Layer	Context Layer
What it is	Fixed token budget for one LLM inference call	External storage that persists info across agent sessions	Governed, structured metadata infrastructure serving all agents
How it works	Everything in the window is processed simultaneously; nothing outside it exists to the model	Retrieves relevant content via semantic search, injects into context window at query time	Reads live from governed data catalog: definitions, lineage, policies, entity relationships
What it stores	Nothing — ephemeral; wiped after each call	Conversation history, extracted facts, user preferences (unstructured)	Certified metric definitions, ontologies, data lineage, access policies (structured)
Best for	Immediate in-session reasoning with limited, curated inputs	Personal assistants, chatbots needing continuity across user sessions	Enterprise data agents reasoning over governed, cross-system business data
Lifespan	Single inference call	Persistent across sessions (until explicitly deleted or expired)	Persistent, continuously updated from live source of truth
Enterprise fit	Partial — useful but insufficient alone	Low — chatbot-native, no governance, no cross-system identity	High — built for governed, multi-system, multi-agent enterprise environments
Failure mode	Silent truncation; context rot; instruction competition	Stale memory; probabilistic recall; no governance or lineage	Depends on implementation quality of the underlying catalog

A context window vs. a memory layer: the key differences

A context window is temporal; it holds only what the model can process right now, in this inference call. A memory layer is spatial; it holds information outside the model and outside the call, across sessions. The context window is your agent’s working memory; the memory layer is its external hard drive. But neither one answers: what does this organisation’s data actually mean?

The core distinction

The “RAM vs. hard drive” analogy is where most explanations stop. It is accurate as far as it goes, but it misses the architectural asymmetry that matters in production.

The context window is processing infrastructure. Everything inside it is reasoned over simultaneously; there is no selective attention between items in the window (though attention degradation occurs at the ends of very long contexts). The memory layer is retrieval infrastructure. It holds information that the model never sees until a retrieval step explicitly fetches and injects it.

Put concretely: the context window asks “what can I reason with right now?” The memory layer asks “what did I learn before?” Neither asks “what does this organisation actually know and govern?” Those are three different questions, and they require three different architectural answers.

How memory layers emerged

Memory layers emerged as a direct response to LLM statelessness. Every inference call resets. The agent that helped a user in Monday’s session has no knowledge of that interaction on Wednesday; the session history exists only in the user’s browser, not in the model.

The industry’s response was to build external stores: systems that extract information from sessions, persist it, and inject relevant pieces into future context windows. This is the core pattern behind Mem0, Zep, LangChain Memory, and similar tools. The Letta Engineering Blog’s “RAG is not Agent Memory” captures the sharpest practitioner distinction: RAG is document retrieval (stateless, query-matched, injected into context), while memory is persistent, updatable, and user-scoped. They are architecturally different things, though both ultimately inject content into the context window.

Context window expansion followed a parallel track. The assumption was that a large enough window would eliminate the need for external memory; if you can fit everything in the context, you don’t need retrieval. This turned out to be wrong for reasons we will cover in detail below.

Why the confusion persists

The same vocabulary appears in architectures with very different meanings. “Context” refers both to the token window and to any contextual information an agent uses. “Memory” refers to both working memory (the window itself) and persistent external storage.

Anthropic’s four-type context taxonomy (working, session, long-term, tool) uses “context” for all four layers, technically precise but easily conflated by practitioners reading quickly.

Getting this distinction wrong has real costs. Teams that conflate context windows and memory layers over-invest in context window expansion, which is expensive, and it does not solve persistence. Teams that over-invest in memory layers discover they solve the chatbot continuity problem well, but they do not solve the enterprise data agent problem at all.

What is a context window?

A context window is the total token capacity available to a large language model during a single inference call. It holds the system prompt, conversation history, retrieved documents, tool outputs, and every other input the model processes simultaneously. Tokens outside the window are invisible to the model; they do not exist, regardless of their relevance or importance.

What it is and why it matters

The context window is not storage. It is the active processing space for one inference, the equivalent of RAM in a computer. Everything the model “knows” during a call must fit here. When the call ends, the context is gone.

Every component of a modern agent prompt competes for this space: system instructions, safety guardrails, few-shot examples, retrieved documents, tool definitions, tool outputs, and the actual user message. Adding a longer system prompt directly reduces the space available for user data. This is the instruction competition problem.

For more on how LLM context window limitations constrain agent design, including silent truncation patterns and cost implications, that page covers the failure modes in depth.

Current sizes, costs, and the effective capacity gap

Context windows have grown dramatically. As of Q1 2026: GPT-4o supports 128,000 tokens; GPT-4.1 reaches 1,000,000 tokens; Claude Sonnet 4 operates at 200,000 tokens (1M in enterprise beta); Gemini 2.5 Pro supports 1,000,000 tokens; Gemini 3 Pro and Llama 4 reach up to 10,000,000 tokens.

The growth is real. But IBM Research’s analysis of why larger context windows have limits identifies a critical constraint: transformer attention cost scales quadratically with token length. Doubling input length roughly quadruples compute cost. A 10M-token context window filled with unstructured content is not just expensive; it is economically impractical for high-volume production agents where cost and latency compound per call.

Real-world effective capacity runs at 60-70% of advertised limits. The reasons are structural, not incidental.

The “lost in the middle” problem and context failure modes

The most important finding about context windows and reasoning quality comes from Liu et al. (2024) in Transactions of the Association for Computational Linguistics, Vol. 12 (MIT Press). Their research documents what they call the “lost in the middle” phenomenon: models exhibit a U-shaped performance curve, performing best when relevant information appears at the beginning or end of the context. Information positioned in the middle of long contexts is significantly underweighted. GPT-3.5-Turbo showed more than 20% performance degradation in 20-30 document settings when relevant information was not at the extremes.

The arXiv preprint confirms the finding across model families. This is not a context window size problem; it is an attention architecture problem. A 10M-token window filled with 10M tokens of content does not process that content uniformly.

Anthropic’s engineering team has separately documented “context rot”, meaning recall accuracy degrading as token counts increase, representing a distinct failure mode from truncation. Context rot occurs well before the nominal token limit is reached, as attention becomes noisier with more input.

For the distinction between what belongs in-context vs. external memory for AI agents, that comparison covers the architectural tradeoffs in more detail.

Core failure modes of context windows

Context windows fail in five predictable ways:

Silent truncation: When inputs exceed the token limit, content is dropped without warning or acknowledgment — the model proceeds as if the information never existed.
Context rot: As token counts increase, recall accuracy degrades — Anthropic documents this as distinct from truncation, occurring well before the nominal limit is reached.
“Lost in the middle” degradation: Models exhibit primacy and recency bias — information positioned in the middle of long contexts is significantly more likely to be missed (Liu et al., 2024).
Instruction competition: System prompts, guardrails, few-shot examples, and user data all compete for the same token budget — adding safety instructions directly reduces space for user data.
Quadratic cost scaling: Doubling context length roughly quadruples inference compute — making large context windows expensive at production volume (IBM Research).

What is a memory layer?

A memory layer is external storage that persists agent information across sessions. It typically uses vector databases for semantic search, key-value stores for structured facts, or graph databases for relationship-aware retrieval. At query time, the memory layer retrieves relevant content and injects it into the context window, giving the agent knowledge of past interactions without requiring every prior interaction to be re-loaded each call.

What it is and the problem it solves

A memory layer sits outside the model and outside the context window. It is the persistence infrastructure that makes a stateless LLM appear stateful.

The memory layer for AI agents, as a category, exists because LLMs reset between calls. A user who interacted with a customer support agent on Monday is a stranger to that agent on Wednesday, unless there is a system that captured and stored the Monday conversation and retrieves it on Wednesday.

Memory layers bridge this gap: extract information from sessions, store it externally, and inject relevant pieces into the context window on future calls.

A key distinction practitioners often miss: RAG (retrieval-augmented generation) is not a memory layer. RAG retrieves documents from a static corpus and injects them into the context window; it is stateless, query-matched document retrieval. A memory layer is stateful; it retrieves personalised history specific to a user or agent session, and it updates as the agent learns more. Letta’s engineering team articulates this distinction clearly: RAG is retrieval, memory is persistence.

Standard taxonomy of memory types

The types of AI agent memory follow a taxonomy borrowed from cognitive science, widely used across practitioners (per Mem0’s “Memory in Agents: What, Why and How”):

Episodic memory: Past events and interactions — what happened in previous conversations.
Semantic memory: General facts and knowledge — structured information agents can retrieve.
Procedural memory: Skills and learned behaviors — how to perform recurring tasks.
Working memory: The context window itself — immediate, per-inference reasoning.

This taxonomy is useful. It describes the memory architecture of personal assistants well. The gap it does not address: enterprise data agents need a fifth category not covered here: governed organisational knowledge, certified metric definitions, data lineage, and access policies that apply consistently across all agents, not just one user’s conversation history.

What memory layers add and where they excel

Memory layers add genuine value over context-window-only architectures:

Persistence across sessions — no cold-start amnesia for conversation history.
Theoretically unlimited storage — the constraint shifts from token budget to retrieval quality.
User-scoped recall — Mem0’s differentiator over plain RAG: retrieval is personalised to a specific user, not just query-matched against a shared corpus.
Automatic fact extraction — rather than requiring manual curation, memory layers parse sessions and extract what to persist.

These capabilities matter for personal assistants, customer-facing chatbots, and user preference personalisation. The Dataiku Engineering Blog on agent memory in enterprise AI systems acknowledges that enterprise memory requirements are unique, though the gap between standard memory layer tools and enterprise requirements remains.

Core components of a memory layer

A memory layer typically includes:

Storage backend: Vector database (Pinecone, Qdrant, pgvector) for semantic recall, or key-value store for structured fact retrieval — chosen based on retrieval pattern.
Extraction pipeline: Logic that parses sessions and identifies what to persist — who said what, which facts were stated, which preferences were expressed.
Retrieval mechanism: At query time, relevant memory is fetched via similarity search and injected into the context window before the model responds.
Update and decay logic: Rules for overwriting stale memories, updating contradicted facts, and expiring irrelevant history — essential for accuracy over time.
Scope model: User-level, session-level, or agent-level scoping — determines what the agent “remembers” and for whom.

Why neither fully solves the enterprise problem

Context windows and memory layers solve different problems, but both share a foundational gap for enterprise AI agents. Neither holds governed metric definitions, cross-system entity relationships, data lineage, or certified access policies. These are not things you retrieve from conversation history or fit into a token budget. They are organisational knowledge; they require a different architectural layer entirely.

The context window’s enterprise gap

Expanding the context window is the first instinct when enterprise agents underperform. Load more data, get better answers. In demos, it sometimes works. In production, it fails predictably.

An MIT study found that 95% of enterprise AI pilots fail to produce measurable ROI, with missing business context (not model capability) identified as the primary cause. The problem is not token capacity. A 10M-token context window still does not know what net_revenue means in your organisation, including whether it is Closed Won or Closed Won net of returns, normalised to USD, as of what date, from which source table.

This is the “garbage in, garbage out” problem operating at the architectural level. The model reasons well over the tokens it receives. If those tokens do not encode the right business definitions, the reasoning is precisely wrong.

The AI agent cold-start problem is not just “the agent doesn’t remember previous conversations.” The deeper cold-start problem is: the agent starts with zero knowledge of this organisation’s data estate. No context window size solves that.

The memory layer’s enterprise gap

Memory layers solve session continuity, a legitimate and useful problem. But that is not the primary challenge for enterprise data agents.

The enterprise cold-start problem is “the agent starts with zero knowledge of this organisation’s data estate.” Memory layers store extracts of what was said in previous conversations. They do not hold:

Canonical metric definitions: What does revenue mean in your system: Closed Won, net of returns, USD normalised, as reported in the finance dashboard? A memory layer has no concept of a canonical definition. It might store a conversation where someone mentioned revenue, but it cannot certify which definition is authoritative.
Cross-system entity identity: account_id in Salesforce, org_id in Stripe, and tenant_id in Zendesk may all refer to the same customer. Resolving that identity requires an ontology, not a vector database.
Governance policies and access controls: Prompt instructions (“do not show PII data”) are a best-effort mechanism. Machine-enforced governance that operates before response generation is infrastructure-level, not memory-level.
Data lineage and provenance: Source table, transformation history, freshness timestamp; these are not summaries of what was discussed. They are verifiable traces that determine whether an agent’s answer is trustworthy.

Research-level validation of this gap appears in arXiv:2603.17787, “Governed Memory: A Production Architecture for Multi-Agent Workflows”. It finds that enterprise multi-agent systems suffer from memory silos, governance fragmentation, and unstructured memories “unusable by downstream systems.” These are exactly the gaps standard memory layer tools leave open.

The third architectural option: structured context

The gap that context windows and memory layers share is the same gap: governed organisational knowledge.

This is what Atlan calls a context layer: persistent, structured, governed infrastructure that encodes what an organisation defines, owns, and certifies about its data. A context layer is not a bigger context window. It is not a smarter memory layer. It is a different architectural layer with a different purpose.

The distinction is direct: a memory layer stores what was said. A context layer stores what your organisation knows and governs.

This distinction has empirical support. Snowflake’s engineering experiment found that adding an ontology layer to an agent’s context improved answer accuracy by 20% and reduced tool calls by 39%, compared to a prompt-engineering-only baseline (Snowflake Engineering Blog, “Building Trustworthy Data Agents: The Agent Context Layer”). The improvement came from structured context, not a larger window, not a memory layer.

For the full comparison between a memory layer and a context layer, including how to choose between them: memory layer vs context layer.

For the architectural model underlying the context layer: five-layer agent context layer.

Memory layer vs context window: detailed comparison

The sharpest differences between a context window and a memory layer appear in lifespan, governance, and what each actually stores. A context window is ephemeral, in-model, and processes everything simultaneously. A memory layer is persistent, external, and retrieves selectively. They are complementary in architecture, but complementary tools built for the chatbot and personal assistant use case, not for enterprise data agents.

Detailed comparison

Dimension	Context Window	Memory Layer
Primary function	Immediate in-call processing — the model’s active reasoning space	Persistent storage and cross-session retrieval of agent knowledge
Storage location	In-model (part of the inference call)	External (vector DB, key-value store, graph DB)
Lifespan	Single inference call — wiped immediately after	Persistent across sessions (until expired or deleted)
Capacity limit	Hard token limit (128K–10M tokens depending on model)	Theoretically unlimited — retrieval quality degrades with volume
Cost model	Quadratic scaling — doubling length roughly quadruples compute	Retrieval latency cost plus storage cost — much lower per-call
Retrieval mechanism	Simultaneous — everything in the window is processed at once	Probabilistic — similarity search; can miss differently-phrased content
Governance	None — no access policy, no lineage, no version control	None — unstructured storage, no schema enforcement by default
Failure mode	Silent truncation, context rot, “lost in the middle” degradation	Stale memory, probabilistic recall failure, cross-agent inconsistency
Cross-agent sharing	Not applicable — per-call	Possible but not native — each agent typically has its own memory store
Enterprise readiness	Partial — required but insufficient	Low — built for user-scoped chatbot personalisation, not governed data

Real-world example: a data analyst agent answering “What was Q4 revenue?”

The agent receives this query. The context window holds: the system prompt, any retrieved documents, and the question: roughly 2,000 tokens in this call. If revenue is defined in a document the agent retrieved, the model uses that definition. If not, the agent infers from whatever is present.

The memory layer holds: previous conversations this agent had about revenue, notes from past sessions, and any facts the extraction pipeline captured. It retrieves these and injects them into the context window.

What neither holds: the certified, governed definition of net_revenue in your organisation: Closed Won, net of returns, USD normalised, along with the source table, its lineage, its owner, and its freshness timestamp. That is a context layer problem, not a memory problem.

How to choose: context window, memory layer, or context layer

The choice between a context window, memory layer, and context layer is not either/or; all three can coexist in the same agent architecture. But over-investing in the wrong layer wastes engineering budget and leaves the core problem unsolved. The deciding question is what problem you are actually solving: in-call reasoning quality, session continuity, or governed organisational knowledge?

For more on how context engineering vs prompt engineering reframes the infrastructure problem, that page covers the shift from instruction-based to context-based agent design.

Start with context window improvements when

Your agent produces inconsistent outputs on the same input; the problem is in-call reasoning quality, not persistence.
Your prompts are competing for space, with system instructions and user data crowding each other out.
Your use case involves dense, curated information that fits within 128K–200K tokens.
You need sub-100ms latency and retrieval round-trips are unacceptable.

Start with a memory layer when

Your agent serves individual users who return across multiple sessions, such as customer support bots and personal assistants.
Session continuity is a feature request, with users expecting the agent to “remember” previous conversations.
Your user base is discrete and user-scoped recall is valuable (preferences, history, onboarding state).
You are not querying governed enterprise data — your agent is conversational, not analytical.

Consider a context layer when

Your agents query enterprise data across multiple systems — Snowflake, Salesforce, Databricks, Tableau.
“What does this metric mean?” is a question your agents answer, and the answer must be certified and consistent.
Multiple agents in your organisation need the same governed definitions (not each agent building its own memory of what revenue means).
You need machine-enforced access policies, not prompt instructions.
Your enterprise AI pilot failure rate is attributed to “agents that don’t understand our data” — not to context window size or memory persistence.

When to use all three simultaneously

In production enterprise data agent deployments, the right architecture combines all three: context window for immediate reasoning quality, memory layer for user session continuity (where applicable), and context layer as the governed knowledge foundation that both draw from.

This is the architecture that closes the gap the MIT study identifies: not better prompts, not larger windows, not more sophisticated retrieval, but governed context as infrastructure.

How Atlan approaches context windows, memory layers, and context layers

Enterprise teams typically discover the context window limit first, then reach for a memory layer, then hit the same wall from a different direction. Atlan’s context layer is the governed data infrastructure that sits beneath both: it gives every agent in the organisation consistent, certified, live knowledge of your data estate, without requiring manual curation per deployment.

The pattern that leads to the wall

Enterprise teams follow a predictable path. Build an agent. The context window fills. Reach for a larger model. Realise the cost is prohibitive at production volume. Add a memory layer. Discover the memory layer knows nothing about the organisation’s data definitions. Build the definitions manually into system prompts. Those prompts go stale within weeks. Start over.

The MIT study puts the number plainly: 95% of enterprise AI pilots fail to produce measurable ROI, with missing business context as the primary cause. The memory layer does not solve the “agent doesn’t know your business” problem. It only solves the “agent doesn’t remember the conversation” problem, which was never the hard problem.

Atlan’s context layer: what it stores and how it works

Atlan’s context layer is the governed metadata infrastructure that agents read from on every call. Not injected text. Not a vector database of conversation history. Live, certified, cross-system knowledge, structured as five layers:

Semantic layer: Governed metric definitions — net_revenue is Closed Won, net of returns, USD normalised. One definition, certified, consistent across every agent that queries it.
Ontology and identity: Canonical entities and cross-system ID resolution — the layer that knows account_id in Salesforce maps to org_id in Stripe and tenant_id in Zendesk.
Operational playbooks: Routing rules and disambiguation logic — which source is authoritative for a given question, how to handle ambiguous queries.
Provenance and lineage: Source table, transformation history, freshness timestamp — the verifiable trail from answer to origin.
Decision memory: Event trails and institutional knowledge via active metadata — continuously updated context that reads live from the source of truth.

The active metadata component is what makes the context layer different from a memory layer at the architectural level. The “memory” is never stale because it draws from the authoritative data estate, not a cached copy of a conversation. Agents connect through MCP (Model Context Protocol), using standardised, infrastructure-level integration rather than prompt instructions.

The full architecture is documented in Atlan’s agent context layer guide. The broader concept of what a context graph enables is also relevant; it is the structural backbone that makes cross-system entity resolution possible.

Customer outcomes

Workday saw a 5x improvement in AI analyst response accuracy after implementing context engineering through Atlan’s MCP server. Not a better prompt. Not a larger context window. Not a memory layer. The improvement came from giving agents governed context: the same definitions, lineage, and access policies, available on every call.

Workday: Context as culture Watch Now

The Snowflake engineering experiment confirms the direction: adding an ontology layer (structured context, not memory) improved accuracy by 20% and reduced tool calls by 39%, compared to a prompt-engineering-only baseline.

The pattern holds across both cases: the knowledge substrate matters more than window size or retrieval infrastructure.

For a deeper look at how the context layer for enterprise AI is structured and how teams implement it: that page covers the deployment architecture in detail.

See what a context layer looks like in production: Atlan’s context layer.

Wrapping up

The context window vs. memory layer debate has a clean answer: they solve different problems and both belong in a well-designed agent architecture. Context windows handle in-call reasoning; memory layers handle session continuity. Neither is wrong for the problem it was built for. Neither is sufficient on its own.

The harder insight is that both layers leave the same gap for enterprise AI: neither knows what your organisation’s data means. Governed metric definitions, cross-system entity identity, data lineage, and access policies are not things you retrieve from conversation history or fit into a token budget. They require a different layer entirely.

Why AI agents forget is a symptom worth understanding, but the fix is not a better memory layer. The fix is governed context infrastructure.

As AI agents move from pilots into production, the teams that close this gap first, those using structured, certified, live organisational context, will see the reliability and accuracy improvements that others are still waiting for. The 95% pilot failure rate is not a model problem. It is a context problem.

See what a context layer looks like in production: Atlan’s context layer.

FAQs about memory layer vs context window

1. What is the difference between a memory layer and a context window in AI?

A context window is the active token budget for a single LLM inference call, covering everything the model processes simultaneously, wiped after each call. A memory layer is external storage that persists information across sessions, retrieving relevant content into the context window at query time. The context window is your agent’s working memory; the memory layer is its long-term storage. Neither holds governed organisational knowledge.

2. Does a larger context window replace the need for a memory layer?

Not entirely. A larger context window reduces reliance on memory retrieval for in-session tasks, but it cannot replace cross-session persistence. When a conversation ends, everything in the context window is lost; a 10-million-token window is no exception. Memory layers solve session continuity; context windows solve in-call reasoning capacity. They address different failure modes and are typically used together in production agent architectures.

3. What is “lost in the middle” in large language models?

“Lost in the middle” is an LLM attention failure mode documented by Liu et al. (2024) in the Transactions of the Association for Computational Linguistics. When relevant information appears in the middle of a long context, rather than at the beginning or end, models significantly underweight it. GPT-3.5-Turbo showed more than 20% performance degradation in 20-30 document settings. This is why expanding context windows does not reliably improve agent reasoning quality.

4. What are the types of memory in AI agents?

AI agent memory is commonly categorised as: episodic memory (past events and conversation history), semantic memory (general facts and knowledge an agent can retrieve), procedural memory (skills and learned task patterns), and working memory (the context window, meaning active, per-inference reasoning). Enterprise agents require a fifth category not covered by this taxonomy: governed organisational memory, including certified definitions, data lineage, and access policies that apply consistently across all agents.

5. Why do AI agents forget between conversations?

LLMs are stateless by design; each inference call is independent, with no native mechanism to carry information between sessions. Everything in the context window disappears when the call ends. Memory layers solve this by extracting information from sessions and storing it externally, injecting relevant history into future context windows. Without a memory layer, every conversation starts from scratch regardless of prior interactions with the same agent or user.

6. Can you use a vector database as a memory layer?

Yes; vector databases like Pinecone, Qdrant, and pgvector are the most common backend for memory layer implementations. They enable semantic search over stored memories, retrieving the most relevant past information based on embedding similarity rather than exact keyword matching. The limitation: vector databases store and retrieve unstructured text efficiently, but they provide no governance, schema enforcement, data lineage, or access controls, making them insufficient as the sole knowledge substrate for enterprise data agents.

7. How does RAG relate to context windows and memory layers?

Retrieval-augmented generation (RAG) retrieves documents from an external corpus and injects them into the context window at query time. It is not a memory layer; RAG retrieves documents, not agent-specific memories. The key distinction: RAG is stateless (it retrieves the same documents for the same query regardless of prior agent interactions), while a memory layer is stateful (it retrieves personalised history specific to a user or agent session). Both ultimately inject content into the context window.

8. What does a memory layer store that a context window doesn’t?

A context window stores nothing; it is ephemeral and wiped after every inference call. A memory layer stores extracted facts, conversation summaries, user preferences, and historical interactions that persist across sessions. It retrieves this content and injects it into future context windows. For enterprise agents, this distinction matters because neither layer natively stores governed business definitions, certified metrics, or data lineage, which is the organisational knowledge that determines whether an agent’s answer is trustworthy.

References

Liu, Nelson F. et al. (2024). “Lost in the Middle: How Language Models Use Long Contexts.” Transactions of the Association for Computational Linguistics, 12. MIT Press. https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long. Also available as arXiv:2307.03172 at https://arxiv.org/abs/2307.03172
Anthropic Engineering. “Effective Context Engineering for AI Agents.” https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
IBM Research. “Why Larger LLM Context Windows Are All the Rage.” https://research.ibm.com/blog/larger-context-window
Letta Engineering Blog. “RAG is not Agent Memory.” https://www.letta.com/blog/rag-vs-agent-memory
Snowflake Engineering Blog. “Building Trustworthy Data Agents: The Agent Context Layer.” https://www.snowflake.com/en/blog/agent-context-layer-trustworthy-data-agents/
Mem0. “Memory in Agents: What, Why and How.” https://mem0.ai/blog/memory-in-agents-what-why-and-how
Dataiku Engineering Blog. “Agent memory: the missing layer in enterprise AI systems.” https://www.dataiku.com/stories/blog/agent-memory
arXiv:2603.17787. “Governed Memory: A Production Architecture for Multi-Agent Workflows.” https://arxiv.org/html/2603.17787
MIT / Fortune (August 2025). Enterprise AI pilot failure rate study: 95% of enterprise AI pilots fail to produce measurable ROI, with missing business context as the primary cause.

Share this article