El agente tacha por sí mismo las respuestas antiguas de las herramientas y reduce a la mitad los tokens de entrada

Un agente que recorre herramientas acumula historial rápidamente: logs, volcados, salidas de comandos, contenido de archivos. En cada una de esas respuestas, lo útil suele ser un orden de magnitud menor que la respuesta entera, pero esta se sigue arrastrando en todas las solicitudes posteriores. Los autores de un preprint en arXiv proponen encargar la limpieza al propio modelo. En el caso de investigación, el prompt final con este enfoque fue de 231 951 tokens frente a 912 492 con el almacenamiento habitual del historial. El volumen total de entrada cayó un 50 % y la estimación del coste de la API bajó a entre $1,28 y $1,44, en lugar de unos $4,38.

Cómo funciona el olvido

La mecánica es sencilla. El modelo en ejecución elige resultados de llamadas a herramientas obtenidos antes y sustituye cada uno por una nota breve, justo en su posición original dentro del diálogo. El orden de los mensajes y la estructura del historial no se rompen. El original exacto no se elimina, sino que pasa a un archivo, del que se puede recuperar con una orden explícita si vuelve a hacer falta.

El enfoque está implementado como un envoltorio (harness) en Python que da al agente dos acciones: archivado por lotes y restauración. No hace falta reentrenar el modelo para la tarea. También hay una salvaguarda: las instrucciones del usuario y los mensajes del asistente quedan fuera de estas operaciones. Solo se pueden olvidar observaciones, no lo que pidió la persona ni lo que el propio agente dijo de sí mismo.

Qué mostraron los experimentos

El caso principal es de investigación: una depuración con OpenTelemetry, seguida de una tarea de implementación sin relación. Es justo el tipo de trayectoria ruidosa en la que las salidas voluminosas se necesitan durante un par de pasos y después solo estorban.

• Prompt final: 231 951 tokens frente a 912 492 con el historial conservado.
• Tokens de entrada totales: un 50% menos.
• Estimación del coste de la API: $1,28–1,44 frente a unos $4,38.
• Prueba de comportamiento: ambas variantes superaron el oráculo principal de dos casos.
• Evaluación de seguimiento (follow-up): ninguna variante la satisfizo por completo.
• Costes: más solicitudes y un 17% más de tiempo de ejecución.

Ahorrar tokens no equivale a ahorrar en todo. El agente gasta pasos en el propio proceso de curación, y eso se nota en el tiempo.

Dónde no funcionó el método

Los autores presentan los contraejemplos con honestidad. En un par de contraste relacionado con el desarrollo de una aplicación, no hubo ahorro ni en contexto ni en coste. Un experimento anterior con continuación de sesión mostró una calidad menor según la evaluación manual, aunque el contexto se redujo. La muestra es pequeña, los casos son exploratorios y no hay estadística. El trabajo no demuestra que la técnica sirva en todas partes. Muestra que la ganancia depende mucho del carácter de la carga, y los autores señalan esa dependencia como el factor central para la gestión reversible del contexto.

Qué probar en la práctica

Si tiene un agente con sesiones largas de depuración, análisis de logs o búsqueda en resultados voluminosos, la idea merece un experimento. Empiece por las observaciones que se recuperan con facilidad: salidas de tests, trazas, volcados. Deje intactas las instrucciones y los mensajes del asistente, como en el esquema original.

Mida no solo los tokens, sino también el número de solicitudes, el tiempo y la calidad del resultado en sus propias tareas, porque el ahorro puede ser aparente. En tareas donde cada fragmento de código o de configuración se vuelve a necesitar una y otra vez, el archivado puede no aportar nada. La reversibilidad es aquí una red de seguridad, no una garantía: si el agente olvidó lo que no debía, tendrá que darse cuenta y volver a pedirlo.