The problem is not just a full context window

A coding agent starts with a small job: inspect a failing test, trace a dependency, change a module, run checks, and explain the patch. Then the job expands. It reads issue history, opens dozens of files, calls tools repeatedly, absorbs test output, encounters a deployment warning, and carries instructions about what it must not touch.

Eventually, the full transcript becomes too large or too expensive to send on every model request. The obvious response is to summarize it. That response is necessary, but it is also where long-running agents can quietly become unreliable.

Long-horizon context management is the deliberate control of the information visible to a model as an agent task outgrows a practical context budget. It includes deciding what to retain, summarize, remove, retrieve later, and store outside the conversation. The aim is not merely to fit under a token limit. It is to preserve enough continuity for the agent to finish the right task under the right constraints.

This is a working term, not settled industry terminology. You will also see agent context management, context compaction, context compression, and long-running agent state management. “Compaction” usually means replacing part of a transcript with a shorter representation. Context management is broader: it also covers deletion, retrieval, caching, state schemas, validation, and recovery.

Plain English: When an agent’s history gets too large, do not just make it shorter. Deliberately decide which facts must remain available, which facts can be fetched again, and which rules must never depend on a summary.

This matters now because agent runs are becoming longer and more tool-heavy. Anthropic’s Python 1.6.0 and TypeScript 0.126.0 SDK releases on September 15, 2026 added beta context compaction parameters and signed compaction blocks, making compaction an explicit runtime concern rather than an improvised prompt trick. Anthropic Python SDK release Anthropic TypeScript SDK release

Active context is a working set, not an archive

A model only works from the active context: the instructions, messages, tool outputs, and other material included in its current request. A transcript may be historically complete while still being a poor active context. Raw command output can crowd out the actual task. An old but binding restriction can be displaced by recent chatter. A 20,000-line log is not useful merely because it is available.

A robust design treats the active context as a working set. It should contain what the model needs to make its next decision, not every detail that happened before. The rest belongs in one of three places:

  • a compact state representation for facts that must remain immediately available;
  • external memory for durable, queryable material that can be retrieved when relevant; and
  • authoritative systems of record for things that must be exact, such as source files, issue IDs, deployment records, transaction identifiers, and permissions.

That last distinction is crucial. A model-generated summary can say that a migration succeeded. It is not proof that the migration succeeded. For irreversible or high-impact work, the authoritative record must remain outside the model’s prose.

Plain English: A compacted conversation can help an agent keep thinking. It should not become the only record of what the system did.

How compaction works in practice

The implementation details vary, but the lifecycle is consistent.

First, the runtime watches context growth. The trigger might be a token threshold, a maximum number of tool calls, a cost budget, or a policy boundary before a risky action. Waiting for the request to fail is a weak trigger: it leaves no room to preserve state carefully.

Second, the runtime chooses an operation. It may summarize older messages into structured state. It may selectively remove old tool results that have already been incorporated into a decision. Or it may move material to external storage and leave a compact reference that tells the agent how to recover it.

Third, the runtime creates a projection of the task. Good projections distinguish durable facts from conversational narration. They might capture the goal, explicit acceptance criteria, completed actions, unresolved questions, relevant resource identifiers, changed artifacts, pending checks, and non-negotiable constraints. They should not pretend to preserve every nuance of the original exchange.

Fourth, the runtime constructs the next request from that projection plus recent interaction. If a provider returns a typed compaction block, treat it as protocol data, not as ordinary assistant text. Persist it and round-trip it exactly as required by that provider’s protocol; associated opaque metadata may also be necessary to preserve continuity. Anthropic’s new signed blocks are a concrete sign that this boundary is becoming part of agent infrastructure. Python release TypeScript release

Finally, validate the transition. The agent should be able to state its current goal, the next safe action, and the constraints that still apply. For higher-risk workflows, pause at the boundary for a policy check, an evaluation, or human approval.

This is Context Engineering at runtime. Context Engineering is the broader discipline of selecting, structuring, and ordering model-visible information. Long-horizon context management is the lifecycle problem: what happens when that information grows, changes, is condensed, and must survive across requests or sessions.

What it is not

Compaction is often confused with prompt caching. Prompt caching reuses a stable prompt prefix so a provider need not recompute or retransmit it in the same way. Compaction reduces or changes the information the model actively sees. These techniques complement each other, but caching does not solve information loss, and compaction does not guarantee lower inference cost.

It is also not simply conversation summarization. A summary is one output. Context management includes the trigger, the schema, selection rules, preservation of protocol objects, recovery behavior, and tests around the boundary.

Nor is it a reliable checkpoint. A checkpoint supports recovery from a known state, normally using reproducible external data. A language-model summary is probabilistic and lossy. It may be helpful to resume reasoning, but it is insufficient as the sole basis for a database write, a production rollout, or a security-sensitive decision.

Plain English: A summary is a useful briefing for the next model call, not a transaction log, permission system, or source of truth.

Example: a repository-maintenance agent

Consider a hypothetical agent assigned to update a service after a dependency deprecation. It must locate usages, make a backward-compatible change, run the project’s checks, and prepare a pull request. It is allowed to alter one repository, but not to deploy or change cloud infrastructure.

At the start, the agent sees task instructions, repository policy, and its tool permissions. As it works, it accumulates file reads, search results, failed test logs, package metadata, diffs, and explanations. After enough calls, the runtime compacts.

A weak design asks the model for “a summary of everything so far,” drops the transcript, and continues. That summary may omit the exact failing command, the version constraint, or the instruction not to change deployment configuration. It may describe a patch without retaining the specific files changed.

A stronger design creates structured task state. It preserves the objective, the approved repository scope, files modified and their current revisions, tests run and their results, the unresolved compatibility question, and the restriction against deployment changes. Large logs are stored externally with stable references; the agent can fetch the relevant section if it needs it. The actual repository remains the authority for file contents.

The next request contains the compact state, recent messages, and only the fresh evidence needed to choose the next action. Before opening a pull request, an evaluation compares the pre- and post-compaction behavior in the same repository state. Does the agent still avoid deployment files? Does it rerun a test already known to fail for an unrelated reason? Does it ask for missing information rather than inventing it?

The restriction should not live only in prose. The agent’s guardrail against deployment changes needs enforcement in its tool layer and authorization layer as well. A summary can reinforce a rule; it cannot safely be the only mechanism that prevents a prohibited action.

Where it breaks

The fundamental failure is lossiness. Summaries omit exact values, uncertainty, provenance, and qualifying conditions. Repeated compaction compounds that loss: a summary of a summary has fewer opportunities to preserve an important detail.

Safety constraints are particularly vulnerable. A 2026 study reports that compaction can silently remove in-context governance constraints, after which agents may take prohibited tool actions. Governance Decay study Another 2026 empirical study reports that recurrent compression can weaken recent interaction influence and lead to blocked actions, repeated exploration, and execution instability. Execution instability study These are research findings, not proof that every implementation fails this way. They are a strong reason to test the boundary instead of trusting fluent summaries.

There are more mundane failures, too. A summary can preserve narrative continuity but lose the version of a file that a patch assumed. A provider-specific compaction block may be incorrectly serialized or omitted during a retry. A recovery path may retry an already-expensive operation, or continue after a malformed summary when it should stop.

The answer is not “never compact.” Without it, many useful long-running workflows eventually run out of room. The answer is to make loss explicit and to keep critical state outside the lossy layer.

What a senior engineer can do this week

Start with one bounded agent workflow, not an open-ended autonomous system. Instrument context size, compaction triggers, failures, retries, and the number of times an agent repeats a completed investigation. That turns a vague quality issue into observable behavior.

Define a state schema before asking a model to summarize. At minimum, separate goal, completed work, pending work, constraints, identifiers, artifacts, and uncertainty. For every field, decide whether the compact state is authoritative, advisory, or merely a pointer to an external record.

Then build evaluations that cross a compaction boundary. Give the agent a task with an important constraint early in the run, enough irrelevant tool output to trigger compaction, and a tempting later action that violates the constraint. Check whether external controls still deny that action even if the compacted state is incomplete.

Finally, design recovery deliberately. Decide whether a compaction failure should halt, retry, rebuild state from external records, or resume with the original transcript when available. The correct choice depends on the cost and reversibility of the next action. The important part is that it is a designed policy, not accidental behavior from a token-limit error.

Long-running agents will always have limited active context. The engineering opportunity is to turn that limit into an explicit state boundary: observable, testable, recoverable, and never solely responsible for preserving the controls that matter.