De la ingeniería de prompts a la ingeniería de contexto: escribir, seleccionar, comprimir, aislar

Cualquiera que haya creado un agente probablemente haya observado el mismo patrón. En los primeros pasos se comporta bien: elige herramientas adecuadas, razona con claridad y se enfoca en la tarea. Alrededor del paso 15 o 20 comienza a descuidarse. Olvida lo que se le pidió, utiliza herramientas que no son pertinentes para el trabajo o empieza a producir resultados de baja calidad.

La primera sospecha habitual es el modelo. Pero con mayor frecuencia, el culpable es lo que se le muestra al modelo. Decidir qué se presenta ante el modelo, en qué formato y en qué momento se denomina ingeniería de contexto, y para quienes crean agentes se ha convertido en una de las habilidades más valiosas del momento.

Las secciones siguientes tratan sobre qué es la ingeniería de contexto y por qué los agentes la necesitan, las cuatro estrategias que organizan casi todas las técnicas, las cuatro formas en que el contexto falla, consejos concretos para los prompts de sistema y las definiciones de herramientas, un flujo de trabajo por fases que integra estas estrategias, y cómo Claude Code, Manus, ChatGPT Agent y el Kit de Desarrollo de Agentes de Google manejan este tema.

De la ingeniería de prompts a la ingeniería de contexto en la ventana de contexto

La ingeniería de prompts consiste en redactar buenas instrucciones para un modelo de lenguaje: expresar las cosas con claridad, proporcionar ejemplos y asignar un rol. Para una conversación con una sola pregunta y respuesta, a menudo eso es suficiente.

Los agentes cambian la situación. Un agente no responde de inmediato; navega, llama a APIs, escribe código y ejecuta comandos, paso a paso, y a veces durante decenas de pasos, sin la intervención humana. Cada paso genera un resultado, y todos ellos se incluyen en el contexto del modelo, el cual tiene un tamaño fijo.

Por lo tanto, la ingeniería de contexto consiste en diseñar todo el sistema de información en torno al modelo. Esto incluye el prompt del sistema, las definiciones de las herramientas, los resultados de las llamadas previas a las herramientas, el historial de conversaciones y mucho más, en cada uno de los pasos. El equipo de ingeniería de Anthropic describe el contexto como el conjunto de tokens que se incluyen al extraer muestras de un modelo, y la ingeniería de contexto como la optimización de cuán útiles son esos tokens para lograr el resultado deseado. En pocas palabras, el agente debe ver la información correcta, en el formato adecuado, en el momento oportuno.

Anthropic también lo presenta como la siguiente etapa natural después de la ingeniería de prompts. Todo lo relacionado con la creación de prompts sigue siendo aplicable (instrucciones claras, buenos ejemplos, formato estructurado), y se añade una capa adicional: herramientas, datos externos, historial de mensajes, memoria y estado dinámico. La ingeniería de prompts se convierte así en un subconjunto de este enfoque.

El momento es importante. Gartner proyecta que para finales de 2026, el 40 % de las aplicaciones empresariales incluirán agentes de IA específicos para tareas, frente a menos del 5 % en 2025. Estos agentes reemplazan a los prompts estáticos y a los pipelines de recuperación fijos por un sistema dinámico en el que cada llamada a una herramienta, documento recuperado y decisión se incluye en una ventana que se llena de información que el usuario nunca solicitó directamente. Los equipos que aprenden a gestionar esto suelen crear agentes que siguen siendo fiables, ya que dejan de culpar al modelo por los problemas que provienen de sus entradas.

La ventana de contexto como memoria de trabajo

LangChain ofrece una analogía útil. Considere al LLM como un nuevo tipo de sistema operativo: el modelo es la CPU que realiza el razonamiento, y la ventana de contexto es la RAM, la memoria de trabajo que almacena todo lo que el modelo puede ver en ese momento. Así como una computadora se ralentiza cuando se llena la RAM, el razonamiento de un agente empeora a medida que su ventana se llena.

Este efecto tiene un nombre: deterioro del contexto. Chroma probó dieciocho modelos de vanguardia, entre ellos GPT-4.1, Claude 4, Gemini 2.5 y Qwen3, y descubrió que todos ellos presentan un peor rendimiento a medida que aumenta la longitud de la entrada, incluso mucho antes de alcanzar el límite anunciado. Un modelo con una ventana de 200K tokens puede mostrar una degradación real ya con 50K tokens. No hay un descenso brusco, solo una pendiente gradual. Los propios documentos técnicos de Anthropic llegan a la misma conclusión y consideran la degradación como un gradiente.

La razón radica en cómo funcionan los transformadores. Cada token presta atención a todos los demás tokens, lo que genera n al cuadrado de relaciones entre pares. A medida que la ventana crece, la capacidad del modelo para seguirles el rastro se dispersa, algo similar a pedirle a alguien que mantenga en su cabeza una cantidad cada vez mayor de elementos. En algún momento se dejan de tener en cuenta.

Un segundo efecto bien estudiado es el de “perderse en el medio”. Un grupo de investigación liderado por Liu descubrió que la atención sigue una forma de U. El material cercano al inicio del contexto se recuerda bien, el material cercano al final también se recuerda bien, pero el material del medio se pasa por alto; la precisión disminuye en más de treinta puntos porcentuales cuando el pasaje relevante se desplaza del principio hacia el medio. Imagine a un agente cuyas instrucciones originales se encuentran debajo de cincuenta mil tokens de salida de herramientas. Esas instrucciones prácticamente han desaparecido.

Los profesionales han establecido reglas prácticas. Los usuarios de Claude Code informan que la calidad de los resultados comienza a disminuir alrededor del 40 al 60 por ciento del tiempo de ejecución, mucho antes de llegar a cualquier límite estricto.

Qué compite por el espacio

Siete tipos de información compiten por espacio en el contexto de un agente:

1. La instrucción del sistema, que representa la identidad del agente: reglas de comportamiento, flujo de control y orientación para diferentes tipos de tareas. En un agente es mucho más que una simple línea que diga “asistente útil” y puede definir cómo funciona todo el sistema.
2. Definiciones de herramientas. Cada herramienta que pueda utilizar el agente necesita un esquema que describa qué hace, qué parámetros acepta y cuándo debe usarse.
3. Resultados de las herramientas. Cada llamada agrega su salida. Una página web recuperada puede contener de cinco a diez mil tokens, y lo mismo ocurre con los archivos leídos.
4. Conocimiento recuperado de RAG: resultados de búsquedas en bases de datos vectoriales, respuestas de API, cualquier información utilizada para tomar decisiones.
5. Historial de conversaciones, la transcripción completa de los mensajes del usuario, respuestas, razonamientos y decisiones anteriores, que aumenta con cada interacción.
6. Memoria, tanto a corto plazo, proveniente de la sesión actual, como a largo plazo, de sesiones anteriores, como preferencias, resultados de tareas y patrones aprendidos.
7. Estado del agente: el plan actual, la lista de tareas pendientes, marcadores de progreso y notas temporales que indican en qué fase se encuentra el agente en un trabajo de múltiples pasos.

Las cuatro estrategias principales, con ejemplos de RAG y Claude Code

Con un período de tiempo finito y en constante reducción, las preguntas se centran en qué se incluye, qué se excluye y qué se debe sacrificar. El marco de trabajo ampliamente citado de LangChain clasifica cada técnica de ingeniería de contexto en cuatro categorías: escribir, seleccionar, comprimir e aislar. Una vez que se conocen estas categorías, casi cualquier técnica que se encuentre se encajará en una de ellas.

Escribir

Los agentes olvidan. Cuando todo el contexto se comprime, la información desaparece, y si el agente no la guardó en otro lugar, se pierde para siempre. Escribir implica proporcionar al agente formas de conservar la información fuera de ese período limitado. Esto se realiza a través de tres formas comunes.

Tableros de bocetos son una herramienta de toma de notas que el agente puede utilizar durante una tarea para registrar hallazgos provisionales, decisiones y elementos que necesitará más adelante. Anthropic desarrolló una herramienta de “reflexión” que brinda a Claude un lugar dedicado para analizar un problema, y en las pruebas de tau-bench mejoró el rendimiento hasta en un 54% en ciertas tareas.

Archivos de reglas funcionan como memoria procedural persistente. Los usuarios de Claude Code conocen CLAUDE.md. Estos archivos se cargan al inicio de cada sesión como instrucciones permanentes, que abarcan la arquitectura del proyecto, las convenciones, cómo ejecutar pruebas y qué aspectos deben tenerse en cuenta, para que los aspectos básicos no se olviden nunca.

Extracción de memoria permite al agente almacenar hechos, preferencias y patrones aprendidos en un sistema basado en archivos y consultarlos en sesiones posteriores, completamente fuera de la ventana de interacción.

Seleccionar

Las notas solo son útiles si las adecuadas llegan en el momento oportuno. La selección implica proporcionarle al agente lo que necesita para ese paso y no todo lo que podría utilizar. Un agente con docenas de herramientas, una amplia base de conocimientos y varias sesiones de historial no puede cargar todo de una vez, por lo que algo debe decidir qué es relevante, y la verdadera pregunta es qué es lo que decide.

En el RAG clásico, el sistema es quien decide. Llega una pregunta, se recuperan documentos y se incluyen en el prompt, y el modelo no tiene voz en el asunto. En el RAG agente, el propio agente elige qué buscar, qué herramientas utilizar, cómo refinar las consultas y cuándo ya tiene suficiente. La recuperación de información se convierte en un proceso iterativo, lo cual es adecuado porque la relevancia cambia en cada paso de una tarea larga y solo el agente sabe qué necesita a continuación.

Tanto LangChain como Pinecone distinguen tres tipos de memoria de las que se pueden extraer datos. La memoria episódica consiste esencialmente en ejemplos de pocos casos en los que se manejó anteriormente una situación similar. La memoria semántica es un almacenamiento de hechos que el agente ha aprendido o a los que le han sido comunicados. La memoria procedural son las instrucciones de comportamiento establecidas, como los archivos de reglas mencionados anteriormente. Un agente bien diseñado recurre a las tres según el paso a seguir.

Las herramientas causan los mayores problemas de selección. Con algo más de cuarenta herramientas, pueden existir hasta diez mil tokens de definiciones en el contexto antes de que comience cualquier tarea. Y como muestra la sección de fallos a continuación, demasiadas herramientas no solo desperdician espacio, sino que también confunden activamente al modelo.

La solución consiste en aplicar RAG a las descripciones mismas de las herramientas, ejecutando una búsqueda semántica que muestre únicamente las pocas herramientas que podría utilizar el paso actual. Un artículo titulado RAG-MCP puso esto a prueba y observó que la precisión en la selección de herramientas aumentó de aproximadamente el 14 % al 43 %, más de tres veces, mientras que los tokens de los prompts disminuyeron en aproximadamente la mitad.

El consejo general de Anthropic es adoptar un enfoque híbrido. Cargar una pequeña cantidad de material esencial de antemano para agilizar el proceso, como el archivo CLAUDE.md, y permitir que el agente obtenga todo lo demás justo a tiempo. En la práctica, eso significa que el agente almacena referencias simples como rutas de archivos, consultas y enlaces, y luego abre el contenido más voluminoso solo cuando un paso lo requiere. Cargar lo básico por adelantado y recuperar el resto según sea necesario mantiene el sistema ligero sin dejar al agente desinformado.

Compresión

Incluso con una buena selección, la ventana sigue llenándose. Imagine a un agente que realiza veinte llamadas a herramientas; lleva consigo ochenta mil tokens de resultados, historial y rastros de razonamiento, la mayoría de los cuales ya fueron procesados. Ese material antiguo sigue ocupando espacio, reduce la atención y aumenta los costos y la latencia. Este es nuevamente el problema de la descomposición del contexto, y la compresión lo aborda reduciendo los tokens mientras mantiene la información importante. Esto se puede hacer en tres puntos.

Antes de que la información ingrese al contexto. El fragmentado divide los documentos grandes en partes más pequeñas y coherentes, y el reordenamiento permite que solo los mejores fragmentos lleguen a la ventana. Los resultados de las herramientas también pueden resumirse al instante, antes de que se incorporen al contexto principal.

Mientras el agente está trabajando. La técnica común es resumir la conversación: un resumen actualizado después de cada intercambio mantiene un registro compacto de todo lo ocurrido hasta el momento. Un enfoque híbrido popular conserva las últimas diez mensajes palabra por palabra, ya que aún pueden ser necesarios detalles precisos, y resume todo lo anterior. Otra opción es recortar el contenido mediante reglas predefinidas, eliminando los mensajes antiguos una vez se supera un umbral de tamaño. Claude Code incluye una función de compactación automática que resume toda la trayectoria cuando la ventana alcanza el 95 % de su capacidad. Eso sirve como medida de seguridad. Lo ideal es que la compresión se realice con antelación y no solo cuando se activa una situación de emergencia.

Después de que el agente haya utilizado algo. La solución más sencilla es borrar los resultados de la herramienta. Si una herramienta ejecutó quince pasos atrás y el agente ya actuó sobre la salida, el texto en bruto puede eliminarse. Una página web completa cargada hace tiempo puede reemplazarse por un resumen de una sola línea o eliminarse por completo.

Aislar

El aislamiento es lo que hace viables los sistemas multiagente. Supongamos que un agente se encarga de la investigación, la planificación, la programación, las pruebas y la depuración dentro de una única conversación prolongada. Su contexto se llenará, pero el problema más grave es la contaminación. Las búsquedas de archivos realizadas durante la fase de investigación siguen existiendo cuando comienza la implementación, y ese material antiguo se convierte en ruido, distrayendo al modelo justo cuando necesita escribir código limpio.

La solución es asignar ventanas de contexto separadas a las distintas partes del trabajo.

La forma obvia son los subagentes. Un agente principal asigna una tarea específica, como encontrar todos los archivos relacionados con la autenticación, a un subagente que funciona en su propia ventana independiente. Una vez completada, este solo devuelve un resumen condensado, y toda la búsqueda compleja permanece dentro del subagente sin afectar al agente principal.

Otra variante es la isolación del esquema de estado, tal como se implementa en LangGraph. El estado del agente está diseñado de modo que diferentes campos almacenen distintos tipos de contexto, y el modelo solo ve los campos relevantes para el paso actual. Los resultados de las herramientas pueden quedar en un campo oculto al que el modelo nunca accede hasta que algo los hace visible intencionadamente. Esto permite un control detallado sin tener que crear agentes adicionales.

En resumen, las estrategias son escribir, seleccionar, comprimir e aislar, y todo lo que sigue aplica una o más de ellas.

Cómo fallan los agentes

Los modos de fallo nos enseñan qué evitar. A mediados de 2025, Drew Breunig escribió una influyente serie de dos partes en la que detalló cuatro formas distintas en las que los agentes dejan de funcionar a medida que su contexto se vuelve más complejo.

Envenenamiento del contexto. Una alucinación o error llega al contexto y luego se vuelve a referir a él una y otra vez. Quizás una herramienta devolvió datos incorrectos, o el agente realizó una inferencia errónea hace cinco pasos. El error permanece en el contexto y el agente sigue basándose en él; como los agentes iteran sobre sus propias salidas, cada paso incorrecto se agrava. La solución es la poda: eliminar activamente la información obsoleta o contradictoria a medida que llegan nuevos detalles, validar las salidas de las herramientas (especialmente las de fuentes externas) antes de que ingresen al contexto, y después de que el agente se recupere de un error, comprimir los intentos fallidos para que diez pasos de depuración sin resultados no persistan cuando solo importa la solución. Si se dejan intactos, esos intentos abandonados siguen tentando al modelo a volver a utilizar enfoques que ya han fallado.

Distracción por el contexto. Con un contexto muy largo, el modelo comienza a depender en exceso de la historia reciente y en menor medida de lo que aprendió durante el entrenamiento. Deja de sintetizar algo nuevo y repite patrones que vio recientemente, repitiendo acciones pasadas en lugar de formular un plan nuevo. La solución es el mismo consejo general: resumir y eliminar de forma enérgica, incluso si el rango de contexto es enorme.

Confusión en el contexto. El modelo recoge contenido superfluo que reduce la calidad de la respuesta. El caso típico es la confusión con las herramientas. Un estudio de referencia ejecutó un modelo Llama 3.1 8B cuantizado en la prueba GeoEngine. Con los cuarenta y seis herramientas disponibles, falló, aunque el contexto estaba dentro de sus límites. Con solo diecinueve herramientas, funcionó. Las herramientas cabían en el rango permitido, pero eran demasiadas como para que el modelo pudiera razonar de manera clara. La solución es la gestión dinámica de herramientas: se deben reducir las herramientas disponibles a aquellas que corresponden a la fase en la que se encuentra el agente, utilizando un recuperador de tipo RAG-MCP para seleccionar las pertinentes en cada paso.

Conflicto de contexto. La nueva información recopilada durante una ejecución contradice algo que ya está en el contexto. El prompt del sistema puede indicar una cosa mientras que un documento recuperado dice otra distinta. El agente no puede reconciliarlos y actúa de manera inconsistente, siguiendo a veces una fuente, otras a otra, y en ocasiones haciendo algo que no coincide con ninguna de ellas. La solución es establecer un orden claro de autoridad: el prompt del sistema por encima de los hechos recuperados, y estos por encima del historial de conversación. Se debe validar la nueva información frente a lo que ya existe antes de incorporarla, y utilizar secciones estructuradas como etiquetas XML o encabezados claros para que el modelo pueda determinar de dónde proviene cada elemento y hasta qué punto confiar en él.

La buena noticia es que nombrar un fallo suele indicar una estrategia. El problema del envenenamiento se aborda mediante compresión y poda, el de la distracción mediante compresión, el de la confusión mediante selección, y el de los conflictos mediante escritura estructurada y selección. Todo se reduce a escribir, seleccionar, comprimir e aislar.

Indicaciones del sistema para los agentes

Indicar instrucciones a un agente difiere significativamente de hacerlo con un chatbot. Una indicación para un chatbot suele establecer un tono: ser amable, mantenerlo breve. Una indicación para un agente define su arquitectura. Detalla el flujo de control, es decir, cómo manejar diferentes tipos de tareas, qué herramientas son adecuadas para cada situación, qué hacer tras un error y qué límites de seguridad aplican. Se parece más a una descripción de puesto de trabajo para un empleado autónomo.

Anthropic habla sobre escribir a la altitud adecuada, y existe una zona de Goldilocks. Ser demasiado prescriptivo resulta frágil. Imagine una regla que exija usar la herramienta X cada vez que el usuario mencione facturación, solicite un reembolso y la cantidad supere los cien dólares; esta regla fallaría en cada caso límite que nadie previó. Ser demasiado vago es igualmente malo. La frase “Sé útil y utiliza las herramientas adecuadas” no proporciona nada al agente, ya que este no sabe qué herramientas son adecuadas para qué y no puede tomar decisiones sin señales concretas. El punto óptimo es lo suficientemente específico como para guiar el comportamiento autónomo y lo suficientemente flexible como para que el modelo pueda aplicar su juicio en situaciones nuevas. Piense en heurísticas sólidas, no en reglas rígidas.

Algunos hábitos prácticos ayudan:

• Proporcione una estructura para el prompt, con etiquetas XML o encabezados de markdown que separen la información de contexto, las instrucciones y las indicaciones sobre las herramientas.
• Comience de forma mínima e iterando ante los fallos. Ejecute el agente en tareas reales, identifique dónde falla y añada instrucciones dirigidas a esos fallos específicos, en lugar de intentar predecir todos los casos límite de antemano.
• Lo mínimo no es lo mismo que lo breve. Una instrucción para un flujo de trabajo complejo puede llegar a contener miles de tokens, y eso está bien, siempre y cuando cada token tenga su razón de ser.
• Utilice ejemplos de pocos casos. Mostrar casos diversos y canónicos de elección correcta de herramientas, razonamiento sólido y ejecución adecuada en múltiples pasos es mejor que describir cada regla con palabras.

Definiciones de herramientas

Cada herramienta llamable necesita un esquema que describa su propósito, parámetros y cuándo utilizarla. Una buena definición es autónoma, tolerante a los errores y clara en sus instrucciones, y su costo es el espacio de contexto.

En la producción, las herramientas se conectan cada vez más a través de MCP, el Protocolo de Contexto de Modelo, una forma estándar para que los agentes accedan a herramientas y datos externos. Un servidor MCP para GitHub, otro para la base de datos y un tercero para el sistema de archivos, todos exponiendo herramientas a través de una interfaz uniforme. El problema es que conectar herramientas se vuelve tan sencillo que se abusa de esta facilidad. Con cuatro o cinco servidores conectados, las definiciones pueden consumir miles de tokens antes incluso de dar el primer paso.

El consejo por defecto es crear un conjunto mínimo viable. Cuando un agente realmente necesita muchas herramientas, hay dos enfoques que permiten escalar.

El primero proviene de Manus, una plataforma de agentes de producción. Desaconsejan agregar o eliminar herramientas en medio de una conversación por una razón que muchos desarrolladores no conocen: la caché KV. Cuando los tokens llegan a un LLM, el modelo calcula representaciones clave-valor para cada uno de ellos, lo cual es costoso, por eso los proveedores los almacenan en caché. Si el inicio del contexto (el prefijo) es idéntico entre llamadas, el proveedor reutiliza el trabajo almacenado en caché y procesa solo los nuevos tokens al final, lo cual es más rápido y económico.

Si se reorganiza o se edita la parte inicial del contexto entre llamadas, la caché se invalida y todo debe volverse a calcular. Con Claude Sonnet, los tokens de entrada en caché cuestan treinta centavos por millón, frente a tres dólares por millón para los que no están en caché, lo que representa una diferencia de diez veces. Un agente que realiza treinta o cuarenta llamadas por tarea lo nota rápidamente.

Por lo tanto, Manus prefiere el enmascaramiento de herramientas sobre su eliminación. Cada definición permanece en el prefijo en caché, pero ciertas herramientas se marcan como no disponibles para la fase actual. Las definiciones se mantienen para garantizar la estabilidad del caché, ya que el agente sabe que no debe usarlas, y los prefijos de nomenclatura consistentes le ayudan a razonar sobre las categorías de herramientas.

El segundo enfoque es la selección basada en RAG mencionada anteriormente: recuperar solo las herramientas relevantes para el paso actual, lo cual, según el artículo RAG-MCP, aumentó la precisión más de tres veces al mismo tiempo que redujo a la mitad el uso de tokens. Los dos métodos se complementan entre sí: el enmascaramiento es adecuado para un conjunto de herramientas moderado, mientras que la recuperación es adecuada para uno muy grande.

Debajo de ambos existe un principio fundamental: el contenido estable se coloca en la parte superior del contexto: el prompt del sistema, las definiciones de las herramientas y todo aquello que no cambia entre turnos. El contenido dinámico (historial, paso actual, estado del agente) se coloca en la parte inferior.

Un flujo de trabajo por fases que combina todo

Estos principios son válidos tanto para un asistente de programación listo para usar como para un agente desarrollado a medida. La única diferencia radica en si estructuras tú mismo el flujo de trabajo o creas el agente para que lo haga.

El CEO de HumanLayer, Dex Horthy, dio una charla en el AI Engineer Code Summit en la que describió un método que ilustra todo esto de manera clara. Según se informa, su equipo lo utilizó para incorporar unas treinta y cinco mil líneas de código en una gran base de código en Rust durante una sola sesión de siete horas. Él lo denomina Compresión Intencional Frequentemente. El trabajo se divide intencionadamente en fases; cada fase genera un artefacto compacto, como un resumen estructurado en markdown, y cada nueva fase comienza en una ventana nueva que contiene únicamente ese artefacto. El objetivo es mantener deliberadamente el espacio ocupado en aproximadamente entre el 40 y el 60 por ciento de la ventana.

Primera fase: investigación. Antes de escribir cualquier código, el agente explora la base de código: lee archivos, sigue los flujos de datos y mapea la arquitectura relevante para la tarea. Los subagentes se encargan de la búsqueda y análisis brutos, de modo que todos esos resultados de grep y contenidos de archivos permanecen en sus ventanas y nunca afectan a la del agente principal. Eso es aislamiento. La salida de esta fase es un archivo de investigación, un documento markdown compacto que contiene rutas de archivos, firmas de funciones, patrones existentes y problemas potenciales. Eso constituye escritura, ya que los hallazgos se almacenan fuera de la ventana. Luego se reinicia el contexto. La investigación bruta podría haber ocupado del 60 al 80 por ciento de la ventana, mientras que el archivo resultante reduce ese espacio a quizás entre el 15 y el 20 por ciento. Eso es compresión.

Fase dos: planificación. Se abre una ventana completamente nueva que contiene únicamente el archivo de investigación y la descripción del problema, y el agente utiliza esa hoja en blanco para redactar un plan de implementación detallado. Este también es el mejor momento para la revisión humana. Un error lógico detectado aquí es fácil de corregir, por lo que cualquiera que construya su propio agente debería incluir un punto de control con intervención humana en esta etapa.

Fase tres: implementación. Otra ventana nueva muestra únicamente el plan, y el agente lo sigue paso a paso. En los trabajos que requieren varios ciclos de compactación, un archivo progress.md registra qué se ha completado y qué queda por hacer, lo cual implica escribir nuevamente.

Alguna versión de este proceso se encuentra en la mayoría de los sistemas en producción.

Cómo manejan el contexto los productos reales

Claude Code. El agente de programación por línea de comandos de Anthropic es uno de los casos mejor documentados. Utiliza una recuperación híbrida: los archivos CLAUDE.md se cargan al inicio de cada sesión para proporcionar contexto básico, mientras que herramientas como glob y grep se encargan de explorar la base de código según sea necesario. No indexa todo de antemano, sino que explora bajo demanda. La compactación automática se activa al alcanzar un 95% de utilización y preserva las decisiones arquitectónicas además de los cinco archivos accedidos más recientemente. Puede generar subagentes con entornos limpios para tareas complejas, y una herramienta de memoria mantiene la información entre sesiones. La filosofía rectora es hacer lo más simple que funcione, confiando en que el modelo sea inteligente para determinar lo que necesita y proporcionándole las herramientas para encontrarlo.

Manus. Se trata del enfoque que requiere más infraestructura, lo cual tiene sentido para un agente de uso general que atiende a cientos de miles de usuarios, donde es crucial la eficiencia a gran escala. Su característica distintiva es el ordenamiento consciente del caché KV, que mantiene el prefijo estable entre turnos para maximizar la reutilización del caché y utiliza herramientas de enmascaramiento en lugar de eliminarlas. Un pipeline de compresión de observaciones procesa toda la salida de las herramientas antes de que llegue al contexto del agente. Una lista de tareas persistente hace seguimiento del estado, y el sistema de archivos funciona como memoria de reserva para el contexto expulsado.

ChatGPT Agent. El agente de OpenAI, que surgió de Operator, es arquitectónicamente diferente de ambos. Al estar basado en un modelo de agente que utiliza la computadora, sigue un enfoque centrado en la interfaz gráfica. En lugar de realizar llamadas a herramientas basadas en texto, utiliza un navegador visual, y las capturas de pantalla se incorporan al contexto como instantáneas sobre las cuales el modelo razona, junto con su historial de capturas anteriores y acciones realizadas. La complejidad del desafío cambia en consecuencia. Los tokens visuales son costosos, por lo que el agente debe ser selectivo respecto a cuántas capturas de pantalla conservar. OpenAI emplea el aprendizaje por refuerzo para descubrir buenas estrategias de uso de herramientas, entrenándose en miles de máquinas virtuales en lugar de programar de forma fija cuándo utilizar cada herramienta. Deep Research y Operator comparten estado, lo que permite transiciones fluidas entre la navegación, el análisis de texto y la ejecución de código. En comparación con Claude Code, centrado en el código, basado en herramientas de texto y con ventanas grandes, este es visual y de uso general. Ambos requieren ingeniería de contexto, pero con problemas y soluciones diferentes.

Kit de desarrollo de agentes de Google. ADK adopta la postura arquitectónica más fundamentada, con tres principios de diseño para el contexto de los agentes. Separa el almacenamiento de la presentación, ya que el estado duradero no es lo mismo que lo que aparece en una llamada a API determinada. Utiliza transformaciones explícitas, es decir, procesadores nombrados y ordenados que remodelan el contexto en pasos comprobables y componibles, en lugar de concatenaciones de cadenas ad hoc. Por defecto, delimita el contexto de modo que cada llamada al modelo vea solo lo mínimo necesario y nada llegue al contexto a menos que se incluya explícitamente. El resultado trata la compilación del contexto como una tubería con etapas claras, y no como un prompt al que se sigan añadiendo elementos.

La tubería común de contexto

Al observar estas plataformas, surge la misma estructura en cada turno del agente:

1. Recopilar candidatos: entrada del usuario, historial, resultados de las herramientas, documentos recuperados y estado del agente.
2. Elegir lo que sea relevante para este paso dentro del presupuesto de tokens restante.
3. Comprimir resumiendo, truncando o reestructurando la selección para que quepa.
4. Organizar todo para su reutilización en la caché KV, con el contenido estable primero y el contenido dinámico al final.
5. Construir el contexto final y realizar la llamada.

El campo avanza rápidamente y aún hay mucho por aprender, por lo que la mejor forma de mejorar es experimentando: crear algo, observar dónde falla y ajustar.

Leer más

• Ingeniería de contexto para aplicaciones LLM: Salidas estructuradas, herramientas y límites de los agentes: Cómo diseñar intencionalmente las entradas del modelo: selección de contexto, plantillas de prompts, esquemas JSON, decodificación restringida, llamadas a herramientas, bucles de agentes y autonomía limitada.
• Estrategias de particionamiento para RAG en producción: de tamaño fijo, semántico y padre-hijo: Una guía práctica sobre el particionamiento en RAG, desde la división por tamaño fijo y recursiva hasta los enfoques padre-hijo, proposiciones, particionamiento tardío, RAPTOR, tablas, código y pruebas de rendimiento.

Ingeniería de Contexto en la Práctica: Un Agente de Investigación con Claude Agent SDK: Crea un agente de investigación en Python con el Claude Agent SDK utilizando patrones de escritura, selección, compresión e aislamiento, y luego compáralo con una línea de base simple en pruebas medidas.