After a long session, an agent may still know the broad goal and forget the exact file it was changing. It may recover a rejected decision, repeat an investigation, or act on an approval that is no longer valid.

That is the boundary of context compaction. It reduces the history sent to the model, but the summary should not become the task's source of truth. The application needs to store operational state separately, compact the conversation with a clear instruction, and verify the result before releasing the next action.

This article complements the guide to context engineering for coding agents. That article asks which evidence belongs in context. This one asks what must survive when history is rewritten. The code is illustrative and was not run against a provider.

Diagram showing conversation history compressed while task state is preserved and verified before an agent continues.

Short answer

  • Treat conversation history as summarizable material, not the official task record.
  • Persist intent, current step, decisions, approvals, external effects, and next action outside the summary.
  • Keep references to files and artifacts instead of carrying huge logs for safety.
  • Validate version, permissions, and invariants after compaction before running another tool call.

What does context compaction preserve, and what can it lose?

Compaction replaces many messages with a smaller representation. It usually keeps the goal and a progress narrative, but it can lose details that seemed secondary when the summary was created. The safe boundary is not "summarize or never summarize." It is deciding which facts require exact fidelity.

In 2026, Anthropic's documentation describes compaction that detects a token limit, creates a summary block, and continues the conversation from it (Anthropic, "Compaction", 2026). The documented configuration uses input_tokens as its trigger, with a default value of 150,000 tokens and a minimum of 50,000. That limit belongs to Anthropic's feature, not every agent.

A useful implementation separates three classes:

Material Can it be summarized? What must remain exact
Repeated conversation and explanations Yes The conclusion that changed a decision
Raw tool output Usually Reference, status, and fact needed later
Architecture plan and decisions Carefully Current decision and reason for rejecting alternatives
Human approval No Who approved, which action, and until when
External effect No Identifier, observed state, and next allowed action

The summary can say that a file was investigated. Task state must say which file, which hypothesis is still valid, and which test remains. That difference keeps a plausible model sentence from replacing a fact the runtime can verify.

The design mistake is using one representation for two different needs. Conversation should be short for the next inference. State should be precise enough to authorize the next transition. A summary that is excellent for reading can still be insufficient for a write.

Which state should live outside the summary?

Keep anything that changes permission to act outside the compacted history. A minimal state record should let a new turn answer five questions: what is the intent, where is the task, what has been decided, which external effect exists, and what step is allowed now.

A provider-neutral representation could look like this:

type TaskState = {
  runId: string;
  stateVersion: number;
  objective: string;
  currentStep: string;
  nextAction: "inspect" | "edit" | "test" | "ask_human" | "stop";
  decisions: Array<{ summary: string; reason: string }>;
  approvals: Array<{
    scope: string;
    approvedBy: string;
    expiresAt?: string;
  }>;
  effects: Array<{
    actionId: string;
    status: "none" | "confirmed" | "unknown";
    externalId?: string;
  }>;
  artifactRefs: string[];
  updatedAt: string;
};

nextAction is more useful than a sentence such as "continue the work." The agent needs a verb the executor understands and a policy it can refuse. If state says ask_human, the next call should not edit a file because the summary sounds confident.

stateVersion matters too. If a delayed compaction overwrites a newer record, the runtime must reject the older write. Persistence could be a database row, a versioned document, or a file controlled by the process. The requirement is explicit concurrency and enough history to investigate the replacement.

The OpenAI Agents SDK documents persistent sessions and compaction modes that can use the response chain or rebuild a request from current items (OpenAI Agents SDK, "Sessions", 2026). That choice changes where the history sent to the model comes from. It does not remove the need for a source of truth for application state.

When should you summarize, clear results, or start a new context?

Use compaction when the task is still one continuous thread and the agent needs recent context for the next decision. Clear results when raw output has done its job and can be recovered through a reference. Start a new context when the task changed, the history is contaminated, or the next step needs an independent review.

Situation Safer choice State that crosses the boundary
The same task continues and history grew Compact Versioned state and relevant artifacts
A huge result was already processed Clear or replace with a reference Result summary, ID, and recoverable location
The task became a different task Start a new context New objective linked to prior work
A human approval is pending Pause or ask for a decision Request, scope, approver, and expiry
An external effect is uncertain Reconcile before compacting or acting Action ID and unknown state

OpenAI's native feature sends a compacted representation and lets the application configure when compaction occurs (OpenAI, "From model to agent: Equipping the Responses API with a computer environment", 2026). The Agents SDK also notes that automatic compaction can extend a streaming run because the runtime waits for the operation before closing the turn. That is a reason to treat compaction as an observable transition, not an invisible detail.

Do not compact every turn without measuring the result. Rewriting the prefix can invalidate a cache, consume time, and remove evidence you have not recorded yet. The trigger should account for room reserved for the next response, tool results, and the state attached to the request.

How do you prepare compaction without losing the next action?

Prepare compaction in two phases. First, consolidate operational state in durable storage. Then produce the summary with an explicit list of what it must carry forward. If the first phase fails, do not compact and do not let the agent continue as if the state were safe.

type CompactionInput = {
  history: unknown[];
  state: TaskState;
};

async function prepareCompaction(input: CompactionInput) {
  const saved = await stateStore.compareAndSet(
    input.state.runId,
    input.state.stateVersion,
    input.state,
  );

  if (!saved) {
    throw new Error("task state changed before compaction");
  }

  return {
    history: input.history,
    instruction: [
      "Summarize conversation history for the next turn.",
      "Do not invent decisions, approvals, tool effects, or test results.",
      "The durable task state is authoritative for permissions and nextAction.",
      `State version: ${input.state.stateVersion}`,
      `Next action: ${input.state.nextAction}`,
    ].join("\n"),
  };
}

This helper does not implement any provider's compaction. It shows the order of the contract: save the version, build the instruction, compact, and attach the result to the next request. In a real implementation, treat the compaction response as an operation that can fail, delay, or return empty content.

After compaction, compare the returned state with the persisted state. Do not accept a summary that changes nextAction, removes a current approval, or turns unknown into confirmed. Compaction can propose a summary. The application decides whether it is enough to continue.

How should you handle large tool results and artifacts?

Keep the operational conclusion and remove volume that does not need to travel on every turn. For a test, that might be the command, status, main failure, and affected file. For a code reading, it might be the path, relevant function, and fingerprint of the content that was inspected.

The original file or object should remain recoverable when the next decision depends on it. A reference without access control is not safe memory. Record who can fetch the artifact, which version was used, and when it may be replaced.

The paper Context Compaction Theory, by Tirmazi, Markelon, Bishop, and Mitzenmacher, formalizes compaction as selecting or generating a smaller message for future needs. The practical implication is simple: a summary can preserve well what the system knows will be asked later. When future questions are open ended, external references and explicit invariants reduce the chance of loss.

Do not put secrets, full prompts, or raw logs in the summary because they seem useful. That increases cost and mixes trusted material with data that may have come from a tool. State should carry only what is needed to authorize and verify the next action.

How do you verify the task after compaction?

Make resume fail explicitly when state does not pass simple invariants. Verification belongs before the next write, external call, or automatic approval. A readable summary does not prove that references and permissions are still valid.

Check at least:

  1. runId and stateVersion belong to the current execution.
  2. The objective did not change silently.
  3. currentStep points to a known workflow state.
  4. nextAction is compatible with current approvals.
  5. Each external effect has a coherent status and identifier.
  6. File and artifact references still point to an allowed version.
  7. The summary is not the only evidence for a test, write, or approval.
function assertResumable(state: TaskState) {
  if (!state.runId || state.stateVersion < 1) {
    throw new Error("invalid task identity");
  }

  if (state.nextAction === "edit" && state.approvals.length === 0) {
    throw new Error("edit requires a current approval");
  }

  if (state.effects.some((effect) => effect.status === "unknown")) {
    throw new Error("reconcile unknown external effects first");
  }
}

This policy is illustrative. An application may allow edits without approval or use another authorization model. The important test is that every allowed combination is documented and unknown states are not converted into success for convenience.

The best compaction test does not ask whether the summary "looks good." It restores a saved case and checks that the agent is still forbidden from doing what has not been proven. Compaction quality appears in the decisions it prevents, not only in the text it produces.

When is compaction the wrong choice?

Do not compact in the middle of an external mutation without recording its result. If a charge, migration, publication, or message may have been accepted, reconcile the effect first. A summary cannot turn an ambiguous operation into a safe operation.

Prefer a pause boundary when a person must decide, ownership changes, or the context contains conflicting instructions. The guide to pausing and resuming an agent without restarting covers the checkpoint that crosses this interruption. The guide to durable execution for AI agents covers the choice between a queue and a workflow.

If the agent keeps reopening the same investigation, earlier compaction may hide the problem. Record the repetition, check the progress signal, and consider starting a new step with a smaller input. Smaller context helps, but it does not fix a task with no completion rule.

Context compaction checklist for a long-running agent

Review this sequence before enabling automatic compaction:

  1. Define which part of history is conversation and which part is operational state.
  2. Persist intent, step, decisions, approvals, effects, and next action.
  3. Version the state and reject delayed writes.
  4. Turn large tool results into conclusions and recoverable references.
  5. State what the summary may omit and what it must never invent.
  6. Record the start, end, reason, and failure of every compaction.
  7. Validate state before the next tool call with an external effect.
  8. Test a full context, empty summary, stale state, expired approval, and unknown external effect.
  9. Use a new session when the task, owner, or trust boundary changes.
  10. Keep full history available for audit even when the model receives only a compacted projection.

Frequently asked questions

Does compaction guarantee that an agent will not forget anything?

No. It creates a smaller representation of history and can lose details. The task should persist facts that authorize an action outside the summary, including decisions, approvals, external effects, and next action. Use invariants and resume tests to detect loss before the agent continues.

Should I keep the entire conversation in the next turn's context?

Not necessarily. The full conversation can increase cost and make important signals harder to recover. Keep full history in storage for audit, send a compacted projection to the model, and retrieve tool results or artifacts by reference when the next decision needs detail.

Are compaction and checkpointing the same thing?

No. Compaction reduces the representation sent to the model. A checkpoint records execution state that must survive an interruption. They can happen together, but a conversation summary does not replace a checkpoint with version, permissions, effects, and next action.

What token threshold should I use?

There is no universal value. The threshold depends on the model, tools, reserved response space, cache behavior, and state size attached to each request. Start with the provider contract, measure your runtime, and reserve room for the next response. Do not copy another agent's trigger without testing it.

Conclusion

Context compaction solves a size problem. It does not solve continuity by itself. History can be summarized, while intent, decisions, approvals, external effects, and next action must remain verifiable in another source.

The safe sequence is clear: persist state, compact conversation, validate the resulting version, and only then let the agent act. When validation fails, pause, reconcile, or start a new step. A smaller summary is useful. An operational state that nobody can prove is not.

Production note

Samuel Fajreldines is responsible for this article. The research combined official OpenAI, Anthropic, and OpenAI Agents SDK documentation with a primary paper on compaction theory and recent public discussions. The code is illustrative and was not run against a provider. AI assistance helped organize sources, draft, localize, generate the image, and review consistency; it did not provide a production test or original benchmark. To organize long agent sessions, I use RemoteCode, my own tool, without presenting it as performance evidence.

Sources consulted