Context engineering: qué es y cómo aplicarlo a los agentes de IA

El context engineering es la práctica de decidir qué información ocupa la ventana de contexto de un modelo en cada llamada: el system prompt, las definiciones de herramientas, los documentos recuperados, el historial de la tarea en curso y todo lo que el agente escribió en memoria en una sesión anterior. El prompt engineering trabaja sobre cómo preguntas. El context engineering trabaja sobre qué sabe el modelo cuando responde.

Importa a quien tiene agentes en producción: trabajo de varios pasos, herramientas conectadas, sesiones de horas y no de segundos. Un clasificador de un solo turno no lo necesita. Un agente que abre cuarenta archivos, llama a seis herramientas y corre noventa minutos se lo juega ahí. Anthropic describe el objetivo como encontrar el conjunto más pequeño de tokens de alta señal que produce el resultado buscado.

La versión de treinta segundos

Los modelos no leen la ventana de contexto de forma uniforme. Si el dato que importa queda en medio de cien mil tokens de salidas de herramientas, la precisión de recuperación baja. Si la sesión se alarga lo suficiente, el agente sigue respondiendo a la versión de la tarea que supuso veinte turnos atrás. El context engineering es el conjunto de movimientos que mantienen la ventana pequeña, ordenada y al día: recuperar en el momento justo, compactar cuando se llena, escribir el estado fuera de la ventana y pasar el trabajo separable a agentes que arrancan con la ventana limpia.

¿Por qué el prompt engineering dejó de bastar?

Los prompts mejoraban y los agentes seguían rompiéndose en los mismos sitios. La razón se mide. Investigadores de Microsoft Research y Salesforce Research simularon más de doscientas mil conversaciones en seis tareas de generación y encontraron que los modelos pierden de media un 39% de rendimiento cuando una instrucción completa llega a trozos repartidos en varios turnos en vez de llegar entera (Laban y otros, 2025). La pérdida vino de la falta de fiabilidad, un 112% más, y no de la capacidad, un 15% menos. Los modelos más grandes no aguantaron mejor: GPT-4.1, Claude 3.7 Sonnet y Gemini 2.5 Pro empeoran todos. El resumen del comportamiento en el paper es seco: cuando un modelo se equivoca de camino al principio, ya no vuelve.

El segundo hallazgo va de longitud, no de turnos. Chroma probó dieciocho modelos en recuperación y réplica de texto, tareas casi triviales con entradas cortas, y vio bajar la fiabilidad a medida que la entrada crecía (Context Rot, 2025). La posición también cuenta: lo que está al principio y al final de la ventana se trata mejor que lo que queda en medio. El nombre que cuajó es context rot, y el kit para replicar las pruebas es público.

Ninguno de los dos problemas se arregla con el prompt. Reescribir una instrucción no repara un paso de recuperación que devolvió el documento equivocado, y ninguna redacción rescata a un agente que veinte turnos antes se agarró a una hipótesis falsa. La solución está más arriba, en qué entra en la ventana y cuándo sale.

Qué hay de verdad en la ventana de contexto de un agente

• System prompt. Rol, restricciones, formato de salida, reglas de la casa. Casi siempre estático y casi siempre lo más barato de cachear.
• Definiciones de herramientas. Cada esquema conectado cuesta tokens en cada llamada, use el agente esa herramienta o no. Veinte herramientas son un impuesto que se paga siempre.
• Datos recuperados. Documentos, filas de base de datos, respuestas de API, contenidos de archivos. El bloque más grande y más volátil.
• Historial de la tarea. La transcripción de pasos dados, llamadas hechas y salidas recibidas. Crece sin parar si nadie interviene.
• Memoria. Lo que el agente anotó en una sesión anterior y relee ahora.

El prompt engineering toca el primer punto. El context engineering toca los cinco, más el orden en que llegan y el momento en que cada uno se retira.

Cómo se aplica en la práctica

Recuperación en el momento justo

Se cargan identificadores, no contenidos. El agente guarda rutas de archivo, consultas guardadas y enlaces, y llama a una herramienta para traer el contenido cuando de verdad hace falta. Claude Code funciona así: el archivo CLAUDE.md entra al principio, y glob y grep traen los fuentes durante la ejecución. El coste es una vuelta más por cada lectura, o sea latencia. La ganancia es una ventana que sigue pequeña en una tarea que toca doscientos archivos. Del archivo hablamos en la guía del CLAUDE.md.

Compactación

Cuando la ventana se acerca al límite, se resume la sesión y se arranca desde el resumen. Lo difícil es elegir qué se guarda. Anthropic recomienda conservar las decisiones de arquitectura, los bugs abiertos y los detalles de implementación, y soltar las salidas de herramientas que el agente ya consumió. Si compactas demasiado, pierdes la restricción que hacía falta en el paso cuarenta. Si compactas tarde, el agente lleva una hora empeorando.

Notas estructuradas

El estado se escribe en un archivo, fuera de la ventana, y se relee. Una lista de tareas, un registro de hallazgos, un histórico de decisiones. Así la ventana se puede reiniciar sin perder el hilo, porque el hilo vive en disco. Hay un efecto secundario que conviene: la ejecución queda auditable, y explicarle a un cliente por qué el agente hizo lo que hizo deja de ser una suposición.

Subagentes con ventana limpia

Se pasa una tarea estrecha y separable a un agente nuevo, que quema su propio contexto y devuelve un resumen. El agente principal se queda ligero. Es la arquitectura detrás de casi todos los agentes de investigación en producción. Cuesta más tokens en total y añade una superficie de coordinación que depurar, así que encaja en trabajo realmente independiente y no como opción por defecto. Los patrones que aguantan producción están en el artículo sobre sistemas multiagente.

Qué cuesta y qué ahorra

Dos números hacen concreta la economía. El equipo de Manus, una plataforma de agentes en producción, reporta una relación media entre tokens de entrada y de salida de unos 100 a 1: casi toda la factura es contexto, no generación. También reporta 0,30 dólares por millón de tokens de entrada con caché frente a 3,00 sin caché en Claude Sonnet, diez veces más (Manus, 2025). Las tarifas cambian, así que conviene comprobar los precios vigentes antes de hacer cuentas, pero la forma de la diferencia se ha mantenido.

Eso convierte la tasa de aciertos de caché en una métrica de primera y no en una optimización para más adelante. Y encarece decisiones pequeñas. Un timestamp arriba del system prompt invalida la caché desde ese token en adelante, en cada llamada, durante toda la vida del agente. Prefijos estables, historial que solo se añade y serialización JSON determinista son hábitos baratos que se notan en la factura. Las mismas cuentas desde el lado del billing están en el artículo sobre coste de tokens, y la mecánica de la caché en la API de Anthropic en Next.js.

Cuándo no hace falta

La disciplina se paga cuando las ejecuciones son largas, las herramientas son muchas o el mismo agente se llama miles de veces al día. Por debajo de esa línea bastan un prompt bien escrito y un paso de recuperación, y las horas de ingeniería rinden más en otro sitio. Un chat de soporte con tope de diez mensajes no necesita compactación. Un clasificador no necesita un archivo de memoria.

Dos límites que conviene decir en voz alta. El context engineering no repara un índice malo: si el vector store devuelve los tres documentos equivocados, una gestión cuidadosa de la ventana entrega los tres documentos equivocados con más eficiencia. Y no elimina la evaluación. Casi todos los movimientos de arriba son compromisos con un parámetro que hay que ajustar, y la única forma de saber dónde ponerlo es medir el éxito de las tareas en ejecuciones largas, no en la demo.

¿Disciplina real o etiqueta nueva?

Un poco de cada. El informe State of Context Management 2026 de DataHub recoge que el 82% de responsables de IT y datos dice que el prompt engineering por sí solo ya no sostiene la IA a escala, y que el 95% considera importante el context engineering para hacer funcionar agentes a escala (DataHub, 2026). Las encuestas de un proveedor sobre una categoría suelen descubrir que esa categoría importa, así que los números se cogen con pinzas. El movimiento de fondo sí es real y aparece antes en la investigación que en el marketing: los puntos de fallo se movieron de cómo formulas una petición a qué tenía el modelo en la mano al responder. El nombre del puesto es nuevo. El trabajo es diseño de recuperación, caché y gestión de estado, algo que en backend se hace desde hace veinte años con otros nombres.

Conceptos cercanos

• La ventana de contexto como presupuesto de tokens, la versión diaria de la misma disciplina dentro de un agente de código.
• Las skills, donde la divulgación progresiva mantiene la capacidad fuera de la ventana hasta que se llama.
• Los patrones multiagente, para cuando una sola ventana limpia no llega.

La lección práctica es más pequeña que el ruido que la rodea. Trata la ventana de contexto como un recurso escaso, ordenado, caro y con responsable; mide qué la llena; retira cosas por calendario en lugar de esperar a que el modelo empiece a fallar. Casi todos los problemas de fiabilidad que vemos en agentes en producción son problemas de suministro, y el suministro se arregla.