Ingeniería de contexto para agentes de IA: guía práctica (2026)
Qué es la ingeniería de contexto, en qué se diferencia de la ingeniería de prompts, las cuatro técnicas fundamentales, cómo se comparan los principales frameworks, cómo medirla y cómo aplicarla en sistemas multiagente.
Un agente de IA solo es tan bueno como la información que hay en su ventana de contexto en el momento en que decide qué hacer a continuación, y seleccionar esa información es el verdadero juego. Si la ingeniería de prompts consiste en escribir una buena instrucción, la ingeniería de contexto consiste en gestionar todo el entorno de información con el que trabaja el modelo: instrucciones del sistema, herramientas, documentos recuperados, memoria y el historial en curso de la tarea. A medida que los agentes asumen trabajos más largos y de varios pasos, esto se ha convertido en la palanca más importante para determinar si tienen éxito o se desmoronan silenciosamente. Esta guía explica qué es la ingeniería de contexto, en qué se diferencia de la ingeniería de prompts, cuáles son sus técnicas principales y cómo aplicarla en sistemas de agentes reales.
Por qué importa la ingeniería de contexto
La ingeniería de contexto importa porque los grandes modelos de lenguaje tienen una ventana de contexto finita, y la forma en que se llena esa ventana determina la calidad de cada decisión que toma el agente. Un modelo es tan bueno como la información que tiene delante: si le das demasiado poca, alucina; si le das demasiada, o del tipo incorrecto, su precisión se degrada.
Esto no es una preocupación teórica. Los investigadores han documentado un efecto de "perdido en el medio", por el cual los modelos utilizan de forma fiable la información situada al principio y al final de un contexto largo, pero pasan por alto los hechos enterrados en el medio. Los profesionales describen un problema relacionado al que llaman "podredumbre del contexto" (context rot): a medida que una conversación o la ejecución de un agente se alarga, se acumulan tokens irrelevantes, la relación señal-ruido cae y el modelo empieza a tomar peores decisiones. La ventana no se ha hecho más pequeña: se ha llenado de ruido.
Este cambio de terminología refleja un cambio real en la práctica. En 2025, voces destacadas de la IA —entre ellas Andrej Karpathy y Tobi Lütke, de Shopify— argumentaron que la "ingeniería de contexto" describe mucho mejor lo que hacen realmente quienes construyen aplicaciones serias basadas en LLM que la "ingeniería de prompts". Anthropic publicó una guía sobre ingeniería de contexto eficaz para agentes; equipos detrás de productos de agentes como Manus escribieron extensamente sobre las lecciones aprendidas al gestionar el contexto en producción. El consenso es claro: en los sistemas agénticos, el contexto es el producto.
¿Qué es la ingeniería de contexto?
La ingeniería de contexto es la disciplina de reunir el conjunto adecuado de tokens para un modelo en el momento de la inferencia, de modo que el modelo tenga exactamente lo que necesita para llevar a cabo la siguiente acción correcta, ni más ni menos. El "contexto" incluye todo lo que hay dentro de la ventana:
- Instrucciones del sistema: el rol del agente, sus restricciones y sus reglas de comportamiento
- Herramientas y sus definiciones: qué acciones puede realizar el agente y cómo se describen
- Conocimiento recuperado: documentos, resultados de búsqueda o filas de bases de datos incorporados para esta tarea
- Memoria: hechos trasladados desde una parte anterior de la sesión o de sesiones previas
- Historial de conversación y de acciones: el registro continuo de lo que se ha dicho y hecho
- La solicitud actual del usuario: el objetivo inmediato
La ingeniería de contexto es el conjunto de decisiones sobre qué va en cada uno de estos espacios, en qué forma y en qué momento. Trata la ventana de contexto como un recurso escaso y gestionado, en lugar de un cubo en el que se sigue vertiendo texto.
La ventana de contexto es un presupuesto de atención finito: la ingeniería de contexto decide qué ocupa cada espacio.
Ingeniería de contexto frente a ingeniería de prompts
La diferencia entre la ingeniería de contexto y la ingeniería de prompts es de alcance: la ingeniería de prompts optimiza una única instrucción, mientras que la ingeniería de contexto gestiona todo el entorno de información, dinámico, a lo largo de una tarea de varios pasos. La ingeniería de prompts es un subconjunto de la ingeniería de contexto.
| Ingeniería de prompts | Ingeniería de contexto | |
|---|---|---|
| Alcance | Un prompt / una instrucción | Toda la ventana de contexto a lo largo del tiempo |
| Estado | En su mayoría sin estado, de un solo uso | Con estado, evoluciona a lo largo de muchos pasos |
| Preocupación | Redacción, ejemplos, formato | Qué incluir, recuperar, recordar y descartar |
| Uso típico | Una única finalización o turno de chat | Agentes autónomos, tareas de larga duración |
| Fallo que evita | Una instrucción vaga o mal interpretada | Podredumbre del contexto, distracción, estado contradictorio |
La ingeniería de prompts sigue siendo importante: un prompt de sistema bien redactado forma parte de una buena ingeniería de contexto. Pero una vez que un agente se ejecuta durante decenas de pasos, invoca herramientas y acumula historial, la redacción de un único prompt deja de ser el cuello de botella. Lo que importa entonces es la disciplina que gestiona todo lo demás a su alrededor.
Las cuatro técnicas fundamentales
La mayor parte del trabajo de ingeniería de contexto se reduce a cuatro operaciones sobre la ventana de contexto. Una forma útil de recordarlas: escribir, seleccionar, comprimir y aislar.
Escribir, seleccionar, comprimir y aislar: las cuatro operaciones detrás de cada decisión de ingeniería de contexto.
1. Escribir: persistir el contexto fuera de la ventana
No todo lo que necesita el agente debería vivir en el prompt. Escribir contexto significa almacenar información de forma externa —blocs de notas, archivos, un almacén de memoria, una lista de tareas— de modo que sobreviva más allá de una única ventana y pueda recuperarse de forma deliberada. Un agente de larga duración que escribe su plan en un archivo y lo vuelve a leer se mantiene enfocado mucho mejor que uno que depende únicamente del historial de la conversación.
2. Seleccionar: incorporar solo lo que es relevante ahora
Seleccionar contexto es el arte de recuperar la información adecuada en el momento adecuado: el documento concreto, la decisión pasada relevante, la única definición de herramienta que necesita este paso. Aquí es donde viven la generación aumentada por recuperación (RAG), la búsqueda semántica y la selección inteligente de herramientas. El objetivo es la precisión: extraer los tres hechos relevantes, no los trescientos adyacentes.
3. Comprimir: reducir tokens manteniendo la señal
Comprimir el contexto significa resumir o podar para que la ventana contenga significado, no volumen. Las tácticas habituales incluyen resumir subtareas completadas, truncar salidas de herramientas demasiado extensas y sustituir historiales largos por un resumen condensado. La compresión es lo que permite a un agente trabajar en una tarea durante más tiempo del que permitiría, de otro modo, su ventana de contexto sin procesar.
4. Aislar: dividir el contexto entre agentes o límites
Aislar el contexto significa dar a las distintas partes de un problema sus propias ventanas limpias; por ejemplo, generar un subagente con solo el contexto que necesita para una subtarea y devolver únicamente el resultado. El aislamiento evita que una parte de un trabajo contamine otra, y es la base de los sistemas multiagente fiables.
Cómo se alinean los principales marcos de trabajo
Una fuente de confusión es que cada equipo importante utiliza su propio vocabulario para las mismas operaciones subyacentes. Anthropic, LangChain y proveedores de bases de datos de grafos como Neo4j describen todos la ingeniería de contexto de manera distinta, pero encajan perfectamente en las cuatro operaciones anteriores. Esta tabla las concilia:
| Operación (esta guía) | Planteamiento de Anthropic | Planteamiento de LangChain | Planteamiento de grafos de conocimiento / GraphRAG |
|---|---|---|---|
| Escribir (persistir fuera de la ventana) | Toma de notas estructurada, memoria del agente (NOTES.md, listas de tareas) | Store y State; herramientas que escriben mediante Command | Memoria a largo plazo; el propio grafo como almacén persistente |
| Seleccionar (recuperar lo relevante ahora) | Contexto justo a tiempo, búsqueda agéntica, recuperación híbrida | Selección dinámica de herramientas/mensajes; herramientas que leen | RAG híbrido, GraphRAG, "contexto mínimo viable" |
| Comprimir (reducir tokens, conservar la señal) | Compactación; gastar el "presupuesto de atención" con criterio | Resumen del ciclo de vida mediante middleware | Presupuesto de tokens/coste; la "pirámide de contexto" |
| Aislar (separar ventanas limpias) | Arquitecturas de subagentes que devuelven resúmenes destilados | Límites de ciclo de vida y subagentes | Traspasos y protocolos (por ejemplo, MCP) |
Si has leído esas fuentes y te ha parecido que estaban en desacuerdo, esta es la razón: están describiendo los mismos cuatro movimientos desde ángulos distintos. Elige el vocabulario que mejor encaje con tu stack: lo que importa son las operaciones.
Ingeniería de contexto para sistemas multiagente
En los sistemas multiagente, la ingeniería de contexto se convierte en un problema de coordinación: cada agente necesita suficiente contexto para hacer su trabajo, pero compartir demasiado genera ruido, coste y estados contradictorios. El patrón dominante es un orquestador que mantiene el plan de alto nivel y delega subtareas con un alcance estrecho a subagentes especializados, cada uno operando en una ventana aislada.
Cada subagente recibe una ventana limpia y aislada, y devuelve solo un resultado destilado, lo que evita la contaminación cruzada.
Esto funciona gracias al principio de "aislar" anterior. Un subagente de investigación que solo ve la pregunta de investigación y sus propios hallazgos superará a uno que además tenga que abrirse paso por el historial no relacionado de la tarea de codificación de un agente hermano. El orquestador comprime después la salida de cada subagente hasta el resultado esencial antes de incorporarla de nuevo al contexto principal. Bien hecho, así es como los equipos ejecutan agentes en tareas que desbordarían muchas veces cualquier ventana de contexto individual.
Modos de fallo habituales de la ingeniería de contexto
La mayoría de los fallos de los agentes se remontan a un puñado de problemas de contexto recurrentes. Nombrarlos facilita diseñar en su contra:
| Modo de fallo | Cómo se manifiesta | Solución principal |
|---|---|---|
| Envenenamiento del contexto | Una alucinación o un error entran en el contexto y se referencian una y otra vez, agravando el error | Aislar + escribir solo hechos verificados |
| Distracción del contexto | La ventana crece tanto que el modelo se centra en exceso en el historial acumulado y deja de razonar sobre el objetivo real | Comprimir |
| Confusión del contexto | La información irrelevante satura la ventana e induce al modelo a una elección equivocada | Seleccionar de forma más estrecha |
| Choque de contexto | La información recién recuperada contradice lo que ya hay en la ventana, y el modelo no puede reconciliar ambas | Seleccionar + escribir hacia una única fuente de verdad |
Las cuatro técnicas fundamentales son los antídotos: escribir para descargar, seleccionar para mantenerse relevante, comprimir para reducir el desorden y aislar para evitar la contaminación cruzada.
Un modo de fallo que las guías populares rara vez cubren es de seguridad: la inyección de prompts a través del contexto recuperado. Cuando un agente incorpora una página web, un documento o el resultado de una herramienta, ese contenido puede incluir instrucciones diseñadas para secuestrar al agente. Trata todo lo que selecciones hacia la ventana como entrada no confiable: mantén los datos recuperados separados de las instrucciones del sistema y ejecuta las herramientas en un sandbox en lugar de directamente en una máquina de confianza.
Cómo medir si la ingeniería de contexto funciona
La ingeniería de contexto se mide comparando el éxito de la tarea con los tokens y el tiempo que cuesta lograrlo: una buena ingeniería de contexto eleva la tasa de éxito manteniendo o reduciendo el coste. La mayoría de las guías describen técnicas, pero nunca explican cómo saber si están funcionando; estas son las métricas que cierran esa brecha.
- Tasa de éxito de la tarea: la proporción de ejecuciones que alcanzan un resultado correcto y completo. Esta es la métrica de resultado; todo lo demás es un medio para lograrla. Haz seguimiento comparándola con un conjunto fijo de evaluación de tareas representativas, para poder comparar el antes y el después de cada cambio.
- Eficiencia del contexto (tokens por tarea exitosa): total de tokens consumidos dividido entre las finalizaciones exitosas. Una reducción de tokens por éxito es la señal más clara de que la compresión y la selección están dando resultado.
- Utilización de la ventana: cuán llena está la ventana de contexto durante una tarea. Estar sistemáticamente cerca del límite predice la podredumbre del contexto; es un indicador adelantado de que hace falta comprimir o aislar.
- Precisión y exhaustividad de la recuperación: de los elementos seleccionados en la ventana, cuántos eran realmente relevantes (precisión), y de los elementos relevantes disponibles, cuántos se incorporaron (exhaustividad). Una precisión baja significa que se está añadiendo ruido; una exhaustividad baja significa que se está privando de información al modelo.
- Latencia y coste por tarea: el techo práctico. La exploración agresiva "justo a tiempo" puede mejorar la precisión pero ralentizar al agente; esta métrica mantiene honesto ese equilibrio.
La disciplina que une todo esto son las pruebas de regresión: mantener una suite de tareas fijas, ejecutarla después de cada cambio en los prompts, la recuperación o la memoria, y observar cómo se mueven los números. La ingeniería de contexto sin un bucle de evaluación es adivinar a ciegas.
Cómo aplica Happycapy la ingeniería de contexto
Happycapy es un ordenador nativo para agentes que ejecuta agentes de IA —incluido Claude Code— directamente en el navegador, y la ingeniería de contexto está integrada en el funcionamiento de esos agentes, en lugar de dejarse en manos del usuario. Tres decisiones de diseño hacen la mayor parte del trabajo:
- Habilidades como contexto delimitado. En lugar de volcar todas las capacidades en un único prompt, Happycapy permite que un agente incorpore una habilidad (skill) concreta —diseñar una presentación, analizar una hoja de cálculo, hacer investigación web— de modo que solo las instrucciones y herramientas relevantes entran en la ventana para esa tarea. Eso es aplicar por defecto los principios de "seleccionar" y "aislar".
- Un sandbox persistente con memoria y archivos. Cada agente trabaja en un espacio de trabajo aislado donde puede escribir planes, resultados intermedios y notas en disco y recuperarlos más tarde: el principio de "escribir", de modo que el progreso sobrevive más allá de una única ventana de contexto.
- Acceso a más de 150 modelos. Distintos pasos tienen distintas necesidades de contexto; dirigir el trabajo hacia un modelo adecuado es, en sí mismo, una decisión de ingeniería de contexto.
El resultado práctico es que puedes delegar una tarea larga de varios pasos y dejar que el agente gestione su propio contexto en segundo plano, para luego recibir el resultado final, sin tener que ajustar los prompts a mano ni vigilar la ventana tú mismo.
Cómo empezar con la ingeniería de contexto
No es necesario reconstruir todo tu stack para empezar. Comienza con los hábitos de mayor impacto:
- Trata la ventana de contexto como un presupuesto. Antes de añadir algo, pregúntate si se gana sus tokens.
- Saca el estado del prompt. Usa archivos, blocs de notas o un almacén de memoria para todo lo que el agente necesite conservar.
- Recupera con precisión. Extrae los hechos concretos que necesita un paso, no documentos enteros.
- Resume sobre la marcha. Sustituye historiales largos y salidas de herramientas demasiado detalladas por resúmenes ajustados.
- Aísla las subtareas. Da a cada trabajo diferenciado su propio contexto limpio, especialmente en configuraciones multiagente.
Si prefieres no ajustar nada de esto a mano, Happycapy ejecuta tus tareas con estos patrones ya integrados en el agente: gestiona su propia ventana de contexto en segundo plano —seleccionando, compactando y aislando a medida que avanza— para que tú describas el resultado deseado y nunca tengas que tocar el presupuesto de tokens.
Preguntas frecuentes
P: ¿Es la ingeniería de contexto lo mismo que la ingeniería de prompts?
No. La ingeniería de prompts optimiza una única instrucción; la ingeniería de contexto gestiona todo el entorno de información que ve un agente a lo largo de una tarea de varios pasos: instrucciones, herramientas, datos recuperados, memoria e historial. La ingeniería de prompts es una parte de la ingeniería de contexto.
P: ¿Por qué es importante la ingeniería de contexto específicamente para los agentes de IA?
Porque los agentes se ejecutan durante muchos pasos, invocan herramientas y acumulan historial, su ventana de contexto se llena rápidamente. Sin una gestión activa, los tokens irrelevantes desplazan a la señal y las decisiones del agente se degradan, un problema conocido como podredumbre del contexto. La ingeniería de contexto mantiene la ventana enfocada en lo que importa.
P: ¿Cuáles son las principales técnicas de ingeniería de contexto?
Las cuatro técnicas fundamentales son escribir (persistir el contexto fuera de la ventana), seleccionar (recuperar solo lo relevante ahora), comprimir (resumir para ahorrar tokens) y aislar (dar a las subtareas su propio contexto limpio). La mayor parte del trabajo práctico es alguna combinación de estas.
P: ¿Es la ingeniería de contexto una habilidad que merece la pena aprender en 2026?
Sí. A medida que se construye más software sobre LLM y agentes autónomos, la capacidad de gestionar bien el contexto se está convirtiendo en una competencia clave para desarrolladores, diseñadores de prompts y equipos de producto de IA, y cada vez marca más la diferencia entre un agente que funciona y uno que no.
P: ¿Cómo se mide si la ingeniería de contexto está funcionando?
Haciendo seguimiento de la tasa de éxito de la tarea frente a un conjunto de evaluación, junto con métricas de eficiencia: tokens por tarea exitosa, utilización de la ventana de contexto, precisión y exhaustividad de la recuperación, y latencia/coste por tarea. Una buena ingeniería de contexto aumenta la tasa de éxito manteniendo o reduciendo el coste. Ejecuta la suite tras cada cambio para poder comprobar si un ajuste ayudó o perjudicó.
P: ¿Necesito hacer yo mismo la ingeniería de contexto para usar agentes de IA?
No necesariamente. Plataformas de agentes como Happycapy integran la gestión del contexto en el sistema —delimitando el contexto con habilidades, persistiendo el estado en un sandbox y aislando subtareas— para que puedas ejecutar trabajo de varios pasos sin ajustar la ventana de contexto manualmente.
