2026 Comparative Analysis: Context Compaction Infrastructure for Long-Running AI Agents — Applied Technology Index
Executive Summary
Context compaction is the infrastructure process that replaces an agent’s growing working history with a smaller continuation state. It is becoming a first-class production primitive because a large model context window does not make an unbounded agent loop operationally safe: input cost and latency grow, stale material competes with current instructions, and eventually the next request no longer fits.
The reviewed systems implement three distinct architectures. OpenAI and Anthropic provide model-provider compaction inside their APIs. Google Agent Development Kit (ADK), LangChain and Deep Agents manage context in the agent framework. Microsoft Semantic Kernel exposes application-side chat-history reducers. These products solve related problems but do not create equivalent artifacts or give operators the same control.
OpenAI Responses compaction emits an encrypted, opaque compaction item. It can run automatically at a configured token threshold or through the stateless /responses/compact endpoint. Anthropic’s beta server-side compaction emits a compaction block containing a summary and permits custom summarization instructions; its separate context-editing controls can clear old tool results or thinking blocks without summarizing the entire history. Google ADK summarizes session events on token or turn-based triggers with configurable retention and overlap. LangChain offers trimming, deletion, and summarization middleware above persistent thread state, while Deep Agents combines summarization with tool-result offloading, filesystem state, progressive skill loading, and isolated subagents. Semantic Kernel supplies truncation and summarization reducers around its ChatHistory abstraction.
The central procurement finding is that compaction is not memory, persistence, caching, or durable execution. Compaction decides what the model sees next. Memory decides what can be retrieved later. Persistence preserves authoritative state. Prompt caching avoids recomputing repeated prefixes. Durable execution determines whether work resumes correctly after interruption. A production agent usually needs all five as separate, testable layers.
No reviewed provider publishes a common benchmark for compaction fidelity. Operators should therefore evaluate whether the compacted state preserves objectives, constraints, decisions, unresolved work, artifact references, tool-call invariants, approval state, and side-effect status—not only whether token count falls.
Key Findings
- The compaction artifact is a strategic interface. OpenAI returns an opaque encrypted item, Anthropic returns a provider-defined summary block, and framework-level systems retain inspectable state that applications can transform or replace.
- Automatic compaction reduces integration work but increases provider coupling. Provider-native artifacts preserve model-specific state, while application-level summaries are more portable and auditable but require more policy and testing.
- Selective deletion can be safer than global summarization for tool-heavy loops. Anthropic can clear old tool results independently, and LangChain can trim or delete selected messages. This reduces bulk without asking one summary to represent every prior event.
- Recent raw context is consistently treated as valuable. Google ADK exposes
event_retention_sizeand sliding-window overlap; LangChain’s summarization middleware can keep recent messages; provider compaction retains or emits a continuation window rather than reducing the entire run to one unconstrained sentence. - Tool-call structure constrains deletion. Assistant tool calls and their tool results often form protocol pairs. LangChain explicitly warns that invalid message histories can be rejected by providers; compaction tests must validate structure as well as semantics.
- Compaction and prompt caching can conflict. Editing an earlier prefix may invalidate a prompt cache. Anthropic documents this directly for tool-result and thinking-block clearing, while Google ADK exposes caching as a separate configuration surface.
- A summary is not an authoritative ledger. Confirmed transactions, approvals, identifiers, file versions, and external side effects belong in structured state or a durable store and should be referenced by the compacted context.
- There is no public interoperability format for compaction artifacts. Moving a live agent run between providers or frameworks generally requires an application-owned checkpoint, summary, and artifact manifest.
Methodology
This analysis reviewed official API documentation, framework documentation, and public technical guidance available on 31 July 2026. Current developer discussion was used only to identify context compaction as an active frontier signal. Product behavior and configuration claims are grounded in provider or maintainer documentation rather than social posts.
The comparison applies eight criteria:
- Compaction location: model-provider API, agent framework, middleware, or application.
- Trigger model: rendered tokens, input tokens, turn count, message count, explicit endpoint call, or custom policy.
- Output artifact: opaque provider item, visible summary block, edited history, event summary, or reduced message list.
- Control and portability: custom instructions, selectable summarizer, preserved recent events, provider dependence, and application ownership.
- Tool-use integrity: treatment of tool calls, tool results, large observations, and message-order requirements.
- State separation: relationship among active context, thread persistence, long-term memory, filesystem artifacts, and durable workflow state.
- Cost and cache interaction: extra summarization calls, repeated input billing, cache invalidation, and request size.
- Evidence gap: absence of common measurements for information retention, task completion, latency, token use, and recovery after repeated compactions.
This is an architecture and operator-fit comparison, not a benchmark. No shared agent workload was executed across the systems. Documentation examples establish supported mechanisms; they do not establish comparative quality or production reliability.
Comparative Analysis Table
| System | Where compaction occurs | Trigger and output | Operator control | Main constraint | Best operator fit |
|---|---|---|---|---|---|
| OpenAI Responses compaction | OpenAI Responses API, either during response creation or through /responses/compact | Configured rendered-token threshold or explicit compact call; returns a canonical compacted window containing an encrypted, opaque compaction item | Choose automatic or explicit mode; use stateless input-array or response-ID chaining; store=false supports a ZDR-friendly flow | Compaction content is not intended to be human-interpretable; artifact is provider-specific; prior chain input can still affect billing and retention choices | OpenAI-native long-running agents that value provider-managed reasoning continuity and minimal client-side summarization logic |
| Anthropic server-side compaction | Anthropic Messages API before continuation | Configured input-token trigger; creates a compaction block with a generated summary and continues from it | Custom summary instructions, trigger threshold, and optional pause after compaction; separate selective context-editing strategies | Beta feature and supported-model boundary; summary remains lossy; custom instructions fully replace rather than extend the default | Claude-native agents that need an inspectable, customizable continuation summary |
| Anthropic context editing and memory tool | Context editing runs server-side; memory file operations run in the customer application | Clear old tool results or thinking blocks at thresholds; retrieve persistent files on demand | Keep recent tool uses, set minimum tokens to clear, exclude tools, control thinking retention, and own memory storage | Editing can invalidate prompt-cache prefixes; memory-handler security and tenant isolation remain customer responsibilities | Tool-heavy Claude agents that need selective pruning plus just-in-time retrieval rather than repeated global summaries |
| Google ADK context compaction | ADK application and session event flow | Token threshold with recent-event retention, or turn-based interval with overlap; creates LLM-generated event summaries | Select summarizer model and prompt; configure token, interval, retention, and overlap policy; implementations span Python, Java, and TypeScript with different configuration surfaces | Framework summaries are model-dependent; language support and configuration are not identical; no published fidelity benchmark | Teams using ADK that want explicit, framework-owned event compaction across agent sessions |
| LangChain and Deep Agents | Agent middleware and graph state, with optional filesystem and subagent boundaries | Trim or delete messages, summarize at a configurable trigger, offload large results, or isolate work in subagents | Full middleware and state control; database checkpointers; custom state; filesystem backends; selectable summarizer | High flexibility creates policy burden; careless deletion can break provider message invariants or erase task facts | Multi-provider teams that prioritize application-owned context policy, persistent thread state, and composable infrastructure |
| Microsoft Semantic Kernel reducers | Application-side ChatHistory abstraction | Message-count threshold; truncation or LLM summarization reduces history to a target count | Built-in and custom reducer interfaces; automatic reduction in supported SDKs; system-message preservation | Reducer maturity differs by language; the documented .NET interface is experimental and Java reduction is unavailable | Semantic Kernel applications needing straightforward chat-history control inside an existing Microsoft-oriented stack |
Observed Profiles
OpenAI Responses: opaque model-native continuation state
OpenAI documents two compaction modes. In automatic mode, context_management with compact_threshold causes the Responses API to compact when the rendered token count crosses the configured threshold. The response stream emits an encrypted compaction item, prunes the working context, and continues inference without a separate endpoint call.
In explicit mode, the application sends a context window to /responses/compact and receives the canonical next window. OpenAI instructs clients to pass that output forward as-is because it can contain both a compaction item and retained items from the prior window. The input to the compact endpoint must still fit within the selected model’s context window, so explicit compaction needs a safety margin before the hard limit.
The artifact’s opacity is the defining trade-off. OpenAI says the compaction item carries key prior state and reasoning with fewer tokens but is not intended to be human-interpretable. This can preserve provider-specific reasoning state better than a generic text summary, yet an operator cannot treat it as an audit record, diff its decisions, or replay it through another model provider.
Conversation transport and data retention remain separate decisions. An application can append all output items in a stateless array, chain with previous_response_id, or use the durable Conversations API. OpenAI states that response objects are retained for 30 days by default unless storage is disabled, while conversation items persist beyond that response TTL. It also states that previous inputs in a response-ID chain remain billable input tokens. Compaction, persistence, privacy configuration, and billing must therefore be modeled independently.
Anthropic: full summaries, selective editing, and external memory
Anthropic’s beta server-side compaction automatically summarizes older context at an input-token trigger. The documented default trigger is 150,000 input tokens, the minimum configurable value is 50,000, and pause_after_compaction can stop the run immediately after the summary is generated. A custom instructions field can focus the summary on items such as code, variable names, or technical decisions, but those instructions completely replace the provider’s default compaction prompt.
The explicit summary block improves inspectability relative to an opaque artifact. Operators can archive and evaluate the summary, test whether required fields survived, or produce a portable checkpoint for another system. The trade-off is ordinary summary loss: a fluent continuation can omit a constraint, collapse uncertainty into a conclusion, or misstate whether an external action completed.
Anthropic also exposes narrower context-editing strategies. clear_tool_uses_20250919 removes the oldest tool results after a threshold while retaining configurable recent tool uses; operators can exclude selected tools and require that at least a set number of tokens be cleared. clear_thinking_20251015 controls preservation of older thinking blocks. These edits run before the prompt reaches Claude while the client retains its full unmodified history.
This separation supports a useful pattern: preserve the authoritative transcript outside the model, remove bulky old observations from active context, and summarize only when the remaining history still becomes too large. Anthropic warns that editing can invalidate prompt-cache prefixes. Keeping more context may increase active tokens, while clearing too frequently can cause repeated cache writes.
The memory tool solves a different problem. It asks Claude to create, read, update, or delete files under a logical /memories path, but the customer application executes those operations against its own storage. Information can be retrieved just in time across conversations without remaining in every prompt. This is persistence and retrieval, not compaction; it also requires path-traversal protection, tenant isolation, authorization, and retention policy in the customer implementation.
Google ADK: event compaction with token and turn controls
Google ADK compacts agent session events rather than relying on a provider-native continuation object. The current documentation exposes token-based compaction as the primary safety mechanism and a sliding-window, turn-based strategy for predictable conversations. If both are configured, token-based compaction takes priority for that turn.
Token-based configuration pairs token_threshold with event_retention_size, preserving a recent raw tail after older events are summarized. Sliding-window configuration pairs compaction_interval with overlap_size, carrying some prior events into the next summary window. Operators can supply an LlmEventSummarizer or LlmSummarizer, select its model, and customize its prompt.
This architecture keeps the compaction policy at the framework layer and can work with different summarizer models. It also makes the retained raw tail and overlap explicit, which helps protect immediate references and tool-call continuity. The cross-language APIs are not identical: the documentation lists version-specific support and shows App-level event configuration for Python and Java versus context compactors on TypeScript agents.
ADK’s context-caching feature is separately configured with a minimum-token threshold, TTL, and reuse interval. Caching reuses stable request data; compaction rewrites growing history. Treating them as separate features is operationally correct because one optimizes repeated prefixes while the other changes the future prompt.
LangChain and Deep Agents: application-owned context policy
LangChain stores thread-level short-term memory in agent state and persists it through a checkpointer. Its documented context-management options include trimming messages before model calls, permanently deleting messages from graph state, and replacing older history with a model-generated summary through SummarizationMiddleware. The middleware can trigger by token count and preserve a configured number of recent messages.
The application owns both power and risk. It can preserve structured state fields outside the message queue, choose a cheap summarizer model, route different tasks to different providers, and inspect every reduced history. It can also create an invalid conversation by separating an assistant tool call from its tool result, removing a required opening message, or deleting a fact that was never written to structured state. LangChain explicitly warns operators to preserve provider message-history requirements.
Deep Agents broadens context management beyond chat summarization. Its documented harness combines progressive skill loading, persistent AGENTS.md memory, automatic history summarization, offloading of large intermediate results, filesystem-backed artifacts, prompt caching, and subagents with isolated context windows. Isolation is a form of context control: a child agent can absorb a large subtask transcript and return only its result to the parent.
This layered design is portable and inspectable, but it is not one compaction algorithm. Procurement should test the complete harness configuration: where files live, whether a summary refers to immutable artifacts, what subagents return, how state is checkpointed, and which middleware runs before each model call.
Semantic Kernel: reducers around chat history
Semantic Kernel represents conversation context through ChatHistory and documents three reduction approaches: truncation, summarization, and token-based policy. The built-in ChatHistoryTruncationReducer discards older messages, while ChatHistorySummarizationReducer summarizes removed content and adds the summary back as one message. Both preserve system messages.
The reducer abstraction is useful when a team wants context policy to remain application-side and close to its existing orchestration code. In .NET, IChatHistoryReducer also permits custom implementations. Python supports truncation and summarization reducers with configurable target and threshold counts and optional automatic reduction.
The language-support boundary matters. The official page marks the .NET reducer interface experimental and states that chat-history reduction is unavailable in Java. A cross-language estate should verify SDK parity instead of assuming the same Semantic Kernel feature set is present everywhere.
Deployment and Evaluation Implications
Create an authoritative state envelope before adding compaction. Store the task objective, current plan, accepted constraints, artifact identifiers, completed steps, pending approvals, side-effect receipts, and next action in structured state. A compaction summary may reference this envelope but should not replace it.
Preserve raw evidence outside the active prompt. Keep an append-only event log or retained transcript under an explicit privacy and deletion policy. Active context can then hold a compact summary plus pointers to tool outputs, files, database records, and traces that remain available for targeted retrieval.
Set the trigger below the hard limit. Reserve tokens for system instructions, tools, current input, reasoning, and maximum output. Explicit compact endpoints still require the pre-compaction window to fit, and a large tool result can consume the remaining margin unexpectedly.
Compact only at valid boundaries. Avoid cutting between a tool call and result, during a transaction, or while an approval is being resolved. Where the platform exposes only token thresholds, add application checks that move large observations into artifacts early and keep consequential actions in durable state.
Use a schema for summaries. Require sections for objective, immutable constraints, decisions with rationale, completed work, unresolved questions, artifact pointers, external side effects, approval state, and next steps. Reject or retry a compaction if mandatory fields disappear.
Evaluate repeated compactions, not one summary. Loss compounds. Run long tasks through several compaction cycles and score final task success, constraint retention, unresolved-item recall, artifact retrieval, tool-call validity, unsupported certainty, and recovery after restart.
Measure the complete cost curve. Track tokens before and after compaction, compaction-model tokens, cache reads and writes, request bytes, model latency, tool latency, retrieval calls, summary retries, and human corrections. A smaller context can still cost more if frequent edits destroy reusable cache prefixes.
Version the compaction policy. Record provider, model, threshold, summary instructions, middleware order, retained-tail policy, and schema version in every trace. A model or prompt change can alter what survives even when the application code does not change.
Design provider migration before an incident. If the primary compaction item is opaque, periodically emit an application-owned portable checkpoint. Test restoring the agent from the checkpoint, structured state, and artifact manifest without relying on the original provider’s hidden continuation object.
Limitations
This analysis relies on public documentation available on 31 July 2026. It does not include hands-on cross-provider runs, private implementation details, model-specific compaction prompts except where documented, enterprise retention contracts, security assessments, or production incident data.
The systems are not direct substitutes. OpenAI and Anthropic expose model-provider API behavior; Google ADK, LangChain, Deep Agents, and Semantic Kernel operate at framework or application layers. A production stack can combine provider-native compaction with framework-level persistence, offloading, retrieval, and policy.
Several features are beta, experimental, or uneven across models and programming languages. Anthropic server-side compaction is beta, its context editing uses a separate beta surface, Semantic Kernel marks its .NET reducer interface experimental, and documented language parity varies. Exact model names, headers, defaults, and SDK support should be rechecked before deployment.
No common public benchmark establishes which method best preserves long-horizon task performance. Provider documentation explains mechanisms and sometimes gives examples, but it does not provide controlled comparisons across identical agents, tools, workloads, models, token budgets, and repeated compaction cycles.
The article compares text-level and event-level context management. It does not evaluate lower-level KV-cache compression, model-training methods for context management, retrieval-ranking algorithms, or the quality of particular summarizer models.
References
- OpenAI: Compaction guide
- OpenAI: Responses compact API reference
- OpenAI: Conversation state
- Anthropic: Server-side compaction
- Anthropic: Context editing
- Anthropic: Memory tool
- Anthropic Engineering: Effective context engineering for AI agents
- Google ADK: Compress agent context for performance
- Google ADK: Context caching with Gemini
- LangChain: Short-term memory
- LangChain: Deep Agents overview
- Microsoft Semantic Kernel: Creating and managing chat history
Changelog
- 2026-07-31: Initial publication.
Corrections
No corrections have been issued for this document.