How do I keep an AI agent’s important state when its context gets compacted? Put an application-level gate around compaction: measure context pressure, request compaction with room to spare, validate the resulting continuation state against a versioned schema, and resume only when required state and policy checks pass. A successful compaction response alone is not proof that the agent has enough reliable state to continue.
This gate is an application design pattern, not a universal feature or checkpoint contract prescribed by OpenAI or Anthropic. Their APIs document provider-specific ways to carry conversation state forward; your application must define what state matters and what to do when it is missing or invalid.
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
As an Amazon Associate I earn from qualifying purchases.
Separate application context from model-visible context
Agent systems often use “context” for two different things. Application-local context can contain dependencies, services, and state used by tools and callbacks. Model-visible context is the material available to the model in the conversation. OpenAI Agents SDK documentation makes the distinction explicit: “The context object is not sent to the LLM.” See the Agents SDK context documentation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Keep those layers separate. A continuation checkpoint should carry only the information the model needs to continue the task. Do not serialize secrets, live dependency objects, or privileged application policy into a prompt-facing checkpoint. Keep authorization and other enforcement in application code.
#1 Best Overall
What compaction preserves—and what it does not promise
Compaction is a continuation mechanism, not simply a command to delete old messages. The OpenAI Responses API documentation describes a compaction item that carries prior state forward using fewer tokens. Its standalone compaction endpoint returns a compacted window that should be passed forward as-is. Anthropic represents compaction with a block that must remain in subsequent requests. Follow the instructions for the provider you use; these representations are not interchangeable.
- OpenAI compaction guide
- OpenAI Responses API compaction endpoint
- Anthropic context-window documentation
These provider mechanisms do not define your application’s required state, validation rules, or recovery policy. Structured output and typed context can help express a contract, but they cannot decide which facts are essential, stale, optional, or safe to reconstruct.
Define a versioned continuation checkpoint
Create distinct types for local application state and the compacted, model-visible continuation state. The separation is a design choice informed by the SDK’s distinction between local context and model input. Make the continuation type explicit and version it so the application can reject or migrate incompatible checkpoints.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
For example, a checkpoint may include these fields:
schema_version: the checkpoint format version.task_goal: the user’s objective in concise form.current_phase: where the workflow is now.completed_work: results that should not be repeated.pending_actions: work still required, with dependencies where relevant.user_constraints: important preferences, boundaries, and requirements.relevant_references: identifiers or concise facts needed to retrieve authoritative source material.unresolved_decisions: open questions that must not be silently treated as settled.compacted_through: a marker identifying the conversation or work boundary represented by the checkpoint.
These are proposed application fields, not a provider standard. Decide which are mandatory for your workflow. For instance, a research agent may require outstanding questions and source references; a transaction agent may require authorization status and a durable operation identifier maintained outside the model-visible checkpoint.
Use a gate with explicit outcomes
Represent the gate as an application state machine rather than a single “compact and continue” call. A practical contract has four outcomes:
continue_without_compaction: pressure is below the trigger and the existing context can continue.compact_and_validate: request compaction and validate the returned state before resuming.repair_or_retry: the compaction failed or the checkpoint needs a bounded repair attempt.stop_for_review: required state is missing, contradictory, unsupported, or cannot be repaired safely.
This is a recommended design, not an official OpenAI or Anthropic feature. The central rule is that successful compaction does not itself authorize continuation.
Recommended Free Tools
Implement the gate in a safe order
- Estimate context pressure. Use the actual model and request limits, and account for input, output, and reasoning tokens where applicable. OpenAI notes that context limits can cover input and output (and, for some models, reasoning tokens); excess generation may be truncated. Check the current model-specific documentation rather than applying a universal threshold. See OpenAI conversation-state documentation.
- Reserve headroom. Trigger before the request window is exhausted, leaving room for the compaction instruction and its response. Tune the margin against your workload, provider, and model. The documentation does not establish a universally correct numeric threshold.
- Request compaction using the provider’s supported mechanism. Do not assume that a provider-managed threshold and an application-triggered request behave identically, or that one provider’s continuation format can be passed to another.
- Preserve the canonical provider representation. For OpenAI’s standalone compaction endpoint, pass the returned compacted window forward as-is. For Anthropic, carry the compaction block into subsequent messages. Do not run a generic pruning or rewriting rule over provider continuation items.
- Parse and validate the application checkpoint. Check schema version, required fields, types, policy invariants, contradictions, and whether critical constraints and pending actions survived. OpenAI Agents SDK supports typed context and structured output schemas, with local validation for supported schema types; see its agent documentation. Schema support helps enforce shape, but your application must define semantic checks.
- Decide whether work may resume. Resume only if both the provider continuation material and the application’s required state are acceptable. A malformed response, missing constraint, unsupported schema version, or insufficient headroom should take an explicit failure path.
- Validate before side effects. Before tools mutate external state or the agent resumes consequential work, check authorization and policy using trusted application data. OpenAI’s handoff guidance documents schema parsing and validation patterns and warns that authorization depending on parsed fields must be checked before application side effects. Applying that conservative rule to compaction checkpoints is an application design recommendation, not a compaction guarantee. See Agents SDK handoff documentation.
Choose where control and state ownership belong
| Design axis | Provider-managed compaction | Application-owned typed checkpoint |
|---|---|---|
| Control | Provider mechanism or threshold determines when its compaction occurs, as documented for that API. | Application decides when to request compaction or construct a checkpoint. |
| State representation | Provider-specific continuation item or block. | Application-defined fields validated against a schema. |
| Portability | Continuation representation is provider-specific; do not treat payloads as interchangeable. | Schema can be owned by the application, but provider continuation data still follows provider-specific rules. |
| Recovery | Provider documentation does not establish a universal application recovery policy. | Application defines repair, retry, migration, or stop-for-review behavior. |
| Operational cost | Evaluate latency, token use, and correctness under repeated compaction for your workload; no general measured outcome is established here. | Evaluate the same factors, including validation and repair overhead, in your implementation. |
Make failures visible and recover deliberately
Do not silently treat an invalid checkpoint as complete. Route failure according to its cause:
Best Value
- Compaction request fails: retry only within an explicit limit; otherwise stop or use an application-defined safe fallback.
- Required state is absent or contradictory: attempt a constrained repair if safe, or stop for review. Do not infer that an omitted user constraint no longer applies.
- Schema version is unsupported: migrate through an explicit, tested path or stop. Do not parse an unknown version as though it were current.
- There is not enough headroom: avoid starting a compaction request that cannot leave room for its instruction and response; take a defined escalation or recovery path.
For operational visibility, record the gate outcome, schema version, token estimate, compaction result, validation errors, and resume decision. Avoid logging sensitive prompt or user data. These telemetry fields are implementation guidance, not a provider-mandated schema.
Quick Recap
What to test before deploying
- A checkpoint containing every required field continues; one missing each required field is rejected.
- Unknown schema versions and malformed structured output take a defined recovery path.
- Contradictory user constraints do not pass validation as a successful continuation.
- Provider continuation material is preserved in the format and sequence required by that provider.
- Authorization is checked from trusted application state before tools cause side effects.
- Repeated compaction is tested for task correctness, latency, and token use with representative workloads rather than assumed to be harmless.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
