Context engineering para agentes de IA: la memoria decide, no el context window
Si tu agente de IA funciona en la demo pero se descontrola en la tarea número catorce, el problema casi nunca es el modelo. Es el contexto. Context engineering es la disciplina de diseñar qué ve el modelo en cada llamada de inferencia: qué se recupera, qué se resume, qué se descarta y qué se guarda fuera de la ventana. En 2026 es lo que separa a los equipos que despliegan agentes fiables de los que siguen atrapados en la demo.
La idea de fondo es incómoda para quien vendió "context windows infinitas" como solución: más contexto no es mejor contexto. Un análisis de despliegues empresariales de IA atribuyó cerca del 65% de los fallos de agentes a deriva de contexto o pérdida de memoria durante el razonamiento multi-paso, no a incapacidad del modelo subyacente. El cuello de botella se movió del modelo al sistema que lo alimenta.
Qué es (y qué no es) context engineering
Prompt engineering optimizaba una instrucción. Context engineering diseña el sistema completo que entrega información al modelo en tiempo de ejecución: pipelines de recuperación, sistemas de memoria, catálogos de herramientas, resumen de conversación y presupuesto de la ventana de contexto.
La metáfora más útil que hemos visto: la ventana de contexto es RAM, no almacenamiento. Es volátil (desaparece al terminar la sesión), es limitada y es cara por token. Tratarla como un disco donde acumular todo el historial es la vía rápida al desastre. Sin compresión, la degradación empieza a notarse alrededor de las 10-15 vueltas de conversación.
Las cuatro operaciones que debes implementar
La comunidad ha convergido en cuatro operaciones básicas sobre el contexto. Cualquier arquitectura de agente seria las implementa, se llamen como se llamen:
- Write (escribir): persistir información fuera de la ventana. El agente mantiene notas de trabajo y resultados intermedios durante la ejecución, para no depender de que "todo siga en pantalla".
- Select (seleccionar): recuperar solo lo relevante ahora mediante búsqueda semántica y scoring de relevancia, en lugar de reinyectar el historial entero.
- Compress (comprimir): resumir para reducir tokens conservando la información que importa. La compresión adaptativa de memoria puede recortar el uso de tokens hasta un 80% manteniendo fidelidad.
- Isolate (aislar): dar a cada sub-tarea su propio contexto limpio, para que un tema no contamine a otro. Es la base de las arquitecturas multi-agente bien hechas.
Memoria a corto y largo plazo
Un agente en producción necesita dos capas de memoria, igual que un sistema operativo separa RAM de disco:
| Capa | Qué guarda | Coste | Persistencia |
|---|---|---|---|
| Corto plazo | Contexto inmediato de la sesión actual | Alto (tokens) | Se pierde al cerrar |
| Largo plazo | Preferencias, hechos, historial de relación | Bajo (almacenamiento) | Sobrevive entre sesiones |
El trabajo interesante está en el trasvase entre ambas: qué asciende a la ventana cuando hace falta y qué se comprime y baja a almacenamiento cuando deja de ser relevante. Frameworks como Letta se inspiran directamente en la gestión de memoria virtual de los sistemas operativos para automatizar ese movimiento.
Presupuesto de contexto: el hábito que casi nadie tiene
Antes de escribir una línea de orquestación, define un presupuesto de tokens por llamada y repártelo explícitamente: system prompt, definiciones de herramientas, memoria recuperada, historial reciente y margen para la respuesta. Si no lo haces tú, lo hará el runtime truncando por el peor sitio posible. Instrumenta cada invocación con la ocupación real de cada partida; es la única forma de detectar cuándo la recuperación está inflando el prompt sin aportar.
Cuándo NO necesitas nada de esto
Seremos honestos, porque es fácil sobre-ingenierizar aquí. Si tu caso es una llamada única sin estado —clasificar un texto, extraer campos de un documento, responder una pregunta autocontenida— no montes sistemas de memoria. Un buen prompt y, como mucho, RAG básico bastan. La maquinaria de write/select/compress/isolate se justifica cuando hay tareas de larga duración, multi-paso, con estado que debe sobrevivir entre turnos o sesiones. Meter memoria persistente en un flujo stateless solo añade latencia, coste y superficie de bugs.
Tampoco confundas "más memoria" con "mejor agente": memoria mal seleccionada es ruido que empeora las respuestas. Si al añadir contexto la calidad baja, el problema es la selección, no la falta de datos.
Cómo lo abordamos en Dribba
Llevamos 15 años construyendo producto y el patrón se repite: la parte difícil de un agente no es conectarlo, es que siga siendo correcto en la tarea 50. Por eso tratamos el contexto como código —versionado, presupuestado y medido— y validamos cada iteración con evals reales, no con "vibes". El context engineering y una capa sólida de MCP en producción son las dos caras de un mismo trabajo: darle al modelo exactamente lo que necesita, ni más ni menos.
Conclusión
En 2026 el diferencial competitivo de un agente no está en el tamaño de su ventana de contexto, sino en el rigor con que gestionas lo que entra en ella. Write, select, compress e isolate no son buzzwords: son las cuatro palancas que convierten una demo impresionante en un sistema que aguanta producción.
¿Tienes un agente que funciona en la demo pero se rompe con carga real? En Dribba diseñamos la capa de contexto y memoria para que deje de romperse. Hablemos.
