Tu agente de IA lo olvida todo: los trucos de MCP que arreglan la hinchazón del contexto

El problema que nadie anuncia

Toda demo de un agente de programación con IA muestra lo mismo: una terminal limpia, una instrucción clara y un resultado ordenado. Nadie te muestra la tercera hora, cuando el agente ya leyó cuarenta archivos, ejecutó una docena de suites de pruebas y llenó su context window con la salida ruidosa de cada comando que ha ejecutado. En ese punto el agente no se vuelve más listo. Se vuelve más torpe, olvidadizo y propenso a repetir con confianza un trabajo que ya terminó.

Este es el problema menos glamuroso y más universal de la programación agéntica. El contexto es la memoria de trabajo del agente, y es finita. Todo lo que el agente lee compite por el mismo espacio, y la mayor parte de lo que lee es basura: registros de compilación, trazas de pila, listados de directorios, el texto completo de archivos de los que solo necesitaba una línea. La ventana se llena de sedimento, y el razonamiento que hacía útil al agente al principio queda desplazado.

Las herramientas que arreglan esto no son las que ganan las comparativas de benchmarks. Son fontanería. Y en octubre, la fontanería fue lo que subió a la lista de tendencias de GitHub.

La idea detrás del sandboxing de salidas de herramientas

Uno de los proyectos más interesantes que han aparecido es una capa de optimización de contexto para agentes de programación que ataca el problema en su origen. Su cifra estrella es una reducción de alrededor del 98 por ciento en el volumen de salida de herramientas que llega al modelo.

El mecanismo es sencillo en concepto. En lugar de dejar que la salida en bruto de un comando se vierta directo en la conversación, lo ejecutas en un sandbox y le entregas al modelo solo lo que necesita del resultado: un resumen, un estado de salida, las líneas concretas que coincidieron con una consulta. La transcripción completa sigue disponible para que el modelo la busque a propósito, pero no ocupa la ventana por si acaso resulta relevante.

Es la misma disciplina que un buen ingeniero aplica por costumbre. No pegas un registro entero en un chat cuando una sola línea de error es el punto. Los agentes, dejados a su aire, hacen exactamente lo contrario.

Esto trae una factura, y por eso el tooling no es un simple refinamiento de ingeniería. Un context window no es gratis. Cada token que el modelo tiene que procesar cuesta dinero y tiempo, y cada token que tiene que recordar cuesta atención. Una herramienta que vuelca cien mil tokens de salida de compilación en una sesión te cobra dos veces: una por los tokens y otra por la degradación del criterio del modelo cuando la señal queda enterrada. La reducción del 98 por ciento es en realidad una corrección de calidad disfrazada de ahorro.

Una memoria que sobrevive a la sesión

La otra mitad del problema es que los agentes olvidan entre sesiones, no solo dentro de ellas. Cierras la terminal y el contexto desaparece. La vuelves a abrir mañana y el agente no tiene idea de qué decidiste, qué enfoque rechazaste ni por qué el código es como es. Vuelves a explicar, el agente vuelve a deducir, y en algún punto una decisión se toma dos veces.

Las herramientas de memoria persistente de este campo adoptan enfoques distintos. Una de las más visibles captura lo que hace el agente durante una sesión, lo comprime con un modelo e inyecta las partes relevantes en sesiones futuras. El discurso no es glamuroso y es correcto: un agente que recuerda la forma de tu proyecto vale más que un agente marginalmente más listo en una sola tarea. Los principales proveedores de modelos se han movido en la misma dirección, añadiendo ajustes que permiten a un subagent compactar su propio contexto antes que la conversación padre, precisamente para no arrastrar toda la historia de la sesión a una tarea que no necesita nada de ella.

La pregunta de diseño interesante aquí es qué recordar. Recuérdalo todo y habrás reconstruido el problema original en una forma más lenta. Recuerda demasiado poco y la memoria es inútil. Los proyectos que cobran tracción son los que recuerdan de forma selectiva, con la teoría de que un buen resumen del último mes supera un registro perfecto de la última hora.

El routing como estrategia de contexto

La tercera pieza del rompecabezas es el routing: decidir, antes de que se ejecute una tarea, qué modelo y qué herramientas necesita, para que no se cargue con capacidades que nunca usará. Un modelo al que se le han anunciado diecisiete integraciones distintas gasta contexto en las diecisiete aunque la tarea solo necesite una. Imponer el routing en todas las plataformas suena a detalle de infraestructura. En realidad es una decisión de presupuesto de contexto disfrazada.

Aquí es donde el problema deja de parecer un problema de caché y empieza a parecer diseño de sistemas. El context window del agente es un recurso, igual que la memoria y el disco son recursos, y las herramientas que lo tratan como tal son las que mantienen a los agentes coherentes en trabajos largos. No es casualidad que los proyectos de sandboxing, memoria y routing converjan: son tres vistas de la misma escasez.

El patrón del subagent es el ejemplo más claro. Cuando un agente engendra un ayudante para un trabajo acotado, ese ayudante no necesita heredar toda la conversación. Darle un contexto limpio con solo la tarea en curso es más barato y más preciso, y por eso los harnesses más nuevos permiten que un subagent compacte su propio contexto antes que el padre. El padre conserva la historia larga; el hijo recibe un escritorio recién despejado. Los equipos que han ejecutado agentes en refactorizaciones de una semana suelen llegar a esta regla por su cuenta, normalmente después de ver a un subagent gastar toda su ventana releyendo una conversación que no necesitaba.

Por qué llega ahora

Ninguno de estos problemas es nuevo. Los agentes pierden contexto desde el primero que se ejecutó. Lo que ha cambiado es que ahora se espera que los agentes corran durante horas, a través de muchas sesiones, en trabajo que importa. Un juguete no pierde nada cuando olvida. Una herramienta de la que un equipo depende para una refactorización de una semana pierde muchísimo.

El mercado se ha dado cuenta. Hace dos años, «nuestro agente tiene una ventana de contexto de 200k» era un argumento de venta. Ahora la pregunta útil es qué fracción de esa ventana se dedica a señal. Los proveedores que lo entienden están lanzando controles de compactación y aislamiento de contexto para subagents. La comunidad está lanzando la fontanería que hace soportable el resto.

La conclusión poco glamurosa

Es tentador leer las noticias de agentes de octubre como una historia sobre modelos más inteligentes y plugins más ingeniosos. La historia más silenciosa y más duradera va sobre higiene. Los agentes ya son lo bastante útiles para correr durante largos periodos, y los periodos largos exponen cada debilidad en cómo gestionan su propia memoria.

Los proyectos que escalan las listas de tendencias son los que aceptan una verdad mundana: el cuello de botella del trabajo autónomo rara vez es la inteligencia bruta. Es la capacidad de mantenerse en la tarea sin ahogarse en tus propias notas. Arregla la memoria, mete el ruido en un sandbox, encamina las capacidades, y un modelo meramente competente de pronto parece excelente. Equivócate en eso y hasta un modelo de frontera pasará la tarde releyendo un archivo de registro que ya leyó cinco veces.