Tabla de contenidos
Hay un momento en el desarrollo de un agente de IA en el que te das cuenta de que el problema no es el modelo. El modelo hace bien su trabajo. El problema es lo que le estás dando a leer. Un agente que empieza a cometer errores inexplicables a mitad de una conversación larga, que olvida instrucciones que estaban en el system prompt, o que responde con menos precisión que al principio de la sesión: eso no es un fallo del LLM, es un problema de lo que está entrando en su context window. Ahí es donde aparece el context engineering.
Si trabajas con agentes de IA para empresas, entender context engineering es tan importante como entender el modelo que usas. Este artículo explica qué es, cuál es el problema central que resuelve (el context rot) y cómo aplicarlo cuando el agente ya está en producción.
Qué es el context engineering (y por qué no es solo prompt engineering)
El context engineering es la disciplina que decide qué información entra en el context window de un modelo de lenguaje en cada momento de la ejecución. No es solo escribir bien el system prompt. Es gestionar activamente el espacio finito que tiene el modelo para «leer» en una llamada: qué instrucciones permanecen, qué fragmentos de conversación se conservan, qué documentos se recuperan del RAG, qué resultados de herramientas se incluyen y en qué formato.
El término lo popularizó Tobi Lütke, CEO de Shopify, a finales de 2024, describiéndolo como «el arte de llenar el context window». Desde entonces, el campo ha crecido rápidamente: en 2025 apareció el paper Context Engineering: From Prompts to Corporate Multi-Agent Architecture en arXiv (arXiv 2603.09619), que formaliza la disciplina y la distingue del prompt engineering clásico.
La diferencia entre prompt engineering y context engineering es de escala y de ciclo de vida:
| Dimensión | Prompt engineering | Context engineering |
|---|---|---|
| Objeto de optimización | El texto del prompt en sí | Todo lo que entra en el context window |
| Momento | Diseño inicial | Cada llamada al modelo, en tiempo real |
| Componentes | System prompt + user message | System prompt + memoria + RAG + historial + tool results |
| Problema central | ¿Cómo formulo la instrucción? | ¿Qué incluyo, qué descarto y en qué orden? |
| Aplicación | Chatbots simples, consultas únicas | Agentes multi-turno, pipelines largos |
Un prompt engineer trabaja principalmente en el momento de diseño. Un context engineer trabaja en el momento de ejecución: decide dinámicamente qué entra en cada llamada para que el modelo tenga el contexto justo que necesita, ni más ni menos. En castellano encontrarás también los términos «ingeniería de contexto» y «optimización de la ventana de contexto», pero el término consolidado en la industria (el que usan los papers, los frameworks y los equipos de ingeniería) es context engineering.
Context rot: cuando demasiado contexto destruye la calidad del agente
El context rot es el fenómeno por el que la precisión del modelo disminuye a medida que el context window se llena. No es intuitivo, porque asumimos que más información es siempre mejor. Pero los modelos de lenguaje tienen una atención que se dispersa cuando el contexto crece: la información relevante queda enterrada entre mensajes irrelevantes, resultados de herramientas redundantes y fragmentos de conversación que ya no importan.
Anthropic lo documenta en su guía de ingeniería: «Model accuracy decreases as context window tokens increase» (Anthropic Engineering — Effective Context Engineering). Lo que empieza como un agente que responde con precisión quirúrgica en las primeras interacciones se convierte, a medida que el historial crece, en un agente que comete errores que no cometía antes.
A nivel empresarial, el context rot se manifiesta de formas concretas: un agente de soporte que olvida la política de devoluciones que sí aplicaba al principio de la sesión; un agente de ventas que mezcla datos de dos clientes distintos porque el historial de ambas conversaciones está en el mismo contexto; un agente de análisis que ignora instrucciones del system prompt después de procesar un documento largo. Estos no son fallos del modelo, son fallos de gestión del contexto.
La solución al context rot no es usar modelos con context windows más grandes. Es decidir activamente qué entra y qué no entra en cada llamada. Eso es context engineering.
Los 6 elementos del context window
Para hacer context engineering, primero hay que saber qué puede entrar en el context window de un agente. Hay seis categorías principales, cada una con su función y su coste en tokens:
┌─────────────────────────────────────────────────────────┐ │ CONTEXT WINDOW │ │ │ │ ┌───────────────────┐ ┌───────────────────────────┐ │ │ │ SYSTEM PROMPT │ │ MEMORIA │ │ │ │ Instrucciones │ │ - Episódica (historial) │ │ │ │ Rol del agente │ │ - Semántica (hechos) │ │ │ │ Reglas y límites │ │ - Procedimental (pasos) │ │ │ └───────────────────┘ └───────────────────────────┘ │ │ │ │ ┌───────────────────┐ ┌───────────────────────────┐ │ │ │ HISTORIAL DE │ │ RAG │ │ │ │ CONVERSACIÓN │ │ Fragmentos recuperados │ │ │ │ Turnos anteriores │ │ de bases de conocimiento │ │ │ │ (filtrado) │ │ externas │ │ │ └───────────────────┘ └───────────────────────────┘ │ │ │ │ ┌───────────────────┐ ┌───────────────────────────┐ │ │ │ TOOL RESULTS │ │ INPUT DEL USUARIO │ │ │ │ Resultados de │ │ Mensaje actual │ │ │ │ herramientas y │ │ + archivos adjuntos │ │ │ │ llamadas API │ │ + metadata de sesión │ │ │ └───────────────────┘ └───────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘
Cada uno de estos seis bloques compite por espacio en un context window que es finito. GPT-4o tiene 128K tokens; Claude 3.7 llega a 200K; Gemini 1.5 Pro a 1M. Aunque esos números parecen grandes, en agentes que acumulan historial de conversación largo, resultados de herramientas y documentos de RAG, es posible llegar al límite en cuestión de minutos. Y mucho antes de llegar al límite técnico, aparece el context rot.
Entender los tipos de memoria en agentes de IA es el primer paso para saber qué poner en el bloque de memoria del diagrama: qué guardar como memoria episódica (el historial filtrado de acciones), qué como semántica (los hechos sobre el cliente o el dominio) y qué como procedimental (las instrucciones que no deben desaparecer del system prompt).
Técnicas prácticas de context engineering en producción
El context engineering no es teórico: se implementa con decisiones de diseño concretas que determinan cómo el agente gestiona su context window en cada llamada. Estas son las técnicas más efectivas para agentes en producción.
Compactación del historial. En lugar de incluir todos los turnos de conversación, el agente mantiene un resumen actualizado de la conversación que reemplaza el historial completo cuando supera un umbral de tokens. Claude lo describe en sus guías de implementación como «structured note-taking»: el agente escribe activamente un fichero NOTES.md que resume lo que sabe hasta el momento, y ese fichero reemplaza al historial cuando el contexto crece demasiado. La compactación se puede hacer con el mismo LLM (pidiendo al modelo que resuma) o con modelos ligeros más económicos.
Filtrado de tool results. Las llamadas a herramientas devuelven a menudo mucha más información de la que el agente necesita. Un resultado de búsqueda que devuelve 10 fragmentos de 500 tokens cada uno cuando el agente solo necesita el primero es un desperdicio de context window que acelera el context rot. El filtrado de tool results puede ser tan simple como truncar la respuesta antes de añadirla al contexto, o tan sofisticado como un clasificador ligero que decide qué fragmentos son relevantes para la tarea actual.
System prompt dinámico. En agentes complejos, parte del system prompt puede variar según el estado de la conversación o el tipo de tarea. En lugar de incluir instrucciones para todos los flujos posibles (lo que infla el system prompt con instrucciones que no aplican en el momento actual), el agente carga solo las instrucciones relevantes para la tarea en curso.
Ventanas deslizantes. Cuando la compactación no es suficiente, la técnica de la ventana deslizante mantiene solo los N últimos turnos de conversación en el contexto. Es una solución brutal pero efectiva: asegura que el contexto siempre tenga un tamaño manejable, aunque pierde información de turnos anteriores. Se combina bien con la memoria persistente: lo que se pierde de la ventana se puede recuperar si el agente lo escribió en su memoria.
Priorización por relevancia. Antes de construir el context window para cada llamada, el agente puede puntuar cada elemento (fragmento de memoria, resultado de RAG, turno de conversación) por su relevancia para la consulta actual y ordenarlos de mayor a menor relevancia. Los elementos menos relevantes se descartan si el presupuesto de tokens se agota. Esta priorización se complementa bien con el Model Context Protocol, que estandariza cómo cada fuente de datos externa declara qué información expone al agente, lo que simplifica considerablemente la lógica de selección y filtrado.
Context engineering y memoria: cómo se complementan
La memoria es la herramienta principal del context engineer. Sin un sistema de memoria bien diseñado, el context engineering se reduce a técnicas de recorte que palian el síntoma (el context window lleno) sin atacar la causa (no hay dónde guardar lo que importa). Con memoria persistente, el agente puede descargar del context window la información que no necesita ahora pero sí necesitará más adelante, sabiendo que puede recuperarla cuando la necesite.
La relación entre context engineering y memoria funciona así: el context engineer decide qué información es suficientemente importante para persistir en la memoria del agente (en lugar de quedarse solo en el historial de la conversación, que se descartará cuando el contexto se compacte). La memoria persistente del agente no es un bloque monolítico: hay información que debe estar siempre en el context window (las instrucciones del system prompt, las preferencias del cliente), información que se recupera bajo demanda (el historial de pedidos, los tickets anteriores) y información que se descarta cuando ya no es relevante.
Anthropic describe en su guía de implementación cómo agentes bien diseñados mantienen ficheros de notas estructuradas (NOTES.md, USER.md, SOUL.md) que actúan como memoria de trabajo compacta: el agente escribe en estos ficheros después de cada sesión, y los carga al inicio de la siguiente. Este patrón reduce radicalmente el coste de tokens por sesión y elimina el context rot porque el context window de cada nueva sesión empieza limpio, con solo la información relevante del fichero de notas.
RAG como herramienta de context engineering
El RAG (Retrieval-Augmented Generation) es, desde la perspectiva del context engineering, una técnica para traer al context window solo los fragmentos de conocimiento que son relevantes para la consulta actual, en lugar de cargar toda la base de conocimiento de una vez. Un agente que tiene acceso a un catálogo de 10.000 productos no necesita esos 10.000 productos en su context window: necesita los 5 o 10 que son relevantes para la pregunta del cliente en este momento.
El RAG bien implementado resuelve dos problemas de context engineering simultáneamente: mantiene el context window pequeño (porque recupera solo lo necesario) y mejora la precisión del agente (porque la información que entra es relevante, no ruido). El Model Context Protocol de Anthropic va un paso más allá: estandariza cómo los agentes se conectan a fuentes de datos externas (bases de datos, APIs, servicios) de forma que el context engineer puede decidir exactamente qué información entra en el contexto en cada momento, con una capa de control explícita.
A nivel práctico, la calidad del RAG en un sistema de context engineering depende de tres variables: la calidad de los embeddings (qué tan bien representa el sistema de vectores el significado de los fragmentos), el tamaño de los chunks (fragmentos demasiado grandes traen ruido, demasiado pequeños pierden contexto), y la estrategia de reranking (cómo se priorizan los fragmentos recuperados antes de añadirlos al contexto). Un context engineer que optimiza estas tres variables puede reducir a la mitad el número de tokens por llamada manteniendo o mejorando la calidad de las respuestas.
Preguntas frecuentes
¿Qué es el context engineering?
El context engineering es la disciplina que decide qué información entra en el context window de un modelo de lenguaje en cada llamada. A diferencia del prompt engineering, que optimiza el texto del prompt en el momento de diseño, el context engineering gestiona dinámicamente todos los elementos que el modelo puede leer durante la ejecución: el system prompt, el historial de conversación, los fragmentos de RAG, los resultados de herramientas y la memoria persistente del agente. El objetivo es que el modelo tenga siempre el contexto justo que necesita, ni más ni menos, para evitar el context rot y maximizar la calidad de las respuestas.
¿En qué se diferencia del prompt engineering?
El prompt engineering trabaja principalmente sobre el texto de las instrucciones: cómo formular el system prompt, qué ejemplos few-shot incluir, qué formato de respuesta pedir. El context engineering trabaja sobre todo lo que rodea a esas instrucciones: qué fragmentos del historial de conversación incluir, qué documentos recuperar del RAG, qué resultados de herramientas añadir y en qué orden. El prompt engineering es una subdisciplina del context engineering. En agentes simples de un solo turno, el prompt engineering suele ser suficiente. En agentes multi-turno en producción, el context engineering es imprescindible.
¿Qué es el context rot?
El context rot es el fenómeno por el que la precisión del modelo disminuye a medida que el context window se llena de información. Cuando el contexto contiene demasiados turnos de conversación, demasiados resultados de herramientas o demasiados fragmentos de RAG que ya no son relevantes, la atención del modelo se dispersa y la calidad de las respuestas baja. Anthropic lo documenta en su guía de context engineering, donde señala que la precisión del modelo decrece conforme aumentan los tokens en contexto. El context rot no se soluciona con modelos de context window más grande: se soluciona gestionando activamente qué entra y qué se descarta en cada llamada.
¿Qué tamaño tiene el context window de los modelos actuales?
En 2026, los modelos más usados tienen context windows que van desde los 128K tokens de GPT-4o hasta el millón de tokens de Gemini 1.5 Pro, pasando por los 200K de Claude 3.7. Sin embargo, el tamaño técnico del context window no es el límite real del agente: el context rot aparece mucho antes de llegar al límite. Además, cada token en el context window tiene un coste económico directo en inferencia. Un agente con un context window cuidadosamente optimizado de 20K tokens puede ser más preciso y más barato que uno que llena ciegamente los 128K disponibles con historial y resultados de herramientas no filtrados.
¿Cómo se relaciona el context engineering con la memoria del agente?
La memoria es la herramienta principal del context engineer. Un sistema de memoria bien diseñado permite descargar del context window la información que no se necesita ahora pero sí más adelante: el agente la persiste en memoria y la recupera bajo demanda. Sin memoria, el context engineering se limita a técnicas de recorte que palian el síntoma. Con memoria, el context engineer puede diseñar agentes que arrancan cada sesión con un context window limpio, cargando solo las variables clave del cliente y la historia relevante. Esto elimina el context rot y reduce el coste por sesión en producción.
¿Necesito context engineering para un agente sencillo?
Para un agente de un solo turno (el usuario hace una pregunta y el agente responde una vez, sin historial), el context engineering es prácticamente innecesario: con un buen prompt y, opcionalmente, RAG bien configurado, el agente funciona correctamente. El context engineering se vuelve imprescindible cuando el agente tiene conversaciones largas (más de 10-15 turnos), cuando maneja múltiples usuarios simultáneamente (y cada uno necesita su contexto separado), cuando usa herramientas externas que devuelven resultados voluminosos, o cuando el coste de los tokens en producción es una variable relevante para el negocio. Si estás construyendo tu primer agente, puedes ignorar el context engineering hasta que el agente esté en producción y empieces a ver los primeros síntomas de context rot.
Implementa context engineering en tu empresa
El context engineering no es una disciplina para equipos de investigación. Es una necesidad práctica para cualquier empresa que haya puesto un agente en producción y empiece a ver cómo su precisión se degrada con el uso. La buena noticia es que no hace falta rediseñar el agente desde cero: las técnicas de compactación del historial, filtrado de tool results y memoria de sesión se pueden añadir de forma incremental, priorizando los puntos donde el context rot genera más coste operativo o más errores visibles.
Si estás en ese punto (un agente funcionando pero con comportamientos erráticos en conversaciones largas, o un coste de inferencia que crece sin que la calidad crezca proporcionalmente) es el momento de revisar la arquitectura de contexto. En Baigency trabajamos con PYMEs que ya tienen agentes desplegados y quieren llevarlos al siguiente nivel. Si quieres analizar cómo está gestionando el contexto tu agente y qué técnicas tienen más impacto en tu caso concreto, podemos ayudarte desde la consultoría de IA.
