When someone asks an agent "what did we decide about the cron schedule last Tuesday?", the model is not retrieving from a database. It is routing the query across three distinct places: the current context window, the memory layer, and its own pattern-matching weights. Each place has a different latency, a different reliability profile, and a different failure mode. The three places compose into the behavior that looks like understanding from the outside.

This piece is about that routing. It names what each place is, what it is good at, what it fails at, and how the three interact on a single query. The operational goal is to know where to put a fact so the right place answers it.

The three places model

The three places are not equally weighted. Which one answers a given query depends on what the query asks, what is available in each place, and how the query is framed. Context answers queries about what is currently in front of the model. Memory answers queries about what was written down and indexed. Pattern-matching answers queries that match something in the training distribution.

The operator's job is to put facts where they will be found. A fact in the wrong place produces a confabulation. A fact with no place at all produces silence or a guess.

Context: the working window

The context window holds what is in front of the model right now. System prompt, prior turns, retrieved documents, tool outputs, the user's current message — all of it stitched together and fed into a single model call.

Context is authoritative. Whatever is in the window is what the model sees, and the model answers from what it sees. If the answer is in the window, the model will usually produce it correctly. If the answer is not in the window, the model produces its best guess from the other two places.

Context is fast. No retrieval step, no file read, no semantic search. The cost is token count, which grows with the context. Most providers charge per token for both input and output, so a full context window is not free.

Context fails in three ways. First, the window fills. The oldest content gets truncated, and whatever was lost is invisible to the model. Second, the window can be poisoned — a tool output that contains misleading information gets treated the same as accurate information, because both are inside the window. Third, anything not in the window is invisible. The model has no way to reach for something that was never placed there.

This is why context management matters so much in agent work. The piece on context management and system prompts covers how to assemble what goes into the window and in what order.

Memory: what survives between sessions

Memory is what the agent has written to durable storage and what the operator has indexed for retrieval. It survives between calls and across sessions. Where context is the working memory of the current call, memory is the notebook.

The strength of memory is persistence. Facts written to memory are available in future sessions without being re-learned. A decision recorded in a project memory file last month is still there when the agent starts a new session today. Memory is cumulative — the agent can build on what it wrote before, reference what it agreed to in a prior session, and maintain continuity.

The failure mode of memory is compression artifacts. Memory is written as a summary, not as a transcript. The agent decides what to write and how to compress it. That decision introduces bias. What gets dropped in compression is invisible at retrieval time — the agent sees the summary, not the gaps. The operator controls what gets saved, which means the operator also controls what gets forgotten.

The piece on memory: short, long, and semantic covers the three-layer model and why each layer has a different job.

Pattern-matching: what's in the weights

The third place is not a place at all. It is the model's weights — the billions of parameters that were adjusted during training to predict the next token well. When the model answers a question about history, or produces a plausible-sounding explanation of a technical concept, it is pattern-matching against what it saw in training.

Pattern-matching is fast and free. It costs nothing to retrieve and requires no setup. The model has it always.

The failure mode is confabulation. The model produces the most likely continuation of the text it has seen. When the continuation does not correspond to anything real — a citation that does not exist, a date that is wrong, a tool that was never built — the model cannot tell. There is no internal check that says "this was in training but it is not true." The check is external: retrieval, verification, a tool call, a database query. The piece on what is an LLM covers this under the next-token view.

How the three compose: a single query walkthrough

Take the query: "what did we decide about the cron schedule last Tuesday?"

Context might answer it if the conversation from last Tuesday is still in the working window. The model reads the prior turns and produces the answer from what it sees. Fast and accurate if the window is still warm. The complication: most sessions compact after a few thousand tokens, and anything more than a day old is almost never in the working window.

If context has been compacted or truncated, memory might answer it. The agent reads the session notes from last Tuesday, or the weekly summary file, or the project memory. This requires the fact to have been written down and the file to have been indexed. If it was never written, memory cannot retrieve it.

If neither context nor memory has the answer, the model falls back on pattern-matching — producing something plausible about typical cron schedules, what the agent's training suggests is normal, or what "usually happens" in comparable setups. This is the least reliable answer, but it is also the only answer available when context and memory are both empty.

In practice, a well-designed agent tries all three in order: check context first, then memory, then weights. Each layer is a fallback for the one before it. The operational question is always: where should this fact live so the right layer answers it?

Operational consequences

The first consequence is placement. A fact that matters should be in the place that will be checked first for the kind of query that will ask for it. A fact that matters in every session belongs in memory. A fact that matters only in the current session belongs in context. A fact that the model should know from training — a language pattern, a coding convention, general world knowledge — belongs in the weights, where it already is.

The anti-pattern is dumping everything into context. The temptation is to put every fact, every reference, every document into the working window, reasoning that more context means more accuracy. What actually happens is that the window fills, the most recent content crowds out the most important content, and the model starts missing things that were there at the beginning. The fix is bounding context deliberately. The piece on context management and system prompts covers the bounding patterns.

The second consequence is that memory is not authoritative. Memory is a summary written by the agent, not a transcript produced by the system. The summary is useful, but the original is gone. When the agent retrieves a fact from memory and acts on it, the act is based on a compressed version of the original. The operator who treats memory as ground truth is building on a compression artifact. The right practice is to verify memory against the source when the stakes are high.

The third consequence is that the model cannot answer questions that belong in memory. Asking the model to recall a decision from last month, without having that decision in context or memory, is asking the model to confabulate. The answer will sound plausible and may even be correct, but there is no way to know which without verification. The discipline is to put the fact in memory when it is made, and to retrieve it from memory when it is needed, rather than asking the model to generate it.

What this is not

This piece is not about LLM consciousness or whether models understand in the way humans do. Those are philosophical questions with no settled answers. The pragmatic account here is about what the three places are, what they are good at, and how to use them deliberately.

This piece is not about benchmarks. The question of whether a model "really" understands a query or is pattern-matching is not answerable from the outside, and treating it as the central question leads to dead ends. The operational question is always: where should this information live so the agent can use it correctly?

This piece is not a guarantee that following the three-place model prevents errors. Each place has failure modes that cannot be fully engineered away. Context overflows. Memory drifts. Pattern-matching confabulates. The three-place model is a frame for thinking clearly about where failures originate, not a recipe for eliminating them.

See also

  • Context vs Memory — the foundational distinction between the working window and what survives between calls.
  • Agent Memory — what survives across sessions and how the memory layers compose.
  • Embedding — the geometry of semantic search that memory retrieval is built on.
  • Compaction — what happens when the context window fills and older turns get compressed into a summary.
  • What Is an LLM? — the next-token view explains why pattern-matching is all the model has by default.
  • How Does an Agent Think? — the sibling piece; think is the loop, understand is the query routing across the three places.
  • Context Management and System Prompts — where context assembly happens and how to control what goes into the window.
  • Memory: Short, Long, Semantic — the three memory layers and their different jobs.
  • Inside the Agent Loop — the six stages where the three-place model is exercised on every turn.