Ingeniería de contexto: cómo construir agentes de IA fiables en producción
La ingeniería de contexto (context engineering) es la disciplina de decidir qué información entra en la ventana de contexto de un modelo en cada paso de inferencia, y qué se queda fuera. En 2026, con modelos que ya son sobradamente capaces, es la variable que más separa a un agente que funciona en producción de una demo que se rompe a la tercera herramienta. No es prompt engineering con otro nombre: el prompt es una parte, pero el contexto incluye también las instrucciones de sistema, las definiciones de herramientas, los resultados que devuelven esas herramientas, la memoria, los documentos recuperados y todo el historial de la conversación.
Si estás construyendo un agente y notas que "empieza bien pero se degrada", que ignora instrucciones que sí están en el prompt, o que la factura de tokens se dispara sin que mejore la calidad, el problema casi nunca es el modelo. Es el contexto.
Qué es exactamente la ingeniería de contexto
Un modelo de lenguaje no tiene estado. En cada llamada solo "sabe" lo que le cabe en su ventana de contexto. La ingeniería de contexto es el conjunto de técnicas para curar ese conjunto finito de tokens de forma que el modelo tenga justo lo que necesita —ni más, ni menos— para dar el siguiente paso correcto.
La diferencia con el prompt engineering clásico es de alcance:
- Prompt engineering: escribir bien una instrucción concreta para una tarea concreta (una clasificación, un resumen).
- Context engineering: gestionar dinámicamente todo lo que el modelo ve a lo largo de un flujo de muchos pasos, donde el estado cambia en cada turno y el historial crece sin parar.
Anthropic lo resume bien: cuando construyes agentes, el trabajo deja de ser "encontrar las palabras mágicas" y pasa a ser "encontrar, en cada iteración, el conjunto mínimo de tokens de alta señal que maximiza la probabilidad del resultado deseado".
Por qué en 2026 el contexto pesa más que el modelo
Durante 2024 y 2025 la conversación giraba en torno a qué modelo era más listo. Esa pregunta importa cada vez menos: los modelos frontera de Anthropic, Google y OpenAI están, para la mayoría de tareas de producto, por encima del umbral de capacidad necesario. La ventaja competitiva se ha desplazado a cómo alimentas al modelo.
Y hay una razón técnica, no de moda: la atención de un transformer no es gratis. Cada token atiende a todos los demás, lo que genera relaciones de orden n². Una ventana de contexto de un millón de tokens no significa que puedas usar un millón de tokens sin coste. El presupuesto de atención del modelo es finito, y cuanto más lo llenas de ruido, peor recupera la señal relevante. El contexto es un recurso que se agota, y hay que tratarlo como tal.
El enemigo silencioso: context rot (y sus variantes)
El fallo más común en agentes de producción tiene nombre: context rot (degradación por contexto). A medida que crece el número de tokens, el modelo tiene más dificultad para localizar la información importante entre el ruido. El síntoma clásico: un agente que a los 5 pasos razona de maravilla y a los 40 empieza a alucinar, olvidar instrucciones o repetir acciones.
Conviene distinguir cuatro modos de fallo relacionados, porque cada uno se trata distinto:
- Context rot: demasiados tokens; la señal se diluye. Se ataca reduciendo y comprimiendo.
- Context poisoning: una alucinación o un dato erróneo entra en el contexto y se arrastra en cada paso siguiente, contaminando el razonamiento.
- Context distraction: información irrelevante pero verosímil que desvía al modelo de la tarea.
- Context clash: dos fragmentos del contexto se contradicen y el modelo no sabe a cuál hacer caso (típico al mezclar documentos de distintas versiones).
Reconocer cuál de estos cuatro estás sufriendo es el 80% del diagnóstico.
Las técnicas que funcionan (y cuándo usarlas)
No existe una solución única. La ingeniería de contexto es un conjunto de herramientas, y elegir bien depende de la forma de tu agente.
1. Recuperación selectiva (RAG con reranking)
En lugar de meter toda la base de conocimiento en el prompt, recuperas solo los fragmentos relevantes para la consulta actual. La clave en 2026 no es el retrieval en sí —eso ya es estándar— sino el reranking: recuperar 50 candidatos con alta cobertura y reordenarlos a un top-5 preciso suele funcionar mucho mejor que volcar los 50 al prompt. Para consultas holísticas ("resume todo lo que sabemos de X"), combinar recuperación vectorial con GraphRAG cubre la mayoría de necesidades.
2. Compactación (compaction)
Cuando la conversación se acerca al límite de la ventana, se resume el historial y se reinicia un contexto nuevo con ese resumen. Es lo que hace Claude Code al "compactar": pasa el historial al modelo para que lo comprima preservando decisiones de arquitectura, bugs sin resolver y detalles de implementación, y descarta lo accesorio. Imprescindible en agentes de larga duración.
3. Notas persistentes / memoria externa
Guardar información fuera de la ventana de contexto —en ficheros, en una base de datos, en un scratchpad— y recuperarla solo cuando hace falta. Permite que el agente mantenga estado a lo largo de sesiones sin cargar con todo el historial en cada llamada.
4. Aislamiento con sub-agentes
En vez de un único agente que lo acumula todo, un agente principal delega tareas concretas en sub-agentes especializados. Cada sub-agente hace su trabajo con su propio contexto acotado y devuelve solo un resumen condensado. El contexto detallado de la búsqueda se queda dentro del sub-agente; el agente líder solo ve conclusiones. Es la mejor forma de escalar tareas complejas sin reventar la ventana.
5. Curación de resultados de herramientas
Una herramienta que devuelve un JSON de 10.000 tokens envenena el contexto de inmediato. Filtra, pagina y resume las respuestas de las herramientas antes de que entren en el contexto del modelo. Este punto es el que más subestiman los equipos y el que más rápido mejora la fiabilidad.
| Técnica | Qué problema resuelve | Cuándo no usarla |
|---|---|---|
| RAG + reranking | Base de conocimiento grande, consultas puntuales | Si el corpus cabe entero y es estable, mételo directo |
| Compactación | Agentes de larga duración | Tareas cortas de pocos turnos: añade latencia sin ganancia |
| Memoria externa | Estado entre sesiones | Flujos sin estado o de una sola pasada |
| Sub-agentes | Tareas complejas y paralelizables | Tareas lineales simples: la orquestación no compensa |
| Curación de herramientas | Herramientas con salidas grandes | Herramientas que ya devuelven poco y estructurado |
Cuándo NO hacer ingeniería de contexto
Esto es lo que no te van a contar los hilos de LinkedIn: la mayoría de los casos de uso no necesitan un agente, y muchos agentes no necesitan la mitad de estas técnicas.
- Si tu tarea es una sola llamada al modelo (clasificar, extraer, resumir un texto que cabe en el prompt), no montes retrieval ni memoria: un buen prompt basta.
- Si tu flujo tiene 3 o 4 pasos deterministas, probablemente quieras un workflow con llamadas encadenadas, no un agente autónomo. Es más barato, más predecible y más fácil de depurar.
- Cada técnica de este artículo añade latencia, coste y superficie de error. Introdúcelas cuando un problema concreto lo justifique, no de forma preventiva. Sobre-ingeniería del contexto es tan común como la sub-ingeniería, y más cara.
La regla que aplicamos: empieza con el contexto más simple que pueda funcionar y añade complejidad solo cuando midas un fallo real. Y para saber cuánto te cuesta cada token que dejas en el contexto, la ingeniería de contexto va de la mano del control de costes: lo tratamos en detalle en nuestra guía de FinOps para IA.
Cómo lo abordamos en Dribba
En Dribba llevamos desde 2011 construyendo producto digital, y desde hace años integramos IA aplicada en producto real —RAG empresarial, agentes y orquestación— con un equipo 100% senior in-house. Nuestra experiencia con agentes en producción se resume en tres principios:
- El contexto se diseña, no se acumula. Antes de escribir el primer prompt, decidimos qué debe ver el modelo en cada paso y, sobre todo, qué no.
- Instrumenta antes de optimizar. Sin trazas de qué entra en cada llamada y cuántos tokens cuesta, optimizar es adivinar.
- La arquitectura de contexto encaja con la de agentes. La forma en que un agente accede a herramientas y datos (vía MCP) y cómo coordina con otros agentes (vía A2A) condiciona directamente qué técnicas de contexto necesitas.
Conclusión
En 2026, elegir el modelo más potente es la parte fácil y cada vez menos determinante. La ingeniería de contexto —qué información entra, cómo se comprime, cuándo se recupera y qué se aísla— es lo que decide si tu agente aguanta en producción o se degrada al escalar. Y como toda buena ingeniería, buena parte del trabajo consiste en saber cuándo no añadir complejidad.
Si estás diseñando un agente o un producto con IA y quieres que aguante más allá de la demo, en Dribba te ayudamos a diseñarlo bien desde el contexto. Cuéntanos tu caso en nuestros servicios de desarrollo con IA.
