Volver
Ingeniería de contexto para agentes de IA: una guía práctica (2026)
June 13, 2026
13 min de lectura
Comparte este artículo

Ingeniería de contexto para agentes de IA: una 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 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 curar esa información es todo el juego. Si la ingeniería de prompts consiste en escribir una buena instrucción, la ingeniería de contexto es gestionar todo el entorno de información en 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 múltiples pasos, esto se ha convertido en la palanca individual más importante para determinar si tienen éxito o si fallan silenciosamente. Esta guía cubre qué es la ingeniería de contexto, en qué se diferencia de la ingeniería de prompts, las técnicas fundamentales 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 modelos de lenguaje grandes tienen una ventana de contexto finita, y la forma en que llenas 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: dale muy poca y alucinará; dale demasiada o del tipo equivocado, y su precisión se degradará.

Esto no es una preocupación teórica. Los investigadores han documentado un efecto "perdido en el medio", en el que los modelos usan de forma confiable la información 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 "context rot" (degradación del contexto): 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 hizo más pequeña, se llenó de ruido.

El cambio en la terminología refleja un cambio real en la práctica. En 2025, voces líderes en IA —incluyendo a Andrej Karpathy y Tobi Lütke de Shopify— argumentaron que "ingeniería de contexto" describe mucho mejor lo que hacen realmente quienes construyen aplicaciones serias con LLM que "ingeniería de prompts". Anthropic publicó orientación sobre ingeniería de contexto efectiva para agentes; los equipos detrás de productos de agentes como Manus escribieron extensamente sobre las lecciones que aprendieron gestionando el contexto en producción. El consenso: para 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 ensamblar el conjunto correcto de tokens para un modelo en el momento de la inferencia, de modo que el modelo tenga exactamente lo que necesita para tomar 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 reglas de comportamiento
  • Herramientas y sus definiciones — qué acciones puede tomar el agente y cómo se describen
  • Conocimiento recuperado — documentos, resultados de búsqueda o filas de bases de datos traídas para esta tarea
  • Memoria — hechos trasladados de una parte anterior de la sesión o de sesiones previas
  • Historial de conversación y de acciones — el registro en curso 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 cuándo. Trata la ventana de contexto como un recurso escaso y gestionado, en lugar de un balde en el que sigues vertiendo texto.

Diagrama de la ventana de contexto de un agente de IA que muestra las instrucciones del sistema, herramientas, conocimiento recuperado, memoria, historial de conversación y la solicitud del usuario compitiendo por un presupuesto de atención finito La ventana de contexto es un presupuesto de atención finito: la ingeniería de contexto decide qué llena cada espacio.

Ingeniería de contexto vs. ingeniería de prompts

La diferencia entre la ingeniería de contexto y la ingeniería de prompts es una cuestión 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 múltiples pasos. La ingeniería de prompts es un subconjunto de la ingeniería de contexto.

Ingeniería de promptsIngeniería de contexto
AlcanceUn solo prompt / instrucciónToda la ventana de contexto a lo largo del tiempo
EstadoMayormente sin estado, de una sola vezCon estado, evoluciona a lo largo de muchos pasos
EnfoqueRedacción, ejemplos, formatoQué incluir, recuperar, recordar y descartar
Uso típicoUna sola completación o turno de chatAgentes autónomos, tareas de larga duración
Fallo que previeneUna instrucción vaga o malinterpretadaDegradación 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 docenas de pasos, llama herramientas y acumula historial, la redacción de un único prompt deja de ser el cuello de botella. Lo que importa es la disciplina que gestiona todo lo que lo rodea.

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.

Las cuatro técnicas fundamentales de la ingeniería de contexto: escribir (persistir el contexto fuera de la ventana), seleccionar (recuperar solo lo relevante ahora), comprimir (reducir tokens conservando la señal) y aislar (dar a las subtareas su propia ventana limpia) 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 el agente necesita debe 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— para que sobreviva más allá de una sola ventana y pueda recuperarse deliberadamente. Un agente de larga duración que escribe su plan en un archivo y lo vuelve a leer se mantiene en el rumbo mucho mejor que uno que depende únicamente del historial de la conversación.

2. Seleccionar — traer solo lo relevante ahora

Seleccionar contexto es el arte de recuperar la información correcta en el momento correcto: el documento específico, 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 conservando la señal

Comprimir el contexto significa resumir o podar para que la ventana contenga significado, no volumen. Las tácticas comunes incluyen resumir subtareas completadas, truncar salidas verbosas de herramientas y reemplazar historiales largos con un resumen condensado. La compresión es lo que le permite a un agente trabajar en una tarea más tiempo del que permitiría su ventana de contexto sin procesar.

4. Aislar — dividir el contexto entre agentes o límites

Aislar el contexto significa dar a diferentes partes de un problema sus propias ventanas limpias; por ejemplo, generar un subagente con solo el contexto que necesita para una subtarea, y luego devolver solo el resultado. El aislamiento evita que una parte de un trabajo contamine otra y es la base de los sistemas multiagente confiables.

Cómo se alinean los principales frameworks

Una fuente de confusión es que cada equipo importante usa 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 diferente, pero se corresponden claramente con las cuatro operaciones anteriores. Esta tabla los concilia:

Operación (esta guía)El enfoque de AnthropicEl enfoque de LangChainEl enfoque 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 vía CommandMemoria 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íbridaSelección dinámica de herramientas/mensajes; herramientas que leenRAG híbrido, GraphRAG, "contexto mínimo viable"
Comprimir (reducir tokens, conservar la señal)Compactación; gastar sabiamente el "presupuesto de atención"Resumen de ciclo de vida vía middlewarePresupuesto de tokens/costos; la "pirámide de contexto"
Aislar (separar ventanas limpias)Arquitecturas de subagentes que devuelven resúmenes destiladosLímites de ciclo de vida y subagentesTraspasos y protocolos (p. ej., MCP)

Si has leído esas fuentes y sentiste que no coincidían, esta es la razón: están describiendo los mismos cuatro movimientos desde ángulos diferentes. Elige el vocabulario que mejor se ajuste a 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 crea ruido, costo y estado contradictorio. El patrón dominante es un orquestador que mantiene el plan de alto nivel y delega subtareas de alcance limitado a subagentes especializados, cada uno operando en una ventana aislada.

Diagrama de un sistema multiagente donde un orquestador delega subtareas específicas a un agente de investigación, un agente de programación y un agente de redacción, cada uno trabajando en su propia ventana de contexto aislada y devolviendo solo un resultado destilado Cada subagente obtiene una ventana limpia y aislada, y devuelve solo un resultado destilado, evitando la contaminación cruzada.

Esto funciona gracias al principio de "aislar" mencionado antes. Un subagente de investigación que solo ve la pregunta de investigación y sus propios hallazgos superará a uno que también tiene que abrirse paso a través del historial no relacionado de la tarea de programación de un agente hermano. El orquestador luego comprime la salida de cada subagente hasta el resultado esencial antes de incorporarla nuevamente al contexto principal. Bien hecho, así es como los equipos ejecutan agentes en tareas que desbordarían cualquier ventana de contexto individual muchas veces.

Modos de fallo comunes en 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 hace que sea más fácil diseñar contra ellos:

Modo de falloCómo se veSolución principal
Envenenamiento del contextoUna alucinación o error entra en el contexto y se referencia una y otra vez, agravando el errorAislar + escribir solo hechos verificados
Distracción del contextoLa ventana crece tanto que el modelo se sobreenfoca en el historial acumulado y deja de razonar sobre el objetivo realComprimir
Confusión del contextoInformación irrelevante satura la ventana y lleva al modelo a una elección equivocadaSeleccionar de forma más estrecha
Choque de contextoLa información recién recuperada contradice lo que ya está en la ventana, y el modelo no puede reconciliar ambasSeleccionar + 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 eliminar el desorden y aislar para evitar la contaminación cruzada.

Un modo de fallo que las guías populares rara vez cubren es uno de seguridad: la inyección de prompts a través del contexto recuperado. Cuando un agente trae una página web, un documento o el resultado de una herramienta, ese contenido puede contener 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 está funcionando

Mides la ingeniería de contexto rastreando el éxito de la tarea frente a los tokens y el tiempo que toma llegar ahí: una buena ingeniería de contexto eleva la tasa de éxito mientras mantiene o reduce el costo. La mayoría de las guías describen técnicas pero nunca dicen 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 llegan a un resultado correcto y completo. Esta es la métrica de resultado; todo lo demás es un medio para alcanzarla. Rastréala contra un conjunto de evaluación fijo de tareas representativas para poder comparar antes y después de cada cambio.
  • Eficiencia del contexto (tokens por tarea exitosa) — total de tokens consumidos dividido entre completaciones exitosas. Una caída en 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 — qué tan llena está la ventana de contexto durante una tarea. Estar constantemente cerca del límite predice la degradación del contexto; es un indicador adelantado de que necesitas comprimir o aislar.
  • Precisión y recall de la recuperación — de los elementos que seleccionaste hacia la ventana, cuántos eran realmente relevantes (precisión), y de los elementos relevantes disponibles, cuántos lograste incorporar (recall). Una precisión pobre significa que estás añadiendo ruido; un recall pobre significa que estás privando al modelo de información.
  • Latencia y costo por tarea — el límite 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 es la prueba de regresión: mantén un conjunto fijo de tareas, ejecútalo después de cada cambio en los prompts, la recuperación o la memoria, y observa cómo se mueven los números. La ingeniería de contexto sin un ciclo de evaluación es solo adivinar.

Cómo aplica Happycapy la ingeniería de contexto

Happycapy es una computadora nativa para agentes que ejecuta agentes de IA —incluyendo Claude Code— directamente en tu navegador, y la ingeniería de contexto está integrada en la forma en que esos agentes operan, 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 cada capacidad en un solo prompt, Happycapy permite que un agente incorpore una habilidad específica —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", para que el progreso sobreviva más allá de una sola ventana de contexto.
  • Acceso a más de 150 modelos. Diferentes pasos tienen diferentes necesidades de contexto; enrutar el trabajo hacia un modelo apropiado es en sí misma una decisión de ingeniería de contexto.

El resultado práctico es que puedes delegar una tarea larga y de múltiples pasos y dejar que el agente gestione su propio contexto en segundo plano, y luego recibir el resultado terminado, sin ajustar prompts a mano ni vigilar la ventana tú mismo.

Cómo empezar con la ingeniería de contexto

No necesitas reconstruir todo tu stack para empezar. Comienza con los hábitos de mayor impacto:

  1. Trata la ventana de contexto como un presupuesto. Antes de agregar algo, pregúntate si se gana sus tokens.
  2. Saca el estado del prompt. Usa archivos, blocs de notas o un almacén de memoria para todo lo que el agente necesite conservar.
  3. Recupera de forma acotada. Extrae los hechos específicos que un paso necesita, no documentos enteros.
  4. Resume sobre la marcha. Reemplaza historiales largos y salidas verbosas de herramientas con resúmenes ajustados.
  5. Aísla las subtareas. Dale a cada trabajo distinto su propio contexto limpio, especialmente en configuraciones multiagente.

Si prefieres no ajustar nada de esto manualmente, 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 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 múltiples 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, llaman herramientas y acumulan historial, su ventana de contexto se llena rápido. Sin una gestión activa, los tokens irrelevantes desplazan a la señal y las decisiones del agente se degradan, un problema conocido como degradación 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: ¿Vale la pena aprender ingeniería de contexto 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 central para desarrolladores, diseñadores de prompts y equipos de producto de IA, y cada vez más marca la diferencia entre un agente que funciona y uno que no.

P: ¿Cómo se mide si la ingeniería de contexto está funcionando?

Rastrea la tasa de éxito de la tarea contra un conjunto de evaluación, además de métricas de eficiencia: tokens por tarea exitosa, utilización de la ventana de contexto, precisión y recall de la recuperación, y latencia/costo por tarea. Una buena ingeniería de contexto aumenta la tasa de éxito mientras mantiene o reduce el costo. Ejecuta el conjunto de pruebas después de cada cambio para poder ver si un ajuste ayudó o perjudicó.

P: ¿Necesito hacer yo mismo la ingeniería de contexto para usar agentes de IA?

No necesariamente. Las 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 múltiples pasos sin ajustar manualmente la ventana de contexto.

Guías relacionadas

Publicado el June 13, 2026
Más artículos