Ingeniería de contexto para agentes de IA de largo alcance

En conjunto, el análisis de Arize, el artículo de arXiv sobre desbordamiento de la ventana de contexto, el explicador para producción de Redis, y la comparación de ingeniería de prompts, contexto y orquestación de Atlan apuntan a un cambio práctico en el diseño de agentes. Los agentes de larga ejecución se evalúan cada vez menos por el tamaño de la ventana de contexto del modelo y más por la capa de control que la rodea. Arize concreta ese cambio. Nombra herramientas de agentes y sistemas de memoria/orquestación ya lanzados, incluidos Pi, OpenClaw, Claude Code y Letta, como ejemplos de ingeniería de contexto a nivel de orquestación, y describe un simulador interactivo que muestra cómo se llena una ventana de 200K tokens.

Los detalles públicos disponibles en las fuentes citadas son desiguales. Arize ofrece cifras concretas de implementación para Pi, OpenClaw, Claude Code y Letta. Un artículo de investigación sobre cómo resolver el desbordamiento de la ventana de contexto en agentes de IA da un mecanismo más general para gestionar salidas de herramientas que pueden superar cualquier ventana práctica. El explicador de Redis sobre desbordamiento de la ventana de contexto resume los síntomas en producción: errores duros de API, degradación silenciosa de la calidad, acumulación de salidas de herramientas y mayor latencia a medida que crecen los prompts. La comparación de Atlan sobre ingeniería de prompts, contexto y orquestación aporta una metáfora de pila útil: la ingeniería de prompts da forma al mensaje, la ingeniería de contexto da forma a lo que ve el modelo y la ingeniería de orquestación da forma a todo el entorno del agente.

La noticia importante no es que las ventanas de contexto sean demasiado pequeñas. Quienes construyen estos sistemas ya lo saben. El punto más útil es que los sistemas de agentes citados están convergiendo en cuatro mecanismos de orquestación que mantienen vivo el trabajo después de que la transcripción deje de ser una fuente segura de verdad.

Un agente superficial lee archivos, llama a herramientas, añade el resultado y espera que el modelo pueda apañárselas. Un agente diseñado primero desde la orquestación bloquea o reformula entradas grandes antes de que lleguen al modelo.

Una forma más clara de leer el primer conjunto de límites es:

• Pi: las lecturas de archivos se detienen en 2.000 líneas o 50KB, lo que ocurra antes. El contenido devuelto incluye una pista de continuación que indica al modelo qué rango de líneas se mostró y cómo continuar con offset y limit. OpenClaw hereda ese comportamiento y después añade límites separados: los archivos de arranque se limitan a 12.000 caracteres por archivo y 60.000 caracteres en total. Los resultados de herramientas reciben otro presupuesto de 16.000 caracteres o el 30% de la ventana de contexto, lo que sea menor.

Claude Code usa un diseño de dos puertas. Según Arize, comprueba un límite de 256KB en bytes antes de abrir un archivo y después cuenta los tokens del resultado contra un presupuesto de 25.000 tokens tras la lectura. Incluso para archivos por debajo del límite, por defecto devuelve 2.000 líneas desde el principio y trunca las líneas de más de 2.000 caracteres. Si el modelo vuelve a leer el mismo rango de archivo y el archivo no ha cambiado, Claude Code puede devolver un stub en lugar de repetir todo el contenido.

Eso no es solo optimización. Cambia el modo de fallo. En lugar de permitir que una lectura grande desplace la tarea, el orquestador convierte «leer todo» en «leer un fragmento controlado». Si el modelo necesita más, puede pedirlo. Para quienes diseñan orquestadores de agentes desde cero, esta es la primera línea de defensa: nunca dejar que los datos externos en bruto se conviertan en la transcripción por defecto.

El siguiente patrón es tratar el contexto como una ventana de visualización, no como almacenamiento.

Pi y Claude Code exponen paginación mediante offset y limit. OpenClaw añade truncamiento de cabecera/cola en algunos lugares, conservando el principio y el final cuando es menos probable que la parte central importe. Arize dice que OpenClaw usa una división 75% cabecera / 25% cola para archivos de arranque sobredimensionados, y que puede conservar tanto la cabecera como la cola de resultados de herramientas cuando la cola parece importante, por ejemplo errores, llaves de cierre de JSON o palabras clave con aspecto de resumen.

Letta va más allá al hacer que los archivos vivan fuera del prompt. Los archivos subidos se analizan, se dividen en fragmentos y se convierten en embeddings en un almacén vectorial, lo que da al agente visualización directa, búsqueda exacta y búsqueda semántica. Cuando un archivo está abierto en contexto, Letta muestra una vista gestionada cuyo tamaño escala con el contexto del modelo: 5.000 caracteres para un contexto de 8K, 15.000 para 32K, 25.000 para 128K y 40.000 para 200K+. El número de archivos abiertos simultáneamente también escala, desde 3 para modelos pequeños hasta 15 para modelos muy grandes, con una política LRU que expulsa los archivos a los que se ha accedido menos recientemente.

Es la misma idea de diseño que hay detrás del RAG en producción: no metas todo el corpus en el prompt; recupera la parte que importa. La diferencia es que los orquestadores de agentes deben hacerlo continuamente, a través de archivos, salidas de herramientas, memoria y planes intermedios. La misma restricción se aplica a los sistemas RAG: la recuperación no trata solo de relevancia, sino también de preservar suficiente presupuesto de contexto para el paso de razonamiento real.

Redis plantea un punto relacionado: unas ventanas de contexto más grandes no eliminan la necesidad de gestión de contexto. Los prompts de sistema, los documentos recuperados, el historial de conversación y las salidas de herramientas compiten por el mismo espacio. Incluso antes de alcanzar un límite duro, los modelos pueden degradarse a medida que la información relevante queda enterrada en entradas largas.

El desbordamiento es el fallo evidente. La pérdida de objetivo es más silenciosa. El agente todavía tiene espacio para responder, pero olvida el objetivo original, pasa por alto una restricción o empieza a optimizar una subtarea local.

Ahí es donde importa la compactación. Mal hecha, la resumización sustituye un historial desordenado pero fiel por una historia ordenada pero con pérdidas. Bien hecha, preserva el estado de la tarea, el trabajo reciente, los elementos pendientes y la integridad de las llamadas a herramientas.

Arize informa de que Pi activa la compactación cuando los tokens de contexto estimados superan la ventana de contexto menos los tokens de reserva, con una reserva por defecto de 16.384 tokens. Conserva aproximadamente los 20.000 tokens más recientes y resume el contenido más antiguo en un mensaje sintético de usuario que se antepone a la cola conservada. También evita cortar entre pares de llamada a herramienta/resultado de herramienta.

OpenClaw añade una política de historial más agresiva. Cuando el historial supera el 50% de la ventana de contexto, divide los mensajes en fragmentos de tokens de masa equivalente, descarta el fragmento más antiguo, resume el contenido descartado mediante una resumización por etapas y de varias pasadas, y repara el emparejamiento llamada/resultado de herramienta. También realiza un vaciado previo a la compactación: un turno agéntico silencioso da al agente la oportunidad de persistir estado en archivos de memoria antes de que desaparezca el historial. Por separado, poda los resultados de herramientas en memoria con comportamiento de recorte suave y borrado duro sobre una TTL de caché de 5 minutos.

Claude Code compacta cerca del final de la ventana. Arize dice que su disparador es la ventana de contexto efectiva menos un búfer de 13.000 tokens, lo que sitúa la compactación alrededor de 167K tokens para un modelo con contexto de 200K. Su prompt de resumización pide secciones estructuradas que cubran la petición principal, conceptos técnicos, archivos y código, errores y correcciones, resolución de problemas, mensajes de usuario, tareas pendientes, trabajo actual y siguiente paso. Después de la compactación, puede volver a adjuntar hasta 5 archivos leídos recientemente dentro de un presupuesto de tokens.

El patrón está claro: la compactación no es «resumir el chat». Es hacer checkpointing. Un agente de larga ejecución necesita el equivalente a una partida guardada: objetivo, restricciones, decisiones, handles abiertos, evidencia reciente y siguiente acción.

Algunas salidas nunca deberían colocarse en la ventana de contexto.

El artículo de arXiv lo concreta con un flujo de trabajo de ciencia de materiales. Una herramienta genera una estructura de rejilla electrónica para una molécula: una matriz 3D de dimensiones 128 × 128 × 128, con un total de 2.097.152 elementos float32. Esa salida supera con creces la ventana de contexto de LLMs muy usados. Pero la siguiente herramienta necesita la rejilla como entrada.

La solución propuesta es almacenar valores grandes fuera del contexto del modelo y devolver identificadores cortos, o punteros. Los wrappers de herramientas inspeccionan las entradas para ver si son valores en bruto o rutas de memoria. Las salidas que son demasiado grandes se almacenan en la memoria de ejecución bajo una ruta, y las herramientas posteriores pueden recibir el puntero y resolverlo internamente. El modelo manipula referencias, mientras el orquestador preserva los datos completos. En un experimento comparativo en el que ambos métodos tuvieron éxito, el enfoque basado en punteros usó aproximadamente siete veces menos tokens que el flujo de trabajo tradicional, según el artículo.

Esta es la separación más limpia entre razonamiento y transporte de datos. El modelo no necesita «ver» una matriz de 2 millones de elementos para pasársela a otra herramienta. Necesita saber que la matriz existe, qué representa y qué operación debe consumirla a continuación.

La misma lógica se aplica más allá de los arrays científicos. Respuestas JSON grandes, PDFs, logs, embeddings, archivos multimedia y exportaciones de bases de datos suelen pertenecer al almacenamiento, no al prompt. Para sistemas construidos alrededor de herramientas MCP o conectores API personalizados, el paso de punteros debería ser una decisión de diseño de primer nivel, no un parche después del primer desbordamiento.

Una ventana de contexto de 200K tokens parece grande hasta que un agente empieza a actuar. Un prompt de sistema, definiciones de herramientas, unos pocos documentos recuperados, lecturas de archivos, logs, trazas de error y resúmenes pueden consumirla más rápido de lo esperado. El marco práctico no es lo grande que parece la ventana sobre el papel, sino lo rápido que los agentes la gastan en tiempo de ejecución. La guía de Redis sobre memoria de agentes apunta hacia memoria externa y duradera para el estado que debe sobrevivir entre llamadas, mientras que el enfoque de ingeniería de contexto de Atlan separa mejores prompts de un mejor ensamblaje de contexto. En conjunto, tratan la ventana de contexto menos como un almacén y más como un conjunto de trabajo restringido.

La lección más profunda es que una ventana de contexto es un recurso escaso en tiempo de ejecución. Tratarla como «memoria» ayuda, pero solo si el orquestador se comporta como un sistema operativo: asigna, expulsa, pagina, compacta, deduplica y persiste. La distinción por capas de Atlan es útil aquí. La ingeniería de prompts no puede arreglar un lector de archivos que vuelca 80.000 tokens irrelevantes en la siguiente llamada. La ingeniería de contexto puede mejorar el conjunto de trabajo. La ingeniería de orquestación decide si ese conjunto de trabajo está protegido desde el principio.

Esto también cambia cómo deberían evaluar los equipos a los agentes. Un prompt de demostración no basta. La evaluación de largo alcance debería incluir transcripciones crecientes, lecturas repetidas de archivos, salidas de herramientas grandes, llamadas a herramientas fallidas, reanudaciones después de la compactación y tareas en las que el siguiente paso correcto depende de una restricción temprana. Nuestra guía de ingeniería de contexto para agentes cubre la versión de ese problema del lado del modelo; la capa de orquestación es donde se vuelve operativa.

Primero, pon presupuestos en cada fuente de contexto. Archivos, salidas de herramientas, fragmentos recuperados, inserciones de memoria e historial de conversación deberían tener límites explícitos. Un único máximo global de tokens es demasiado tosco.

Segundo, haz que el truncamiento sea accionable. Si el orquestador corta contenido, el modelo debería saber qué rango ha visto y cómo pedir más. El truncamiento silencioso es peor que el rechazo porque crea trabajo confiado sobre datos ausentes.

Tercero, compacta alrededor del estado, no de la prosa. Los resúmenes deberían preservar el objetivo del usuario, las restricciones, las decisiones, las tareas pendientes, los archivos tocados, los resultados de herramientas que importan y el siguiente paso inmediato. Los pares de llamadas a herramientas deberían mantenerse intactos.

Cuarto, saca los valores grandes del prompt. Guárdalos, nómbralos y pasa punteros por las herramientas. Esto es especialmente importante para agentes que llaman a APIs, procesan documentos o coordinan sistemas multiagente.

Por último, prueba la pérdida de objetivo por separado del desbordamiento. Un agente puede mantenerse por debajo de la ventana dura y aun así desviarse. La pregunta adecuada no es solo «¿aceptó la API el prompt?». Es «¿la siguiente acción sigue sirviendo a la tarea original?».

El resumen de abajo convierte esos patrones en una lista rápida antes de las preguntas frecuentes.

• Los agentes de largo alcance fallan tanto por desbordamiento de contexto como por pérdida de objetivo, así que el orquestador debe gestionar más que la longitud del prompt.
• Los sistemas de agentes en producción usan presupuestos estrictos sobre archivos, salidas de herramientas e historial antes de que los datos en bruto lleguen al modelo.
• La paginación, la búsqueda y las vistas gestionadas tratan el contexto como una ventana limitada en lugar de almacenamiento permanente.
• La compactación funciona mejor como checkpointing: preserva objetivos, restricciones, decisiones, trabajo pendiente e integridad de las llamadas a herramientas.
• Las salidas de herramientas grandes suelen pertenecer al almacenamiento externo, con punteros cortos pasados entre herramientas en lugar de valores completos dentro del prompt.

Esta sección responde a las preguntas prácticas detrás de la ingeniería de contexto para agentes de largo alcance: qué se desborda, cómo se pierden los objetivos y qué patrones de orquestación mantienen el trabajo encaminado.

El desbordamiento de contexto ocurre cuando el prompt acumulado, el historial, los datos recuperados, los archivos y las salidas de herramientas de un agente superan la ventana de contexto utilizable del modelo o degradan la calidad antes de que se alcance el límite duro.

La pérdida de objetivo ocurre cuando la tarea original sigue presente en algún lugar de la transcripción pero ya no guía la siguiente acción del agente, a menudo después de historiales largos o de una mala resumización.

Establecen presupuestos por fuente, paginan lecturas de archivos, recuperan solo vistas relevantes, compactan el historial alrededor del estado, deduplican lecturas repetidas y almacenan salidas grandes fuera del prompt.

Los punteros permiten que el modelo se refiera a valores grandes almacenados en la memoria de ejecución, como matrices, logs o PDFs, mientras que las herramientas posteriores resuelven los datos completos sin colocarlos en la ventana de contexto.

No. Las ventanas más grandes ayudan, pero los prompts de sistema, las definiciones de herramientas, los documentos recuperados, los logs y el historial siguen compitiendo por espacio, y la información relevante puede quedar enterrada antes de alcanzar un límite duro.