AI Dictionary: Context, Memory, and Handoffs

This dictionary focuses on LLM-based coding agents. Product behavior varies by model, API, and harness. Entries explicitly marked as informal describe working vocabulary used here, rather than universal technical definitions.

Dictionary overview

Context

The relevant information the agent has access to right now. The abstract noun — not the model’s capacity limit (that’s the context window), not the running history (that’s the session), but what the agent knows that’s pertinent to the task. “Loading something into context” means making it part of this set; “context engineering” is the discipline of curating it.

The three terms separate cleanly:

Term	What it names
Context	The task-relevant information the agent currently has
Context window	The capacity for the model’s active input and generation
Session	The running conversation the harness stores

The separation matters because context is a measure of quality, not quantity. A context window can be nearly full and the context still poor — thousands of tokens of stale tool output, none of it about the task at hand. It can also be nearly empty and the context excellent: the one type definition the task turns on.

Context problems are one useful explanation to investigate. When the agent invents an API, contradicts a decision, or guesses at a schema, the first question is what was in context when it did — the relevant fact may be missing, stale, contradicted, or overlooked. One possible fix is curation: load what the task needs, keep out what it doesn’t.

Context engineering

Designing how information reaches a model during a task: what to include, retrieve, summarize, preserve, or omit. It includes instructions, tools, retrieved sources, conversation state, and memory, not just the wording of one prompt.

For example, a debugging harness supplies the failing assertion, current function, relevant type definition, and test command instead of dumping the whole repository. It re-reads files after edits and records decisions before compaction. The aim is sufficient, current evidence with clear provenance and manageable context.

Context window

The maximum amount of context a model can process for an inference, usually measured in tokens. People also use the term loosely for the current contents of that context; the distinction matters when comparing capacity with actual usage.

Input can include system and developer instructions, user messages, selected conversation history, tool definitions, and tool results. Multimodal inputs can consume capacity too. Depending on the model and API, generated output and reasoning tokens also count toward the limit, with separate output limits possible.

For example, a hypothetical model with a shared 32,000-token limit cannot accept 31,000 input tokens and then generate 4,000 more within that same limit. The application must reserve output room, reduce input, or use another model.

The stored session can be much longer than the active context: the harness may select, summarize, or retrieve history. A large window gives capacity, not a guarantee that every included detail will be used reliably.

Attention relationship

An informal name here for a connection computed by a transformer’s attention mechanism. For a query position, an attention head weights permitted key positions and combines their value representations. In causal self-attention, a token can attend to earlier positions and itself, not future tokens.

For example, processing “Sarah opened her editor” may involve attending to “Sarah” when representing “her.” This illustrates a possible association; attention weights alone are not a complete explanation of pronoun resolution or model understanding.

Dense self-attention over N positions has quadratic pairwise work during input processing. Architectures and implementations vary, and cached keys and values reduce repeated work during generation. That compute relationship does not establish a universal quality threshold or prove that useful information receives a smaller share as input grows. See the original Transformer paper.

Attention budget

A practical metaphor for the limited context and processing capacity available to a task. It is not a measurable, fixed reservoir of understanding that is divided equally among tokens.

For example, ten pages of unrelated build logs can make the relevant failure harder to find and cost more input processing. Extracting the failing assertion, exit code, and surrounding lines can give the agent better evidence with less input.

More context can also help: a missing type definition is worth adding. The aim is useful information in a form the model can use, rather than the smallest possible input. Attention weights can remain concentrated despite a longer sequence; dilution is not an inevitable arithmetic law.

Attention degradation

An informal label here for declining reliability in using context as it becomes longer, noisier, or harder to navigate. Related terms include context rot and lost in the middle. The symptom is observable; its cause cannot be read directly from a token count.

For example, an agent overlooks a constraint buried among many file dumps but follows it when the relevant files and constraint are supplied together. Lost in the Middle found position-sensitive performance on retrieval and question-answering tasks in the models tested; that does not define a universal threshold for coding agents.

Check other explanations too: stale observations, conflicting instructions, missing evidence, a changed model, or a tool failure. Reduce irrelevant material, retrieve fresh evidence, or compact when appropriate. Compaction can lose information, so preserve critical constraints and verify the result.

Smart zone

An informal working metaphor for the range in which an agent uses its context reliably on a particular task. “Dumb zone” describes observed deterioration. Neither is a standard model property, and there is no established universal boundary at 125,000–150,000 tokens.

Effective context use depends on the model, task, information placement, distractions, and harness. A short context can be inadequate if it lacks evidence; a long one can work well if the relevant information is accessible.

For example, repeated failures to apply a documented constraint are a reason to inspect the active context and simplify it, even when the window is far from full. Preserve the constraint in a durable document before clearing or compacting. Use observed task quality and evaluation, rather than an assumed token threshold, to decide when to reset.

Clearing

Resetting the active conversation context, typically through a product command or by starting a new session. Fresh context still contains applicable system instructions, project guidance, and any memory the harness loads; it is not literally empty.

For example, after abandoning one implementation approach, write down the accepted requirements and start fresh with those requirements and the relevant files. This can reduce interference from old plans, but it also removes useful active history.

Clearing is not necessarily deleting stored transcripts or files. Retention, resume behavior, and memory controls depend on the product. Compare compaction, which carries selected conversation state forward instead of dropping it.

Compaction

Reducing active conversation state so work can continue within the model’s context limit. A harness may replace older messages with a readable summary; a provider may return a compacted state representation. This usually continues the same session.

For example, ten test runs become “The parser still fails on empty input; current patch is in src/parser.ts; rerun the parser tests.” The full logs may remain in stored history even though they are no longer active input.

Compaction trades detail for room. A missed constraint or stale conclusion can affect later work, so preserve decisions and verification evidence in durable files and re-read important sources.

Not every compacted item is a prose handoff. OpenAI’s compaction API can return an opaque encrypted item along with retained conversation items. Follow the product’s handling requirements rather than assuming every summary can be inspected or edited.

Auto-compact

Compaction triggered automatically when a harness or provider decides active context needs reducing. Thresholds and mechanisms vary; there is no universal 80% rule.

For example, a long debugging run crosses a configured limit, older context is compacted, and the agent resumes in the same conversation. It may retain the general plan while losing the exact failure that mattered.

Keep constraints, progress, and meaningful verification in durable artifacts during work. Manual compaction at a phase boundary may help where supported, but avoiding every automatic compaction is not a requirement. Configuration and the ability to disable it depend on the product.

Memory system

A system that attempts to make an agent stateful across sessions. Persists information into the environment during a session and reloads it into the context window at the start of future sessions or when relevant during work, so the agent carries continuity beyond the user clearing the session.

A memory system has two halves. The write path: during a session, the agent records what it learned — a preference you stated, a fact about the project — in persistent storage. The read path: the harness or agent retrieves relevant records at startup or during work; storage may be files, a database, or a service. Many harnesses ship their own memory system — Claude Code’s auto memory is one, with /memory providing inspection and controls — but you can also build one yourself: a directory of notes plus an instruction in AGENTS.md to consult it.

The same trade-offs as any always-loaded content apply. Memories accumulate, so some systems load a concise index and leave the bodies behind context pointers rather than inlining everything. And memories are secondary sources, so they drift: a fact recorded in March may be retrieved in June after the project has moved on. A memory system needs pruning, the same way AGENTS.md does.

For example, save “This project uses pnpm” with a pointer to the package-manager configuration, then verify it still matches when retrieved. Avoid storing secrets or unnecessary personal information in reusable memory. See Claude Code’s memory guide for one implementation.

Handoff

Transferring responsibility and relevant information to another agent, session, or person. It may use a written artifact, copied history, a summary, or framework-managed state. A handoff can have a return path; it does not inherently make the previous actor unreachable.

For example, a planning agent gives an implementer the agreed scope, acceptance criteria, relevant paths, and unresolved decisions. The implementer verifies the current files before relying on the plan.

The receiving actor may inherit context or start with only the brief. Write the brief so it stands alone either way. Record what was decided and why, what is complete, what remains, and what needs verification. Compaction transfers active context within a continuing session; it is related to handoff but does not necessarily transfer responsibility.

Handoff artifact

A document that carries relevant information across a handoff. Specs, tickets, and plan docs can serve this role, alongside an explicit progress brief.

The reason to write one: clearing active context can remove the only currently loaded copy of a decision. Decisions, constraints, half-finished plans — all gone with the context that held them. The environment persists. Writing the important state into a file moves it somewhere the next session can read it back from.

The artifact is a secondary source — an account of the session’s work, not the work itself. That’s what makes it small enough to brief a fresh session, and also why it can mislead one: it records what the writing session believed, and anything it left out or got wrong is invisible to the reader. Where a claim matters, the next session should verify it against the primary source — the code, the tests — rather than inherit it.

A good artifact is written to be read into a session that has zero context. Concrete file paths rather than “the file we discussed”. What was decided and why, so the next session doesn’t relitigate it. What’s done and what’s left. It helps to tell the writing session where the artifact is headed: “write a handoff doc for a fresh session that knows nothing about this work”.

Compaction is another way to carry context forward, through a summary or a provider-managed representation. The artifact has two advantages: it lives on disk where you can read and correct it before anything depends on it, and it can be reused — the same spec can brief five parallel sessions.

For example, a useful brief says “Parser handles quoted fields; empty input still fails; see src/parser.ts; run the parser tests.” “Almost done” does not tell the next session what to verify.