Context Engineering
Tu agente no es tonto, tiene amnesia
Si tienes un buen puñado de años, probablemente recuerdes lo que era pelearse con la memoria RAM. Hubo una época, no tan lejana, en la que tener 256 MB o 512 MB era un lujo que solo algunos podíamos permitirnos. Optimizábamos cada proceso, cerrábamos aplicaciones en segundo plano con una disciplina casi religiosa y mirábamos de reojo el administrador de tareas (si es que lo había). Meter capas de abstracción innecesarias era un pecado capital porque, sencillamente, no cabían. Aprendimos a ser frugales, a entender que los recursos eran finitos y que la elegancia del código residía, en gran parte, en su eficiencia.
Hoy vivimos en la era de la abundancia. Lanzamos contenedores a producción con gigas de RAM sin pestañear y los navegadores modernos se meriendan la memoria como si no hubiera un mañana. Hemos perdido ese miedo al “Out of Memory”, delegándolo en orquestadores que simplemente levantan otra instancia si la anterior explota. Pero en el mundo de los modelos de lenguaje (LLMs), volvemos un poco a revivir aquella época. El contexto es la nueva RAM y estamos siendo terriblemente descuidados con él.
Los modelos tienen una limitación física e insalvable (por ahora): la ventana de contexto. Y aunque los proveedores compitan semanalmente por ver quién ofrece más miles o millones de tokens, el problema no es solo de capacidad bruta. Es un problema de atención. Cuanto más “ruido” metes en el contexto, más divaga el modelo, más alucina y menos coherente es su razonamiento. Tu agente no es que sea limitado. Es que tiene una memoria RAM muy cara, muy volátil y muy fácil de ensuciar.
Context Rot
Últimamente, en Technosylva, andamos dándole forma a una AI Platform. Uno de los componentes clave es un repositorio centralizado para compartir plugins, skills, agentes y demás artefactos. El objetivo es allanar el camino y bajar la barrera de entrada para ayudar a la gente a incorporar agentes en su día a día. Es un reto que tiene muchísimas similitudes con la ingeniería de plataformas tradicional: estamos construyendo los “Golden Paths”, pero para la era de la inteligencia artificial.
Al diseñar este tipo de sistemas, te das cuenta de que la tentación inicial de cualquier desarrollador es “meterlo todo”. Quieres que el agente sea superinteligente, así que piensas: “¿Por qué no le paso toda la documentación de cómo desplegamos en GitLab, todos nuestros dashboards de Grafana y toda la arquitectura que tenemos documentada en Notion?”.
Al problema de meter información superflua se le conoce como Context Rot (o contexto podrido). El rendimiento del agente cae porque su atención se agota al procesar datos irrelevantes o, peor aún, contradictorios. Imagina a un agente intentando arreglar un fallo en producción mientras tiene en su memoria tres versiones distintas de la misma guía de despliegue, dos de ellas obsoletas. El modelo empieza a perder el foco, a mezclar conceptos y a generar respuestas que, aunque suenan convincentes, son técnicamente erróneas.
Para evitar esto, necesitamos dejar de pensar únicamente en “escribir prompts” (prompt engineering) y empezar a hablar de Context Engineering: la disciplina de diseñar y gestionar sistemáticamente el ecosistema de información que rodea al agente, cuidando su limitado presupuesto de atención.
Agent Harness
Para que un agente sea realmente eficiente y fiable, necesita lo que en la industria se empieza a llamar un Agent Harness (p ej., Copilot, Claude Code, etc.). Imagínalo como el sistema operativo o la infraestructura que envuelve al núcleo del modelo. Si el modelo es la CPU y la ventana de contexto es la RAM, el harness es el kernel que gestiona qué procesos tienen permiso para ocupar esa memoria.
El harness se encarga del arranque, de curar la información entrante y de asegurar que el agente permanezca estable en flujos de trabajo largos. Uno de los patrones más interesantes y efectivos que estamos descubriendo es el de la Progressive Disclosure.
En lugar de cargarle al agente toda la base de conocimiento de la empresa de una sentada, diseñamos una arquitectura por capas:
Boot Sequence: La fase de arranque inicial altamente optimizada. El agente solo carga su identidad core, sus restricciones de seguridad obligatorias y un menú de navegación (al que se le llama Dispatch Table). Es como arrancar el sistema con lo mínimo para que sea receptivo.
Dispatch Table: Una matriz de enrutamiento que mapea la intención del usuario con la skill o el rol específico necesario. Si el usuario pregunta por una métrica de rendimiento, el agente solo activa las herramientas de Grafana. No necesita saber absolutamente nada de lo que hay en Drive en ese momento.
Targeted Retrieval (o Just-in-Time Context): Aquí es donde ocurre la magia técnica. El agente usa herramientas específicas para ir a buscar solo el fragmento de documentación exacto que necesita en el momento preciso de la ejecución. Es el fin de la precarga masiva de documentos.
Index-Time RAG vs. Real-Time RAG
Este enfoque cambia radicalmente cómo entendemos el RAG (Retrieval-Augmented Generation). Hasta hace poco, la norma era el “Index-Time RAG”: coges miles de documentos, los troceas, generas vectores y los guardas en una base de datos. Cuando el usuario pregunta, buscas por similitud y le pasas el resultado al modelo.
El problema es el desfase. En entornos operativos reales, las cosas cambian cada minuto. Un dashboard de Grafana o un ticket de Jira no puede esperar a que un proceso de indexación termine. Por eso la industria se está moviendo hacia el Real-Time RAG (o API-First Retrieval).
Desplazamos la carga de recuperación de la información al momento de la inferencia. El agente consulta directamente las APIs de los sistemas fuente (Notion, GitLab, Grafana, JIRA) para obtener la verdad absoluta en tiempo real. Esto garantiza la corrección operativa, eliminando el riesgo de que el agente trabaje con estándares obsoletos que aún no han sido reindexados.
MCP vs. API vs. CLI
Conectar todo esto de forma segura y escalable es el siguiente gran reto. No puedes escribir una integración a medida para cada herramienta de cada equipo; acabarías con una maraña de código infumable. Aquí es donde el Model Context Protocol (MCP) se está posicionando como una pieza fundamental, pero no es la única opción que estamos viendo en la industria.
MCP es el estándar abierto (impulsado inicialmente por Anthropic) que actúa como el “USB-C” de la IA. Su gran ventaja es que no solo permite ejecutar acciones, sino que está diseñado específicamente para exponer recursos y cargar contexto de forma estructurada. Cuando un agente se conecta a un servidor MCP de GitLab, no solo “lanza comandos”, sino que puede explorar el repositorio y traerse los fragmentos de código relevantes directamente a su contexto.
Sin embargo, no todo es MCP. En muchos casos, la industria —y nosotros mismos en ciertos flujos— optamos por utilizar CLIs (Command Line Interfaces) o llamadas directas a APIs.
Si ya tienes una herramienta de línea de comandos que sabe cómo interactuar con tu infraestructura, enseñarle al agente a usar ese CLI es, a veces, mucho más rápido y potente que envolverlo todo en un servidor MCP. El agente simplemente “lee” la salida estándar del comando y la incorpora a su contexto. Por otro lado, las APIs directas siguen siendo la opción preferida cuando necesitamos un control granular absoluto o cuando el volumen de datos es tan grande que necesitamos filtrar la información antes siquiera de que llegue al modelo.
¿El futuro es la memoria?
Por el momento, la optimización es la clave absoluta. Seguimos en esa fase donde cada token cuenta y donde los “ingenieros de contexto” tenemos que ser quirúrgicos. Estamos redescubriendo el valor de la escasez.
Sin embargo, la industria se mueve rápido. Con el tiempo, veremos una evolución similar a la de las memorias de nuestros ordenadores. Van apareciendo sistemas de memoria persistente y bases de datos diseñadas específicamente para ser “el hipocampo” de los modelos de lenguaje. Estas herramientas gestionarán automáticamente la revelación de información progresiva al contexto y el olvido selectivo sin que nosotros tengamos que orquestar cada llamada a la API.
Pero mientras cruzamos ese puente, quien mejor entienda cómo dosificar la información será quien construya los agentes más útiles y eficientes. La verdadera inteligencia no consiste en tener acceso a toda la información del mundo, sino en saber qué información ignorar en cada momento para centrarse en lo que realmente importa.
¿Y tú? ¿Cómo estás lidiando con la saturación del contexto en tus desarrollos? Cuéntamelo en los comentarios, que me interesa mucho conocer vuestras estrategias.
¡Muchas gracias por leerme!