OpenAI Compaction API: Mantener la calidad del agente reduciendo costos de contexto

Technical Context

Analicé detenidamente la documentación de OpenAI sobre compaction en la API Responses y noté un cambio que es arquitectónicamente más importante que simplemente "más contexto". En el output posterior a una llamada aparece un ítem especial con type=compaction, que contiene un encrypted_content opaco. Según OpenAI, esto “preserva la comprensión latente del modelo” (preserves the model’s latent understanding). Para mí, esto significa que no nos dan un recuento de la historia, sino una transferencia del estado interno de comprensión en un contenedor compacto.

La diferencia práctica clave con la sumarización clásica es esta: un resumen es texto forzado a "destilar" el pasado, perdiendo casi siempre detalles, vínculos causales y acuerdos sutiles. Compaction, en cambio, intenta preservar exactamente lo que el modelo usa realmente para continuar razonando, pero lo hace en una forma que el cliente no puede interpretar ni editar.

Desde el punto de vista de la integración, hay dos caminos principales:

• Auto-gestión de contexto en /responses: configuras context_management con un compact_threshold (por ejemplo, 0.9). Cuando la ventana de contexto se acerca al límite, la plataforma puede emitir un ítem de compaction durante el stream, "recortar" la historia y continuar la generación con la representación compacta.
• Ejecución manual a través de /responses/compact: envías la entrada completa (que debe caber en el límite del modelo en el momento de la compactación) y recibes una "ventana empaquetada" para la siguiente llamada a /responses.

Lo que me llamó la atención como arquitecto: encrypted_content puede ser muy grande (la documentación menciona valores de hasta ~10M de caracteres), pero permanece opaco. No es un "ahorro de un par de líneas"; es un formato diferente para almacenar la huella del contexto. Otro punto: OpenAI destaca la compatibilidad con ZDR (Zero Data Retention), lo que suena como un intento de minimizar riesgos de almacenamiento/fugas para entornos corporativos. Sin embargo, sin revelar detalles de gestión de claves y criptografía interna, yo no prometería a los equipos de seguridad una "privacidad mágica"; simplemente lo trataría como un mecanismo gestionado por el proveedor.

También es importante entender que compaction en su modelo de mundo no está obligado a reemplazar todos los mensajes del usuario: las descripciones sugieren que el texto del usuario puede conservarse más "tal cual", mientras que las capas de assistant/tool/reasoning se empaquetan. Para sistemas agénticos, esto es lógico: la huella de herramientas y las cadenas de razonamiento son las que inflan la ventana más rápido y se rompen con mayor frecuencia con resúmenes primitivos.

Business & Automation Impact

En la práctica, casi siempre me encuentro con el mismo dolor: "el agente se vuelve más inteligente los primeros 10–20 minutos, y luego empieza a entorpecerse". La razón generalmente no es el modelo en sí, sino cómo el equipo gestiona el contexto: cortaron la historia, hicieron un resumen burdo, perdieron restricciones/objetivos/excepciones, y el agente comienza a tomar decisiones diferentes. Compaction es el intento del proveedor de solucionar precisamente esta clase de degradación.

Si diseño automatización con IA para ventas, soporte o equipos de ingeniería, compaction cambia la matemática del TCO: las sesiones largas se vuelven más predecibles en costo, y la calidad después de la "compresión" potencialmente cae menos que con la sumarización de texto. Ganan aquellos que tienen:

• diálogos de larga duración (soporte L2/L3, onboarding, compras, correspondencia de licitaciones);
• agentes intensivos en herramientas (CRM/ERP, catálogos, orquestación RPA, code-assist con muchas llamadas a herramientas);
• procesos donde la secuencia de decisiones es crítica (scripts de cumplimiento, aprobaciones, reglamentos).

Pierden aquellos que contaban con la "portabilidad universal de la historia" entre proveedores. El blob opaco es, de hecho, un vendor lock-in a nivel de memoria del agente. Si mañana quieres mudarte a otro stack de LLM, esta capa de contexto no migrará. En mis proyectos, establecería una regla simple: los artefactos originales deben almacenarse localmente (mensajes de usuario, inputs/outputs de herramientas, hechos críticos, decisiones y su justificación); de lo contrario, pierdes capacidad de gestión y auditoría.

Otro detalle de negocio: compaction no es solo "hicimos menos tokens y listo". Afecta la observabilidad. Ya no puedes leer qué es exactamente lo que el agente "recuerda" después de la compactación, lo que aumenta el papel de las pruebas, los escenarios de regresión y la telemetría de calidad. En Nahornyi AI Lab, incluiría esto en el plan de implementación de IA como una capa obligatoria: conjuntos de evaluación (evals) para intenciones clave, verificaciones de preservación de restricciones y pruebas separadas para el estado "post-compactación".

Desde una perspectiva arquitectónica, veo un patrón práctico: compaction es la "memoria rápida" del proveedor, mientras que el cliente conserva la "memoria a largo plazo" en forma estructurada (hechos/decisiones/restricciones) y almacenamiento primario para auditoría. En este esquema, compaction da velocidad y estabilidad, y tu entorno da control.

Strategic Vision & Deep Dive

Mi pronóstico: el mercado de plataformas de agentes pasará de discutir "qué resumen es mejor" a "qué memoria es mejor". Compaction es un paso hacia la memoria gestionada en el lado del modelo, donde el proveedor optimiza la transferencia de estado tal como optimiza la inferencia. Y es una jugada fuerte: elimina la necesidad de que los equipos inventen su propio algoritmo de compresión de diálogos, que casi siempre resulta frágil.

Pero no compro esto como una solución universal. En los proyectos de Nahornyi AI Lab, veo regularmente dos clases de requisitos que compaction no cubre:

• Explicabilidad: El negocio a menudo necesita entender por qué el agente llegó a una decisión. Un blob opaco no ayudará. Por lo tanto, sigo registrando decisiones críticas en logs legibles: "qué hechos se usaron", "qué reglas se activaron", "qué devolvió la herramienta".
• Olvido Gestionado: A veces necesitas garantizar que parte del contexto se "borre" (PII, secreto comercial, instrucción errónea). Cuando la memoria es opaca, tienes que construir una política: qué no se permite en el contexto en absoluto, qué pasa por redacción antes de enviarse, y cómo funcionan la retención/eliminación en tu lado.

Yo usaría compaction como un mecanismo para estabilizar el razonamiento del agente, pero no como la única fuente de verdad. La arquitectura de soluciones de IA real en producción es un pastel en capas: log de eventos, "hechos" estructurados, RAG sobre datos corporativos, reglas de seguridad, y solo sobre esto, la capa conversacional que puede compactarse.

Y hay otra trampa en la que es fácil caer: "como todo se guarda de forma latente, no hace falta pensar en el contexto". Falso. Si alimentas al modelo con basura (duplicados, contradicciones, rastros de herramientas innecesarios), corres el riesgo de conservar esta basura en una forma más resistente. El beneficio de compaction se revela cuando antes de él ya has establecido una disciplina de mensajes normal, tipificación de resultados de herramientas y minimización de ruido.

En el futuro habrá menos hype sobre "ventanas gigantes" y más ingeniería sobre memoria, control y costo. Compaction es una herramienta poderosa, pero ganan quienes la implementan como parte del sistema, y no como una casilla en el SDK.

Si estás construyendo un agente de larga duración o quieres hacer automatización con IA sin descontrolar el presupuesto, te invito a discutir la arquitectura y el plan de pruebas para tu proceso. Escribe a Nahornyi AI Lab; yo, Vadym Nahornyi, realizaré la consulta personalmente y propondré un esquema de implementación considerando calidad, seguridad y portabilidad futura.