La mayoría de los agentes de IA que no rinden en producción no tienen un problema de modelo: tienen un problema de contexto. La ingeniería de contexto es la disciplina de decidir, de forma deliberada, qué ve el modelo en cada llamada —system prompt, entrada del usuario, historial, documentos recuperados, definiciones de herramientas y memoria— para que responda bien, barato y de forma predecible. Cambiar de modelo rara vez arregla lo que un contexto mal diseñado rompe.
En Dribba llevamos integrando LLMs, RAG y agentes en producto real desde antes de que "agente" fuera una palabra de marketing. Este es el marco con el que trabajamos y, sobre todo, las decisiones donde vemos fallar a más equipos.
Qué es (y qué no es) la ingeniería de contexto
Durante 2023 y 2024 la conversación era el prompt engineering: cómo redactar la instrucción perfecta. Eso ya no es el cuello de botella. Con agentes que encadenan decenas de llamadas, invocan herramientas y arrastran historial, el problema deja de ser cómo pides las cosas y pasa a ser qué información tiene el modelo delante en el turno 30.
La ingeniería de contexto es esa segunda disciplina: gestionar la ventana de contexto como el recurso escaso que es. No es escribir un prompt más largo. De hecho, casi siempre es lo contrario: quitar, no añadir.
Definición corta: ingeniería de contexto es diseñar deliberadamente el conjunto de tokens que entran en cada inferencia —instrucciones, datos recuperados, historial, herramientas y memoria— para maximizar la calidad de la respuesta minimizando el ruido y el coste.
El contexto es un presupuesto, no un cubo
El error mental más común es tratar la ventana de contexto como un cubo: "cabe un millón de tokens, pues meto todo lo que tengo". No funciona así por dos razones.
Coste y latencia. Cada token de entrada se paga y se procesa en cada llamada. Un agente que arrastra 40.000 tokens de historial innecesario en un flujo de 30 turnos no paga eso una vez: lo paga 30 veces. La factura y la latencia se disparan sin que mejore la respuesta.
Degradación de la atención. Más contexto no es más señal. Pasado cierto punto, el modelo se distrae con información irrelevante, pierde lo importante en mitad de un historial gigante y baja su precisión. Ventana grande ≠ ventana bien usada.
La consecuencia práctica: trata el contexto como un presupuesto por turno. Cada token que metes tiene que ganarse su sitio.
Las cuatro formas en que un contexto se pudre
Cuando un agente empieza a dar respuestas raras, casi siempre es uno de estos cuatro fallos. Ponerles nombre ayuda a diagnosticar rápido:
- Envenenamiento (poisoning): una alucinación o un dato erróneo entra en el contexto y se arrastra turno tras turno como si fuera verdad. El agente construye sobre una premisa falsa.
- Saturación (overload): hay tanta información que la relevante queda enterrada. El modelo tiene los datos, pero no "los ve".
- Distracción: el historial acumulado empuja al modelo a repetir patrones pasados en vez de razonar sobre la tarea actual. Se nota en agentes largos que empiezan a dar vueltas.
- Conflicto (clash): dos fragmentos del contexto se contradicen —una instrucción antigua contra una nueva, dos documentos incompatibles— y el modelo elige mal.
Si no mides qué entra en la ventana en cada llamada, no vas a saber cuál de los cuatro te está pasando. La observabilidad del contexto no es opcional.
Las técnicas que sí usamos en producción
No hay una bala de plata; hay un repertorio. Estas son las palancas por orden de rentabilidad según nuestra experiencia:
- Recuperación selectiva (RAG bien hecho): no metas toda la documentación, recupera solo los fragmentos relevantes para la consulta actual. La calidad de un sistema RAG está en el retrieval y el chunking, no en el LLM.
- Compactación: cuando el historial crece, resúmelo. Sustituye 30 turnos de conversación por un resumen fiel de lo decidido y descarta el ruido. Es la diferencia entre un agente que aguanta una sesión larga y uno que se ahoga.
- Notas estructuradas (memoria externa): que el agente escriba su estado y sus conclusiones fuera de la ventana —en un fichero, una tabla, una nota— y lo recupere cuando lo necesite, en vez de mantenerlo todo "en la cabeza".
- Sub-agentes con contexto limpio: delegar una subtarea a un agente con su propia ventana, que devuelve solo el resultado. El agente principal no se contamina con los 10.000 tokens intermedios del subproceso.
- Menos herramientas, mejor descritas: cada definición de herramienta ocupa contexto y añade una decisión. Un catálogo de 40 herramientas mal delimitadas confunde más que ayuda. Menos herramientas, con límites claros, casi siempre rinde mejor.
Cuándo NO hacerlo (o al menos, no todavía)
Esta es la parte que casi nadie escribe, y es donde se ahorra más dinero:
- No montes RAG si tus datos caben en el prompt. Si tu base de conocimiento son 20 páginas estables, mételas en el system prompt y punto. Un pipeline de vectorización, reindexado y retrieval es infraestructura que hay que mantener; solo se justifica cuando el volumen o la frescura de los datos lo exigen.
- No montes multi-agente para un problema secuencial. La orquestación de varios agentes añade latencia, coste y superficie de fallo. Si la tarea es una cadena de pasos, un solo agente con buenas herramientas suele ser más robusto y mucho más fácil de depurar.
- No añadas memoria persistente "por si acaso." La memoria a largo plazo es una fuente clásica de envenenamiento: un dato viejo o erróneo que sobrevive sesiones. Añádela cuando el caso de uso la pida, con política de caducidad y validación, no por defecto.
- No optimices contexto que no has medido. Antes de compactar o recortar, instrumenta: cuántos tokens entran por turno, cuánto cuesta, dónde está el bulto. Optimizar a ciegas suele romper lo que funcionaba.
La regla general que aplicamos: empieza por lo simple y añade complejidad solo cuando un problema real lo justifique. El coste de mantener un pipeline de contexto sofisticado es muy real, y muchos productos no lo necesitan.
Diagnóstico rápido: síntoma, causa, técnica
| Síntoma en producción | Causa probable | Qué aplicar |
|---|---|---|
| El agente repite errores o inventa datos que "recuerda" | Envenenamiento de contexto | Validar entradas, memoria con caducidad, cortar el historial contaminado |
| Ignora información que sí le diste | Saturación | RAG selectivo, subir la señal, reducir ruido |
| En sesiones largas se ralentiza y da vueltas | Distracción / historial inflado | Compactación, notas estructuradas |
| Respuestas contradictorias según el turno | Conflicto de contexto | Ordenar prioridades, eliminar instrucciones obsoletas |
| Factura de tokens desproporcionada | Contexto tratado como cubo | Presupuesto por turno, sub-agentes, medir |
Cómo lo medimos
Un agente en producción sin telemetría de contexto es una caja negra que te llega en la factura. Lo mínimo que instrumentamos: tokens de entrada por turno, coste por interacción completada, latencia por llamada y trazas de qué entró en la ventana en las decisiones que salieron mal. Con eso, la mayoría de los problemas de "el modelo no es lo bastante bueno" se revelan como lo que son: contexto mal presupuestado.
Conclusión
El salto de calidad en agentes de IA en 2026 no viene tanto de modelos más grandes como de contextos mejor diseñados. La ingeniería de contexto es lo que separa una demo que impresiona de un producto que aguanta miles de interacciones sin dispararse en coste ni degradarse. Y buena parte del trabajo consiste, paradójicamente, en meter menos: recuperar solo lo relevante, resumir lo viejo, delegar lo pesado y medir todo.
Si estás integrando un agente o un sistema RAG en tu producto y ves que el coste no cuadra o las respuestas se degradan con el uso, suele ser un problema de contexto, no de modelo. En Dribba llevamos LLMs, RAG y agentes a producción con equipo senior in-house y ROI medible desde el primer mes. Si quieres una segunda opinión sobre tu arquitectura, hablamos.
