Después de una sesión larga, el agente puede seguir recordando el objetivo general y olvidar el archivo exacto que estaba modificando. También puede recuperar una decisión descartada, repetir una investigación o actuar con una aprobación que ya no es válida.

Ese es el límite de la compactación de contexto. Reduce el historial que se envía al modelo, pero el resumen no debe convertirse en la fuente de verdad de la tarea. La aplicación necesita guardar el estado operativo por separado, compactar la conversación con una instrucción clara y verificar el resultado antes de liberar la siguiente acción.

Este artículo complementa la guía de ingeniería de contexto para coding agents. Allí la pregunta es qué evidencia debe entrar en el contexto. Aquí la pregunta es qué debe sobrevivir cuando se reescribe el historial. El código es ilustrativo y no se ejecutó contra un proveedor.

Diagrama que muestra el historial comprimido mientras el estado de la tarea se conserva y se verifica antes de que el agente continúe.

Respuesta corta

  • Trata el historial de la conversación como material resumible, no como el registro oficial de la tarea.
  • Persiste la intención, el paso actual, las decisiones, las aprobaciones, los efectos externos y la siguiente acción fuera del resumen.
  • Conserva referencias a archivos y artefactos en lugar de transportar logs enormes por seguridad.
  • Valida la versión, los permisos y las invariantes después de compactar antes de ejecutar otra tool call.

¿Qué conserva la compactación de contexto y qué puede perder?

La compactación reemplaza muchos mensajes por una representación más pequeña. Normalmente conserva el objetivo y una narración del progreso, pero puede perder detalles que parecían secundarios cuando se creó el resumen. El límite seguro no es "resumir o nunca resumir". Consiste en decidir qué hechos requieren fidelidad exacta.

En 2026, la documentación de Anthropic describe una compactación que detecta un límite de tokens, crea un bloque de resumen y continúa la conversación desde él (Anthropic, "Compaction", 2026). La configuración documentada usa input_tokens como disparador, con un valor predeterminado de 150.000 tokens y un mínimo de 50.000. Ese límite pertenece a la función de Anthropic, no a todos los agentes.

Una implementación útil separa tres clases:

Material ¿Se puede resumir? Qué debe permanecer exacto
Conversación y explicaciones repetidas Sí La conclusión que cambió una decisión
Resultado bruto de una herramienta Normalmente Referencia, estado y hecho que se usará después
Plan y decisiones de arquitectura Con cuidado Decisión actual y motivo para rechazar alternativas
Aprobación humana No Quién aprobó, qué acción y hasta cuándo
Efecto externo No Identificador, estado observado y siguiente acción permitida

El resumen puede decir que se investigó un archivo. El estado de la tarea debe decir cuál archivo, qué hipótesis sigue siendo válida y qué prueba falta. Esa diferencia evita que una frase plausible del modelo reemplace un hecho que el runtime puede verificar.

El error de diseño consiste en usar una representación para dos necesidades distintas. La conversación debe ser corta para la siguiente inferencia. El estado debe ser preciso para autorizar la siguiente transición. Un resumen excelente para leer puede ser insuficiente para realizar una escritura.

¿Qué estado debe quedar fuera del resumen?

Mantén fuera del historial compactado todo lo que cambie el permiso para actuar. Un registro mínimo debe permitir que un nuevo turno responda cinco preguntas: cuál es la intención, dónde está la tarea, qué se decidió, qué efecto externo existe y qué paso está permitido ahora.

Una representación independiente del proveedor podría verse así:

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 es más útil que una frase como "continúa el trabajo". El agente necesita un verbo que el ejecutor entienda y una política que pueda rechazar. Si el estado dice ask_human, la siguiente llamada no debe modificar un archivo solo porque el resumen suena seguro.

stateVersion también importa. Si una compactación retrasada sobrescribe un registro más nuevo, el runtime debe rechazar la escritura antigua. La persistencia puede ser una fila de base de datos, un documento versionado o un archivo controlado por el proceso. El requisito es tener concurrencia explícita y suficiente historial para investigar el reemplazo.

El OpenAI Agents SDK documenta sesiones persistentes y modos de compactación que pueden usar la cadena de respuestas o reconstruir una solicitud a partir de los elementos actuales (OpenAI Agents SDK, "Sessions", 2026). Esa elección cambia de dónde sale el historial enviado al modelo. No elimina la necesidad de una fuente de verdad para el estado de la aplicación.

¿Cuándo conviene resumir, limpiar resultados o iniciar otro contexto?

Usa la compactación cuando la tarea sigue siendo un hilo continuo y el agente necesita el contexto reciente para tomar la siguiente decisión. Limpia resultados cuando la salida bruta ya cumplió su función y puede recuperarse mediante una referencia. Inicia otro contexto cuando la tarea cambió, el historial quedó contaminado o el siguiente paso necesita una revisión independiente.

Situación Opción más segura Estado que cruza la frontera
Continúa la misma tarea y creció el historial Compactar Estado versionado y artefactos relevantes
Ya se procesó un resultado enorme Limpiar o sustituir por una referencia Resumen del resultado, ID y ubicación recuperable
La tarea se convirtió en otra tarea Iniciar otro contexto Nuevo objetivo vinculado al trabajo anterior
Hay una aprobación humana pendiente Pausar o pedir una decisión Solicitud, alcance, aprobador y vencimiento
El efecto externo es incierto Reconciliar antes de compactar o actuar ID de acción y estado unknown

La función nativa de OpenAI envía una representación compactada y permite configurar cuándo ocurre la compactación (OpenAI, "From model to agent: Equipping the Responses API with a computer environment", 2026). El Agents SDK también indica que la compactación automática puede alargar una ejecución en streaming porque el runtime espera a que termine antes de cerrar el turno. Por eso conviene tratarla como una transición observable, no como un detalle invisible.

No compactes en cada turno sin medir el resultado. Reescribir el prefijo puede invalidar una caché, consumir tiempo y eliminar evidencia que todavía no registraste. El disparador debe considerar espacio para la siguiente respuesta, los resultados de herramientas y el estado que acompaña a la solicitud.

¿Cómo preparar una compactación sin perder el siguiente paso?

Prepara la compactación en dos fases. Primero, consolida el estado operativo en almacenamiento duradero. Después, produce el resumen con una lista explícita de lo que debe llevar al siguiente turno. Si la primera fase falla, no compactes y no dejes que el agente continúe como si el estado fuera seguro.

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"),
  };
}

Este helper no implementa la compactación de ningún proveedor. Muestra el orden del contrato: guardar la versión, construir la instrucción, compactar y adjuntar el resultado a la siguiente solicitud. En una implementación real, trata la respuesta de compactación como una operación que puede fallar, retrasarse o devolver contenido vacío.

Después de compactar, compara el estado recibido con el estado persistido. No aceptes un resumen que cambie nextAction, elimine una aprobación vigente o transforme unknown en confirmed. La compactación puede proponer un resumen. La aplicación decide si basta para continuar.

¿Cómo manejar resultados grandes de tools y artefactos?

Conserva la conclusión operativa y elimina el volumen que no necesita viajar en cada turno. Para una prueba, puede ser el comando, el estado, el fallo principal y el archivo afectado. Para leer código, puede ser la ruta, la función relevante y una huella del contenido inspeccionado.

El archivo u objeto original debe seguir siendo recuperable cuando la siguiente decisión dependa de él. Una referencia sin control de acceso no es memoria segura. Registra quién puede obtener el artefacto, qué versión se usó y cuándo puede reemplazarse.

El paper Context Compaction Theory, de Tirmazi, Markelon, Bishop y Mitzenmacher, formaliza la compactación como la selección o generación de un mensaje menor para necesidades futuras. La implicación práctica es sencilla: un resumen puede conservar bien aquello que el sistema sabe que se preguntará después. Cuando las preguntas futuras son abiertas, las referencias externas y las invariantes explícitas reducen el riesgo de pérdida.

No pongas secretos, prompts completos ni logs brutos en el resumen porque parecen útiles. Eso aumenta el coste y mezcla material confiable con datos que pueden venir de una tool. El estado debe transportar solo lo necesario para autorizar y verificar la siguiente acción.

¿Cómo verificar la tarea después de compactar?

Haz que la reanudación falle de forma explícita cuando el estado no cumpla invariantes sencillas. La verificación debe ocurrir antes de la siguiente escritura, llamada externa o aprobación automática. Un resumen legible no demuestra que las referencias y los permisos sigan siendo válidos.

Comprueba al menos:

  1. runId y stateVersion pertenecen a la ejecución actual.
  2. El objetivo no cambió de forma silenciosa.
  3. currentStep apunta a un estado conocido del workflow.
  4. nextAction es compatible con las aprobaciones vigentes.
  5. Cada efecto externo tiene un estado y un identificador coherentes.
  6. Las referencias a archivos y artefactos apuntan a una versión permitida.
  7. El resumen no es la única evidencia de una prueba, escritura o aprobación.
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");
  }
}

Esta política es ilustrativa. Una aplicación puede permitir ediciones sin aprobación o usar otro modelo de autorización. La prueba importante es que cada combinación permitida esté documentada y que los estados desconocidos no se conviertan en éxito por comodidad.

La mejor prueba de compactación no pregunta si el resumen "parece bueno". Restaura un caso guardado y comprueba que el agente sigue sin permiso para hacer aquello que no se ha demostrado. La calidad de la compactación aparece en las decisiones que impide, no solo en el texto que produce.

¿Cuándo es mejor no compactar?

No compactes en medio de una mutación externa sin registrar su resultado. Si un cobro, una migración, una publicación o un mensaje pudo aceptarse, reconcilia primero el efecto. Un resumen no convierte una operación ambigua en una operación segura.

Prefiere una frontera de pausa cuando una persona debe decidir, cambia el responsable o el contexto contiene instrucciones en conflicto. La guía para pausar y reanudar un agente sin reiniciarlo cubre el checkpoint que atraviesa esa interrupción. La guía de ejecución durable para agentes de IA trata la elección entre una cola y un workflow.

Si el agente vuelve a abrir la misma investigación, compactar antes puede ocultar el problema. Registra la repetición, comprueba la señal de progreso y considera iniciar un paso nuevo con una entrada menor. Un contexto pequeño ayuda, pero no arregla una tarea sin regla de finalización.

Checklist de compactación para un agente de larga duración

Revisa esta secuencia antes de activar la compactación automática:

  1. Define qué parte del historial es conversación y cuál es estado operativo.
  2. Persiste la intención, el paso, las decisiones, las aprobaciones, los efectos y la siguiente acción.
  3. Versiona el estado y rechaza escrituras retrasadas.
  4. Convierte los resultados grandes de tools en conclusiones y referencias recuperables.
  5. Declara qué puede omitir el resumen y qué nunca debe inventar.
  6. Registra el inicio, el final, el motivo y el fallo de cada compactación.
  7. Valida el estado antes de la siguiente tool call con efecto externo.
  8. Prueba un contexto lleno, un resumen vacío, un estado obsoleto, una aprobación vencida y un efecto externo desconocido.
  9. Usa una sesión nueva cuando cambien la tarea, el responsable o la frontera de confianza.
  10. Mantén el historial completo disponible para auditoría aunque el modelo reciba solo una proyección compactada.

Preguntas frecuentes

¿La compactación garantiza que un agente no olvidará nada?

No. Crea una representación menor del historial y puede perder detalles. La tarea debe persistir fuera del resumen los hechos que autorizan una acción, incluidas las decisiones, las aprobaciones, los efectos externos y la siguiente acción. Usa invariantes y pruebas de reanudación para detectar la pérdida antes de continuar.

¿Debo conservar toda la conversación en el contexto del siguiente turno?

No necesariamente. La conversación completa puede aumentar el coste y dificultar la recuperación de las señales importantes. Conserva el historial completo en almacenamiento para auditoría, envía una proyección compactada al modelo y recupera resultados o artefactos por referencia cuando la siguiente decisión necesite detalles.

¿La compactación y el checkpoint son lo mismo?

No. La compactación reduce la representación que se envía al modelo. Un checkpoint registra el estado de ejecución que debe sobrevivir a una interrupción. Pueden ocurrir juntos, pero un resumen de conversación no sustituye un checkpoint con versión, permisos, efectos y siguiente acción.

¿Qué umbral de tokens debo usar?

No existe un valor universal. El umbral depende del modelo, las herramientas, el espacio reservado para la respuesta, el comportamiento de la caché y el tamaño del estado que acompaña cada solicitud. Empieza con el contrato del proveedor, mide tu runtime y reserva espacio para la siguiente respuesta. No copies el disparador de otro agente sin probarlo.

Conclusión

La compactación de contexto resuelve un problema de tamaño. No resuelve por sí sola la continuidad. El historial puede resumirse, mientras que la intención, las decisiones, las aprobaciones, los efectos externos y la siguiente acción deben seguir siendo verificables en otra fuente.

La secuencia segura es clara: persiste el estado, compacta la conversación, valida la versión resultante y solo después deja actuar al agente. Si la validación falla, pausa, reconcilia o inicia un paso nuevo. Un resumen menor es útil. Un estado operativo que nadie puede probar no lo es.

Nota de producción

Samuel Fajreldines es el responsable editorial de este artículo. La investigación combinó documentación oficial de OpenAI, Anthropic y OpenAI Agents SDK con un paper primario sobre teoría de compactación y discusiones públicas recientes. El código es ilustrativo y no se ejecutó contra un proveedor. La asistencia de IA ayudó a organizar fuentes, redactar, localizar, generar la imagen y revisar la consistencia; no proporcionó una prueba de producción ni un benchmark propio. Para organizar sesiones largas de agentes, uso RemoteCode, una herramienta mía, sin presentarla como evidencia de rendimiento.

Fuentes consultadas