Apple propone SelfCompact: el agente decide por sí mismo cuándo comprimir el contexto

Investigadores de Apple ML Research han propuesto SelfCompact, un marco para agentes basados en LLM en el que el propio modelo elige cuándo y cómo comprimir el historial acumulado. El diseño se apoya en dos elementos que operan en la fase de inferencia. El primero es una herramienta de compactación que el modelo invoca para resumir el contexto acumulado.

En lugar de la regla rígida de «comprimir al llegar a N tokens», la decisión la toma el agente. El fragmento del resumen al que tenemos acceso se corta en la descripción del primer elemento. El segundo elemento y los resultados numéricos no aparecen en él, por lo que de momento no es posible evaluar la eficacia del método con cifras.

El problema: un contexto que estorba al razonamiento

Las trayectorias largas de los agentes se componen de cadenas de razonamiento y llamadas a herramientas. Con el tiempo, acumulan contenido obsoleto: hipótesis intermedias, opciones descartadas, respuestas de búsqueda voluminosas. Los autores señalan dos consecuencias. En primer lugar, esa cola «ancla» las generaciones posteriores: el modelo sigue apoyándose en lo que ya ha perdido vigencia. En segundo lugar, tarde o temprano la trayectoria desborda la ventana de contexto.

La práctica actual es la siguiente: el marco cuenta tokens y, al alcanzar un umbral, lanza la compresión a intervalos regulares. Es fácil de implementar, pero el enfoque tiene un punto débil: el disparador no ve la estructura de la tarea. El umbral puede saltar en mitad de una deducción matemática o de una búsqueda de varios pasos, y un resultado parcial que aún no se ha consolidado en una conclusión puede quedar sacrificado o perder detalles importantes.

Qué cambia SelfCompact

La idea es entregar la decisión a quien mejor conoce el estado del razonamiento: el propio modelo. El modelo recibe una herramienta de compactación y la llama igual que una búsqueda o un intérprete de código. El agente puede terminar una subtarea, fijar la conclusión y solo entonces comprimir el historial. También determina por sí mismo el contenido del resumen: qué hechos conservar y qué pasos intermedios dar por cerrados.

De la expresión «inference-time elements» se deduce que se trata de una capa añadida sobre el modelo, y no de un cambio en su arquitectura. El texto disponible no lo dice de forma explícita, así que no puede darse por confirmado. Si fuera así, el método podría probarse con modelos existentes sin reentrenamiento.

Qué se sabe a partir de la fuente

• Autor: Apple ML Research, publicación del 12 de octubre de 2026.
• Nombre del método: SelfCompact.
• Esquema base de comparación: compactación a intervalo fijo según un umbral de tokens.
• Composición del método: dos elementos en la fase de inferencia; el primero es una herramienta de compresión que invoca el modelo.
• El fragmento disponible no incluye benchmarks, tamaños de modelo, mejoras de precisión ni ahorro de tokens.

Cómo aplicarlo en la práctica

Mientras no se disponga del texto completo, conviene tratar SelfCompact como una hipótesis que se puede poner a prueba. Los equipos que construyen agentes de larga duración para programación, investigación o soporte deberían hacer varias cosas.

Primero: revisar los logs de sus agentes y localizar los casos en que la compresión por umbral saltó en un mal momento. Las señales son estas: el agente repite una búsqueda ya hecha, pierde un resultado intermedio o vuelve a una hipótesis descartada. Si hay muchos casos así, el tema les afecta.

Segundo: montar un experimento pequeño. Darle al modelo una herramienta de compresión con una instrucción clara sobre cuándo usarla y compararla con el disparador actual sobre el mismo conjunto de tareas. Las métricas son evidentes: la proporción de tareas completadas con éxito, el número de tokens por tarea y la cantidad de pasos repetidos.

Tercero: prever salvaguardas ante un mal comportamiento. El modelo puede comprimir con demasiada frecuencia o, al contrario, no comprimir nunca hasta que la ventana se desborde. Es sensato mantener un umbral rígido como red de seguridad y tratar la decisión del modelo como el mecanismo principal.

El trabajo importa porque traslada la gestión de la memoria del agente desde la capa de infraestructura al ámbito de responsabilidad del propio modelo. Hasta qué punto funciona se sabrá cuando se publiquen los resultados completos y la comparación con los esquemas por intervalos en tareas largas.