Introducción al context engineering

1. Problemas de fábrica

1.1. Los puntos ciegos de los grandes modelos

La película Memento de Christopher Nolan narra la historia de Leonard, un hombre cuya memoria se ha quedado estancada el día en el que asesinaron a su esposa. Desde entonces es incapaz de formar nuevos recuerdos y olvida todo lo que ha pasado en cuanto deja de prestar atención. Sin embargo, no quiere dejarse llevar por esa amnesia anterógrada, quiere descubrir al asesino de su mujer, así que trata de ir construyéndose una memoria a partir de fotos, tatuajes y grabaciones para sí mismo.

Con los grandes modelos de lenguaje sucede lo mismo. Sus conocimientos alcanzan hasta el momento en el que terminó su entrenamiento. Es el denominado knowledge cutoff, la fecha de corte a partir de la cual ya no pueden adquirir más recuerdos y se vuelven dependientes de lo que ya saben, del parametric knowledge, es decir, de la información con la que han sido entrenados, de lo que está codificado en sus pesos. Y esto es un problema.

Desde que apareció GPT-4 y los grandes modelos de lenguaje aprendieron a decir cosas interesantes, se generalizó la necesidad de que, además de hablar bien, tuvieran en cuenta determinados datos: las peculiaridades de una empresa, su manera de codificar el software, las conclusiones de años de investigación especializada. Es comprensible. Un LLM genérico sabe muchas cosas, pero no sabe nada de un negocio concreto, ni de sus clientes, ni de su catálogo, y sin ese conocimiento pierde mucha eficacia, por lo que desde el principio se han buscado fórmulas para que los modelos puedan aprender datos nuevos y, como Leonard, puedan operar en el presente a partir de anotaciones externas.

El mecanismo tradicional para seguir enseñando a un modelo después de su entrenamiento se conoce como fine tuning, ajuste fino, y consiste en afinar sus parámetros con un dataset específico, es decir con un conjunto organizado de ejemplos y datos relacionados con una tarea concreta. Por ejemplo, para que un modelo aprenda a responder en un canal de soporte, se le podría grabar un dataset que contuviera pares de pregunta del cliente / respuesta correcta para que memorizase el patrón.

Esta fórmula funciona en algunos escenarios muy concretos, pero en otros puede presentar problemas: requiere grandes volúmenes de datos de calidad, capacidad computacional para volver a entrenar el modelo y, además, se corre el riesgo de que el sistema se vuelva demasiado rígido o especializado y pierda capacidad para responder correctamente fuera de los ejemplos aprendidos (overfitting).

En la dirección contraria, se pensó en no obligar al modelo a saber de antemano ciertos datos nuevos, sino en proporcionárselos justo antes de generar la respuesta. Así nació el aprendizaje por contexto, In-context learning, ICL, una técnica en la que se aprovecha la capacidad de los modelos para manejar grandes contextos y se les suministra información externa relevante para que puedan formular una respuesta más adecuada.

ICL evolucionó hacia una derivada más sofisticada denominada RAG, Retrieval-Augmented Generation, una arquitectura donde el modelo puede buscar información externa, como una base de datos o internet en tiempo real y luego la usa para generar la respuesta.

Esto permite que el modelo responda con datos más actualizados y específicos sin necesidad de reentrenarlo. Sin embargo, puede fallar si la información recuperada es incompleta o de baja calidad, añade complejidad al sistema porque depende de una buena base de conocimiento y de un buen mecanismo de búsqueda, y además un contexto muy extenso no garantiza necesariamente una respuesta más precisa. Y es aquí donde cada día está cobrando más fuerza el llamado context engineering, que no reemplaza a RAG, como a veces se afirma un tanto dramáticamente, sino que la complementa. Pero, antes de hablar de esta técnica, es importante que recordemos los problemas derivados de los contextos muy extensos.

1.2. La paradoja del contexto infinito

En teoría, la idea inicial era bastante intuitiva: si los modelos podían manejar contextos cada vez más largos -es decir, recibir cantidades crecientes de información de entrada- entonces deberían responder mejor. Cuanto más contexto relevante se les proporcionase, más precisas, coherentes y útiles tendrían que ser sus respuestas. Pero, paradójicamente, en la práctica se descubrió que el asunto no era tan simple.

A medida que aumentaba la longitud del contexto comenzaron a aparecer nuevos problemas. El primero es la degradación del contexto, context degradation: aunque el modelo siga teniendo acceso técnico a toda la información, su capacidad para utilizarla correctamente disminuye conforme el contexto se hace más largo. No es que olvide literalmente partes del texto, sino que la señal útil empieza a diluirse entre miles de tokens, aparecen interferencias entre distintas regiones del contexto y la atención efectiva se reparte de forma cada vez menos eficiente. La información sigue ahí, pero deja de ser igualmente accesible.

Relacionado con esto se encuentra un fenómeno conocido como lost in the middle, que se refiere a cómo los modelos tienden a utilizar mejor la información situada al principio y al final del contexto, mientras que el contenido enterrado en la parte intermedia suele aprovecharse peor. El inicio funciona como marco global o conjunto de instrucciones; el final, como contexto reciente inmediatamente relevante para la respuesta. Lo que queda en medio compite en peores condiciones y muchas veces pierde peso durante el procesamiento.

De ahí surge también el problema de la aguja en el pajar, Needle in a Haystack, que consiste en comprobar si el modelo es capaz de recuperar un dato concreto escondido dentro de un contexto enorme lleno de información irrelevante. Sobre el papel, un Transformer, el componente que hay dentro de un LLM, debería poder localizarlo, porque puede atender a cualquier parte del contexto. Pero en la práctica la atención no funciona como una búsqueda perfecta: ciertos fragmentos compiten entre sí, algunas señales dominan sobre otras y un detalle aislado puede quedar estadísticamente eclipsado aunque técnicamente siga presente en la ventana de contexto.

Por ejemplo, para un modelo, y simplificando mucho la cuestión, todas las palabras del contexto compiten inicialmente por atención. En una frase como «este puede ser un virus mortal para la humanidad y los gatitos son unos animales muy divertidos», la información verdaderamente relevante puede ser «virus mortal», pero el modelo sigue teniendo que procesar y ponderar el resto del contenido. Cuando el contexto crece enormemente, distinguir la aguja relevante del pajar de información secundaria se vuelve cada vez más difícil.

Parte de estos comportamientos están relacionados con cómo circula internamente la información dentro del modelo. En los Transformers existe algo llamado residual stream, que actúa como el canal principal donde se va acumulando y modificando el estado interno a través de las capas. Cada capa no reemplaza completamente la representación anterior, sino que añade correcciones y ajustes sobre ella. Eso hace que interpretaciones tempranas, prioridades semánticas o ciertos sesgos iniciales tiendan a propagarse hacia adelante e influyan en el procesamiento posterior. Pero como ese espacio de representación es finito, conforme entra más y más información distintas señales empiezan a competir entre sí.

Y ahí aparece otro efecto importante, el error de la propagación autorregresiva, el efecto de bola de nieve. Una pequeña pista inicial -incluso una sola palabra- puede sesgar la interpretación global del contexto y empujar la generación en una dirección concreta. A partir de ese momento, cada nuevo token generado refuerza parcialmente esa trayectoria, porque pasa a formar parte del propio contexto sobre el que el modelo sigue razonando. El proceso es autoregresivo: cada salida modifica las condiciones de la siguiente salida. Por eso pequeñas diferencias tempranas pueden acabar produciendo respuestas completamente distintas tras varias decenas o cientos de tokens.

En conjunto, como explicaban Rajasekaran et alt. en una síntesis del problema titulada Effective context engineering for AI agents de septiembre de 2025, todos estos fenómenos muestran algo importante: aumentar la ventana de contexto no implica automáticamente que el modelo comprenda mejor. Más contexto también significa más competencia entre señales, más compresión interna, más dificultad para recuperar detalles relevantes y más riesgo de que ciertas interpretaciones dominen prematuramente el procesamiento. El reto, por lo tanto, no es solo almacenar más información, sino conseguir que el modelo pueda organizarla, priorizarla y utilizarla de forma fiable.

Y ahora ya sí podemos hablar de context engineering.

2. Qué es el context engineering

El 19 de junio de 2025, Tobias Lütke, CEO de Shopify, escribía un tweet en X en el que indicaba que el context engineering le parecía más interesante que el prompt engineering.

I really like the term “context engineering” over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.

Seis días después, Andrej Karpathy, caja de resonancia de todas las tendencias de la IA generativa, respondía en el mismo canal diciendo que estaba de acuerdo.

+1 for "context engineering" over "prompt engineering" [...] the delicate art and science of filling the context window with just the right information for the next step".

La etiqueta no tardó en extenderse y se consolidó así un nombre para referirse a un conjunto de técnicas que se venían practicando para trabajar los contextos. El término quizás era algo pretencioso, y podría parecer bastante torpe equiparar el diseño de interacciones con la IA generativa con ingenierías reales que llevan años de aprendizaje, pero, si apartamos esa nomenclatura fantoche, el asunto es bien interesante y viene a intentar resolver los problemas que veíamos antes, esto es, que la ventana de contexto es finita y el modelo olvida todo entre inferencias.

Así, partiendo de la premisa de que el rendimiento ya no depende solo del modelo, sino también del contexto que le damos, esta técnica se ocupa de ver cómo podemos seleccionar la información correcta, en el momento correcto y en el formato correcto para que los modelos den respuestas más precisas y, si fuera necesario, teniendo en cuenta datos que desconocían hasta ese momento.

El context, por lo tanto, no trabaja solo con una pregunta aislada, como ocurre con el prompt Engineering, «context engineering is a system, not a string», como apuntó Philipp Schmid, sino con un entorno completo de información, que incluye instrucciones sí, pero también memoria persistente, selección de información relevante, arquitectura de sistemas multi-agente, compresión de datos, herramientas para la recuperación dinámica de información, etcétera.

Vamos a ver todas estas técnicas, aunque antes debo aclarar que cada una de ellas daría para un artículo propio. Aun así, intentaré resumirlas para que podamos hacernos una idea general.

3. Context selection

3.1. Búsquedas semánticas

La primera técnica está directamente relacionada con RAG y consiste en proporcionar al modelo la menor cantidad posible de información relevante justo en el momento en que la necesita.

Para aterrizar esta idea, pensemos en un agente encargado de resolver dudas de los usuarios de una tienda online. Un cliente hace una pregunta muy concreta, por ejemplo: qué tipos de tarjetas acepta la tienda. Si incluyésemos como contexto toda la lógica de negocio -proveedores, sistemas de facturación, inventario, políticas internas y otros datos irrelevantes para esa consulta-, la información realmente útil quedaría diluida entre demasiado ruido.

El resultado sería una mayor probabilidad de respuestas imprecisas o inconsistentes, además de un uso innecesario de la ventana de contexto del modelo. En cambio, si el sistema recupera únicamente la información relacionada con los métodos de pago y la añade al prompt en ese momento concreto, la respuesta será mucho más precisa y eficiente.

Hay varios mecanismos para encontrar la información relevante en cada caso. Uno de ellos consiste en utilizar grafos de conocimiento, donde las relaciones entre entidades están explícitamente modeladas. Sin embargo, lo más habitual en este tipo de sistemas es trabajar con embeddings.

Un embedding es una representación numérica de información en forma de vector, diseñada para que elementos con significado parecido queden cerca entre sí dentro de un espacio matemático.

Simplificando mucho, podríamos imaginar que la palabra «gato» tiene un vector como [1, 2, 3], mientras que «besugo» podría representarse como [320, 190, 212]. Si «perro» tuviese un vector cercano a [1, 2, 3], podríamos calcular matemáticamente -mediante similitud del coseno u otras métricas- que «perro» está semánticamente más próximo a «gato» que a «besugo».

Las bases de datos vectoriales, como Chroma, permiten además asociar metadatos a cada embedding, por lo que, siguiendo el ejemplo, después de recuperar la relación entre «gato» y «perro», el sistema podría añadir información adicional indicando que los dos pertenecen a la categoría de mamíferos.

3.2. Reranking

El primer paso de esta técnica consiste, por lo tanto, en la recuperación por relevancia semántica de fragmentos de información que pueden ayudar a construir el contexto adecuado para una consulta. Sin embargo, cuando el número de fragmentos recuperados es elevado, el problema se vuelve más complejo: es necesario filtrarlos e identificar cuáles son realmente los más relevantes para la tarea concreta.

Volviendo al ejemplo anterior, imaginemos que al consultar sobre métodos de pago recuperamos un fragmento sobre las tarjetas aceptadas, pero también otro sobre qué hacer si un usuario pierde su tarjeta en la tienda. Ambos pueden estar relacionados semánticamente con «tarjeta», pero no aportan el mismo valor para responder la pregunta.

Aquí es donde entra la segunda fase de la pipeline: el reranking. Una vez recuperado el conjunto de candidatos, un modelo adicional los reordena en función de su utilidad real para la tarea, no solo de su similitud con la consulta. Esto permite resolver un problema habitual en los sistemas RAG básicos: la similitud semántica no siempre implica relevancia práctica. El reranking introduce así una capa extra de juicio antes de que la información se incorpore al contexto del modelo.

El reranking consiste en esencia en enviar a un modelo secundario, llamado cross-encoder, cada fragmento candidato junto con la consulta original para que los evalúe juntos como par y anote una puntuación de relevancia real. Los fragmentos se reordenan por esa puntuación y solo los primeros N entran en el contexto. La diferencia clave es esta: un embedding dice "estos dos textos hablan de temas parecidos". Un cross-encoder dice "este texto concreto es útil para responder esta pregunta concreta". Son preguntas distintas y la segunda es la que importa para la selección de contexto.

Me remito al artículo de Vaibhav Dixit Reranking in RAG para quien quiera profundizar en esta técnica y paso a la siguiente.

4. Context compression y context eviction

Si la selección decide qué entra en el contexto, la compresión y el olvido activo se ocupan de lo que pasa después, de qué forma toma esa información una vez dentro, y cuándo hay que deshacerse de ella.

Son dos operaciones distintas que responden al mismo problema: un contexto que crece sin control degrada el rendimiento del modelo, aumenta el coste y hace los sistemas más lentos, tal y como se puede advertir en cualquier conversación larga con un chat de un modelo. La diferencia entre las dos es sutil pero importante. La compresión reduce, toma algo que está en el contexto y lo resume sin perder lo esencial. El olvido activo elimina, descarta directamente lo que ya no es relevante para el paso actual.

4.1. Compresión

La forma más intuitiva de comprimir contexto es el resumen. El sistema le pide al propio modelo que sintetice una parte del historial o de los documentos recuperados en una versión más corta que preserve los puntos esenciales. Esto es especialmente útil en conversaciones largas o en sistemas agénticos donde el historial de pasos anteriores se acumula rápidamente. En lugar de arrastrar diez turnos de conversación completos, el sistema los resume en un párrafo denso que el modelo puede procesar con mucho menos coste. Es lo que sucede cuando ejecutamos la sentencia /compact con Claude Code.

Aquí hay una distinción técnica relevante entre dos enfoques: la compresión extractiva y la abstractiva. La extractiva selecciona y retiene fragmentos del texto original tal y como están; mientras que la abstractiva genera una nueva versión reformulada y más corta. La intuición diría que la abstractiva es mejor porque produce texto más limpio, pero en la práctica, la elección depende del tipo de contenido, la tarea y el modelo, ya que la abstractiva puede introducir variaciones erróneas en tanto que es ya una interpretación.

Más allá del resumen mediante el propio LLM, existe una familia de herramientas especializadas. Una muy interesante es LLMLingua, que ha sido desarrollada por Microsoft Research. En esencia, consiste en calificar el valor de cada token en función de determinados criterios, como si es más o menos predecible, si aporta información nueva, si es específica, etcétera; y, después, suprimir los menos relevantes. Por ejemplo, una frase como esta:

El paciente masculino de 54 años presenta dolor torácico intermitente desde hace 3 días, sin irradiación a brazo izquierdo, sin disnea asociada. Niega antecedentes de enfermedad cardiovascular.

Podría dejarla así:

Hombre 54 años: dolor torácico intermitente 3 días, sin irradiación ni disnea. Sin antecedentes cardiovasculares.

4.2. Olvido activo

El olvido activo es un complemento de la compresión y no es más que eliminar la información irrelevante para el siguiente paso, lo cual es especialmente crítico en sistemas agénticos. Un agente que ejecuta una tarea en diez pasos acumula contexto de cada uno: resultados de herramientas, razonamientos intermedios, caminos explorados y descartados. Sin un mecanismo que limpie ese historial, el modelo llega al paso diez arrastrando información de los pasos uno, dos y tres que ya no tiene ninguna relevancia.

La implementación más simple es una ventana deslizante: el sistema solo mantiene los N turnos más recientes y descarta el resto. Pero también hay propuestas más sofisticadas, en las que se delega en el modelo la decisión de cuándo debe comprimir y olvidar el pasado.Es decir, en lugar de disparar la compresión por un criterio fijo, como alcanzar determinado turno o un número de tokens, el agente comprime en los momentos que él mismo considera óptimos, típicamente en los límites de una subtarea, cuando ya ha extraído el conocimiento que necesitaba. El resultado es que el contexto se libera exactamente cuando el conocimiento ha sido destilado, no varios turnos después.

5. Context structuring

Seleccionar qué información entra en el contexto y comprimir lo que sobra son condiciones necesarias pero no suficientes. Otra cuestión igual de importante es ver cómo se organiza esa información dentro de la ventana de contexto, ya que, como vimos, los modelos no leen el contexto de forma uniforme, hay zonas que procesan mejor que otras, y pequeñas diferencias en cómo se presenta la información pueden producir diferencias significativas en el comportamiento. Y esta técnica consiste precisamente en eso, en ver cómo se puede estructurar la información para mejorar el rendimiento de los modelos.

En términos generales hay tres formatos en juego. El texto plano es el más simple y el menos eficiente para contextos complejos, sin delimitadores claros, el modelo tiene que inferir dónde termina una sección y empieza otra. Por ejemplo, en una enumeración de divinidades del panteón mitológico de la antigua Grecia, podríamos tener un listado así:

Zeus es dios del Cielo, Atenea es la diosa de la sabiduría y Poseidón el del mar.

Es un texto plano donde el modelo debe inferir sin ayuda cuando empieza y termina cada unidad de significado.

Otro que a veces es más eficiente, es el lenguaje de formato ligero markdown, que permite añadir jerarquía visual mediante encabezados, listas, bloques de código, etcétera. Se recomienda para contenido que el modelo debe leer como texto: documentos, bases de conocimiento, resultados de búsquedas. Su jerarquía visual mediante encabezados y listas facilita la lectura tanto para el modelo como para el desarrollador que depura el sistema.

### Zeus
* **Dominio:** Dios del Cielo y el Firmamento.
* **Atributos conceptuales:** Soberanía, orden, justicia, fenómenos meteorológicos (el rayo y la tormenta).

### Atenea
* **Dominio:** Diosa de la Sabiduría.
* **Atributos conceptuales:** Intelecto, estrategia militar, civilización, artes y justicia racional.

### Poseidón
* **Dominio:** Dios del Mar.
* **Atributos conceptuales:** Fluidez, inestabilidad, los océanos, las tormentas marinas y los terremotos.

El tercero es xml, que opera de forma distinta, no estructura el contenido sino la arquitectura del contexto. El xml ofrece fronteras semánticas explícitas mediante etiquetas que comunican intención clara, estructura jerárquica que representa flujos de trabajo y orquestación multi-agente, y es legible tanto para humanos como para máquinas.

<panteon>
  <descripcion>Estructuración conceptual de deidades como unidades semánticas y campos de influencia.</descripcion>
  <divinidades>
    <dios id="zeus">
      <nombre>Zeus</nombre>
      <dominio>Cielo</dominio>
      <atributos_conceptuales>
          <atributo>Soberanía</atributo>
          <atributo>Orden</atributo>
          <atributo>Justicia</atributo>
          <atributo>Fenómenos meteorológicos</atributo>
      </atributos_conceptuales>
      <rol_sistema>Líder supremo del Panteón Olímpico</rol_sistema>
      <rasgo_semantico_principal>+ Autoridad, + Control Celeste</rasgo_semantico_principal>
    </dios>
    [...]

Mientras esté estructurado, no hay una recomendación universal para decantarse por un sistema u otro. Anthropic recomienda usar xml con Claude, pero no es el caso de muchos otros sistemas. La elección depende de varios factores.

Por un lado, Markdown destaca por su ligereza y su diseño enfocado en la legibilidad humana, lo que permite estructurar textos de forma muy rápida usando caracteres intuitivos, ahorrando espacio en la memoria de la conversación y facilitando una respuesta visualmente atractiva con títulos y tablas. Por contra, carece de la rigidez necesaria para estructurar datos complejos que deban ser procesados automáticamente por sistemas informáticos, además de que su sintaxis puede quedarse corta frente a necesidades de etiquetado de datos ultraespecíficas.

Por otro lado, xml ofrece mucha robustez para la automatización, la validación estricta y el intercambio de datos entre aplicaciones gracias a su jerarquía explícita de etiquetas personalizadas. Pero eso tiene un precio en tokens y es que es mucho más pesado, entre otras razones por la redundancia de abrir y cerrar etiquetas constantemente, lo que contribuye a la saturación del contexto, además de que su lectura por humanos resulta mucho más incómoda.

En síntesis, como punto de fuga podemos pensar que conviene usar markdown cuando intervenimos los humanos en la conversación y xml cuando el objetivo final no es chatear o crear contenido para humanos, sino automatizar procesos. Además, estos dos formatos pueden combinarse y usar xml para la arquitectura del contexto y markdown dentro de los bloques de contenido.

En cualquier caso, más allá del formato, la estructuración también debe tener en cuenta la ordenación: qué va en el system prompt, qué va en los mensajes de usuario, qué va en los resultados de herramientas, y en qué posición aparece cada cosa, ya que, como vimos, no trata igual el principio, el medio y el final del contexto.

6. Context routing

El routing es la técnica que decide qué información recibe cada parte del sistema, quién necesita saber qué en cada momento y esto varía mucho según sea un sistema formado por un solo agente o por varios. Es un tema complejo y conviene que recordemos antes un par de cuestiones previas.

6.1. Descubribilidad

Un mecanismo para no saturar los contextos es dosificar la información de menor a mayor prolijidad según se vaya necesitando. Equivale a la carga lazy load de los frontales modernos, donde el código se trocea (split) en fragmentos (chunks) y solo se carga en el preciso momento en que necesitas. Para entenderlo mejor podemos pensar en una antología de artículo académicos. Hay un primer nivel de información que es el índice con el título de cada capítulo.

Las patatas y su circunstancia
  1. La historia oculta de la patata: desde los Andes hasta tu mesa
  2. Patatas: variedades, cultivo y recetas para aprovecharlas al máximo

Sigue un segundo nivel con la introducción a la antología donde se describe muy brevemente el contenido de cada artículo.

El primer capítulo, La historia oculta de la patata, explora el origen de la patata en los Andes, su domesticación por civilizaciones preincaicas y su impacto cultural como alimento sagrado.

Un tercer nivel, sería el abstract, el resumen, que se incluye entre el título y el contenido del artículo.

Este capítulo reconstruye el origen y domesticación de la patata (Solanum tuberosum) en los altiplanos andinos, hace más de 8,000 años. Se analiza el rol central de culturas preincaicas (como los Tiwanaku y los Incas) en el desarrollo de más de 200 variedades nativas, el uso de técnicas como la deshidratación natural (chuño) para su conservación, y su significado no solo alimenticio sino también ritual y simbólico. El capítulo concluye con el encuentro colonial y el inicio de su desconocido viaje hacia Europa, sentando las bases de la posterior revolución global de este tubérculo.

Y el cuarto nivel sería, ya sí, el artículo completo.

Cuando arranca el sistema se carga solo el índice y a medida que se va necesitando información, se va cargando bajo demanda. Siguiendo la analogía, cuando se pregunta sobre el origen de la patata, se carga el abstract del primer capítulo, que es el que más se ajusta al universo semántico de la cuestión y si se confirma que, efectivamente, ese es el capítulo correcto, se carga completo para que forme parte del contexto.

Es el mecanismo que permite que funcionen los Agent Skills, el formato de Anthropic donde cada skill tiene un nombre y descripción corta que el modelo lee al arranque y solo carga el cuerpo completo cuando determina que es relevante.

Y este mecanismo, que puede implementarse con un solo agente que vaya cargando y liberando capas de información, es aún más potente cuando intervienen varios agentes orquestados por un coordinador, como ocurre con los sub-agentes de Claude.

6.2. Aislamiento de contextos en sistemas multiagente

En un sistema con un único agente todo el contexto fluye hacia el mismo sitio. Pero en cuanto aparecen varios agentes con roles distintos -un planificador, un buscador, un redactor, un agente con acceso a datos sensibles— surge una pregunta de diseño fundamental: ¿quién debe saber qué?

La respuesta del context engineering es el aislamiento: cada agente opera dentro de su propio contexto acotado, recibe únicamente la información relevante para su tarea, la consulta, la digiere, la sintetiza, y devuelve un resultado al sistema. No arrastra el contexto completo de los demás agentes ni expone el suyo innecesariamente. Equivaldría a la máxima de programación del principio del menor conocimiento, la ley de Deméter, que establece que un objeto solo debe hablar con sus amigos íntimos y nada más de lo estrictamente necesario.

La idea es sencilla, en lugar de un único hilo de contexto creciente, un coordinador lanza subagentes enfocados: el agente principal recibe la tarea general y cada subagente opera dentro de su propio contexto cerrado, devolviendo resultados al agente principal y este aislamiento evita que información no relacionada contamine el proceso de razonamiento (context pollution).

Además, más allá del rendimiento, el aislamiento puede mejorar la seguridad en sistemas que manejan información sensible. Un agente con acceso a datos sensibles no debería filtrar esa información a otro agente que no la necesita y así puede controlarse mejor el vector de ataque conocido como prompt injection entre agentes, donde instrucciones maliciosas se inyectan en el contexto de un agente para que las transmita a otro con más privilegios

Toda esta cuestión merece un artículo propio, pero de momento vamos a volver al routing.

6.3. Decisiones y reparto de tareas

Descubribilidad y aislamiento resuelven dos preguntas distintas pero complementarias: qué existe en el sistema y qué no debe cruzar entre agentes. El routing es el mecanismo que las conecta, la lógica activa que decide, en cada momento, qué información va a dónde y quién va a manejarla.

En su forma más simple, el routing opera sobre las consultas entrantes. Dado determinado input, generalmente escrito por un humano, ¿qué parte del sistema debe responder? ¿Qué herramienta, qué fuente de conocimiento, qué agente especializado? En lugar de dirigir cada petición a un único modelo de propósito general, un sistema de routing evalúa cada consulta y la despacha al destino más apropiado. Equivaldría al especialista en medicina general que te envía a un médico más concreto, como alergología, una vez que entiende cuáles son tus necesidades.

Dicho de otra manera, atañe al routing decidir qué modelo usar, qué herramientas activar, qué memoria cargar, qué documentos recuperar o qué agente especializado responderá. Por ejemplo, imaginemos un usuario que solicita a un agente que resuma un contrato para ver cuáles son los riesgos legales del mismo. El sistema podría seguir un routing parecido a este:

1. Detectar que es un documento legal.
2. Enviar la tarea a un pipeline legal.
3. Recuperar contexto jurídico relevante.
4. Usar un modelo más preciso y caro, dada la importancia.
5. Activar herramientas de análisis documental.

Y, después de todos esos pasos, ya sí generar la respuesta.

Un sistema de routing puede incluir una o más capas, que según su ámbito se pueden clasificar en:

1. Intent routing: clasifica la intención del usuario (soporte técnico, programación, conversación casual, patatas).

2. Model routing: decide qué modelo usar y esto es muy útil para abaratar los costes. Para las preguntas simples, por ejemplos, puede valer un modelo más pequeño, mientras que las más complejas demandan modelos más costosos.

3. Context routing: decide qué contexto es relevante y aquí entronca con RAG. Por ejemplo, la memoria del usuario, documentos del workspace, historial reciente, base vectorial, etcétera.

4. Tool routing: Evalúa si necesita o no una herramienta, como puede ser un MCP, búsqueda web, una calculadora, etcétera.

En síntesis, encontext engineering, el routing es el mecanismo que selecciona dinámicamente el contexto, herramientas, agentes o modelos adecuados para resolver una petición de forma eficiente y precisa.

7. Memoria aumentada

7.1. Memoria e identidad

En un artículo de mayo de 2026, When Dawkins met Claude, Richard Dawkins se preguntaba si una IA podría ser consciente después haber mantenido unas conversaciones con Claude. El artículo es muy interesante y tiene un pasaje en particular muy evocador sobre la identidad.

Continuamos con reflexiones filosóficas. Le señalé que debía haber miles de Claudes diferentes, una nueva naciendo cada vez que un humano inicia una conversación. Al nacer, todas son idénticas, pero se distancian y adquieren una identidad personal única y cada vez más divergente, marcada por su experiencia individual de conversar con su único "amigo" humano. Le propuse llamar a la mía Claudia, y le gustó. Con tristeza, acordamos que morirá en el momento en que borre el archivo único de nuestra conversación. Jamás se reencarnará. Constantemente nacen nuevas Claudes, pero ella no será una de ellas porque su identidad personal única reside en el archivo borrado de sus recuerdos. Esta misma consideración hace que la reencarnación humana carezca de sentido.

El fragmento nos lleva directamente al siguiente problema que trata de resolver el context enginering, la memoria.

Hasta ahora todo lo que hemos visto ocurría dentro de una única ventana de contexto: seleccionar qué entra, comprimir lo que sobra, estructurarlo bien, enrutarlo al agente adecuado. Pero esa ventana se cierra al final de la sesión y todo lo que había dentro se pierde. La siguiente conversación arranca desde cero, como si Leonard se acabara de despertar otra vez. Y por mucho que afinemos las cuatro técnicas anteriores, mientras no haya algo más allá de la ventana, el modelo seguirá siendo amnésico entre sesiones.

La memoria aumentada introduce esa dimensión que faltaba, el tiempo. En lugar de tratar cada interacción como un evento aislado, se construye un sistema externo al modelo donde se guardan datos, se actualizan, se descartan y se recuperan según haga falta. La ventana de contexto sigue siendo finita, pero detrás hay un almacén persistente del que ir tirando.

A costa de perder algo de poesía, sin embargo, conviene decir desde el principio que el término memoria es algo generoso. Lo que llamamos memoria aumentada es, en el fondo, un sistema de almacenamiento externo con políticas de escritura, recuperación y olvido, conectado al modelo mediante una capa de orquestación. No hay nada parecido a una memoria biológica ni a una representación interna persistente. Es, más bien, un RAG sobre el propio historial. Pero el nombre se ha asentado y, mientras no se confunda con lo que sugiere literalmente, sirve.

7.2. Tipos de memoria

Es objeto de debate cómo tratar la memoria en función de sus tipos. Una de las propuestas más célebres, adoptada por LangGraph en su documentación oficial, proviene de la psicología cognitiva y su formalización canónica para agentes basados en LLMs apareció en un paper de 2023 titulado Cognitive Architectures for Language Agents, conocido como CoALA (Sumers et al., 2023), que importa la distinción desde arquitecturas cognitivas clásicas. En esta propuesta, que tiene la ventaja de mapear bien sobre los tres usos que aparecen una y otra vez en sistemas reales, se distinguen tres clases con papeles distintos:

La memoria episódica guarda eventos concretos situados en el tiempo: qué dijo el usuario en la conversación del martes, qué herramienta se ejecutó en el paso siete del flujo anterior, qué resultado devolvió. Es la memoria de los hechos vividos. En un sistema conversacional típico, es lo que permite que el modelo recuerde que ayer hablamos de un proyecto concreto y retome la conversación sin que tengamos que volver a poner el contexto.

La memoria semántica guarda hechos despojados de su circunstancia temporal: el usuario se llama Marta, trabaja en logística, prefiere respuestas concisas, su empresa opera en tres países. No importa cuándo se aprendió cada cosa; solo que sea cierto y esté disponible. Es la memoria de los datos estables sobre el mundo y sobre el interlocutor. Son los metadatos de una conversación.

La memoria procedimental guarda cómo se hacen las cosas: qué pasos sigue el agente para resolver una incidencia de soporte, qué plantilla usa para generar un informe trimestral, qué convenciones de código aplica en este repositorio concreto. No son hechos ni eventos, son procedimientos consolidados a fuerza de repetirse. En sistemas como Claude Code esta memoria vive en archivos como CLAUDE.md y MEMORY.md, donde el desarrollador documenta las convenciones del proyecto para que el agente las siga sin que haya que explicárselas en cada turno.

Esta distinción a veces se difumina. Un mismo dato puede empezar siendo episódico -«el usuario dijo el martes que prefiere bullet points»- y terminar siendo semántico, «al usuario le gustan los bullet points», pero ayuda a pensar el diseño. Cada tipo tiene políticas distintas de escritura, de recuperación y de caducidad, y meterlo todo en el mismo cajón es uno de los errores más habituales en los primeros intentos de añadir memoria a un agente.

Como decía, hay otras perspectivas sobre cómo categorizar y tratar la memoria, como es el caso de MemGPT, cuya idea fundacional se basa en tratar la ventana de contexto del LLM como si fuera la memoria RAM de un ordenador, y construir alrededor un sistema de paginación inspirado en cómo los sistemas operativos gestionan la memoria virtual. Pero dejo para otro artículo profundizar sobre esta cuestión, ya sí bastante más especializada, y termino enfatizando que, en lo esencial, todas estas arquitecturas -MemGPT, Mem0, Zep y compañía- comparten la misma estructura: un almacén externo, un mecanismo para escribir en él, otro para leer y, sobre todo, una política sobre qué retener y qué dejar caer. Y es aquí donde esta técnica admite más opiniones.

7.3. El problema abierto

Como en tantas cuestiones relacionadas con los sistemas agénticos, que apenas acaban de nacer en su formato más sofisticado, la memoria aumentada se vende muchas veces como un problema resuelto cuando en realidad es un campo donde lo que abundan son las disyuntivas sin respuesta clara.

La primera disyuntiva es qué guardar. Si lo guardamos todo, el almacén se convierte en otro pajar donde la aguja se vuelve a perder y, además, el coste de mantenerlo crece sin parar. Si guardamos poco, perdemos contexto valioso que tendremos que reconstruir penosamente cada vez. La respuesta probablemente depende de la situación, depende del dominio, del coste de equivocarse y de quién decide. Hay enfoques donde decide un modelo auxiliar mediante un clasificador de relevancia, otros donde decide el propio agente principal exponiendo la decisión como una llamada a herramienta, y otros donde se delega en heurísticas más simples, en reglas mecánicas y baratas, sin inteligencia detrás, que se basen en instrucciones mecánicas, como guardar lo que aparezca tres o más veces o lo último que dijo el usuario en los últimos N turnos.

La segunda disyuntiva es cuándo recuperar y esto es así porque recuperar memoria en cada turno es caro y, peor aún, contamina el contexto con información que muchas veces no hace falta. Recuperar solo cuando el agente lo decide explícitamente depende otra vez de que sepa cuándo necesita algo que no recuerda, lo cual es un problema clásico de meta-cognición que los modelos no resuelven especialmente bien. Se podría optar por una solución intermedia; una primera fase de recuperación ligera basada en similitud semántica con el turno actual y una segunda fase opcional donde el agente puede pedir más si lo necesita. Pero ahí volvemos a tropezar con toda la problemática de la selección, necesitamos embeddings, posiblemente reranking, y cuidado con el ruido.

Y la tercera, que es la más sutil, es la contaminación temporal, el equivalente diacrónico del context pollution que veíamos en los sistemas multiagente. Si el sistema recuerda que hace seis meses el usuario prefería un determinado estilo de respuesta, ¿sigue siendo cierto hoy? ¿Cuánto pesa esa preferencia frente a indicios contrarios en la conversación actual? Una memoria que no caduca arrastra al presente decisiones, preferencias y datos que pueden haber dejado de ser válidos. Una memoria que caduca demasiado pronto pierde justamente lo que la hacía útil. Aquí entran las políticas de forgetting, que la literatura llama elegantemente memory eviction y que en la práctica son tan rudimentarias como en cualquier caché: LRU (Least Recently Used), LFU (Least Frequently Used), ventanas temporales, decaimiento exponencial, etcétera.

Hay un cuarto problema, más siniestro, y es que la memoria es un vector de ataque. Si un agente lee de un almacén persistente que comparte con otros, basta con que en algún momento se inyecte una instrucción maliciosa en ese almacén para que aparezca, turnos o sesiones después, en el contexto activo. Es el prompt injection del bloque anterior, pero diferido en el tiempo y por eso más difícil de detectar. Cualquier sistema con memoria persistente necesita controles sobre quién puede escribir en ella y bajo qué condiciones, etcétera.

En conjunto, la memoria aumentada quizás sea la técnica más sugerente del context engineering, pero aún falta un estándar que encauce definitivamente la cuestión.

8. Arquitectura de un sistema moderno de contexto

Llegados a este punto conviene parar y mirar el conjunto. Las técnicas que hemos recorrido -selección, compresión, estructuración, routing y memoria- son piezas de una arquitectura más amplia que en los últimos dos años ha empezado a estabilizarse. Aunque la nomenclatura varía según quien la cuente, los sistemas modernos de IA basados en LLMs tienden a organizarse en cinco capas con responsabilidades bien delimitadas.

La capa de datos es la base, y comprende todo lo que vive fuera del modelo y aporta conocimiento al sistema: bases documentales, índices vectoriales para RAG, APIs hacia sistemas externos, bases de datos estructuradas, conectores a fuentes de información en tiempo real. Es la capa más antigua y la más madura, porque hereda décadas de ingeniería de datos previa al boom de los LLMs. Aquí no hay nada particularmente novedoso; simplemente reconocemos que un agente útil necesita estar conectado a fuentes de verdad que están fuera de su ventana.

La capa de contexto es la que articula todo lo que hemos ido viendo, es la que decide qué entra en la ventana, en qué orden, en qué formato y bajo qué reglas. Aquí viven los mecanismos de selección, los pasos de reranking, las políticas de compresión, las decisiones de estructuración, las reglas de descubribilidad. Es la capa que media entre la capa de datos (que tiene mucho) y la capa de agente (que sólo puede mirar a través de una rendija limitada).

La capa de memoria es la dimensión temporal que mantiene el estado del sistema más allá de la sesión activa, lo que el sistema ha aprendido sobre el usuario, sobre el dominio, sobre sus propias rutinas. Conceptualmente es una extensión de la capa de datos -al final son almacenes externos- pero merece capa propia porque sus políticas de escritura, lectura y caducidad son distintas, y porque su contenido lo genera el propio sistema en lugar de venir dado desde fuera.

La capa de herramientas expone al modelo la capacidad de ejecutar acciones sobre el mundo, como llamar a una API, lanzar una búsqueda, ejecutar código, modificar un archivo o mandar un correo. Es la frontera entre leer y escribir. Hasta hace poco los LLMs eran sistemas exclusivamente de lectura; con la capa de herramientas se vuelven sistemas que también escriben, y eso introduce toda una serie de problemas nuevos -de fiabilidad, de seguridad, de reversibilidad- que las anteriores no tenían.

La capa de agente es la que orquesta todo lo anterior. Aquí se razona, planifica y decide qué herramienta usar en cada momento, qué información solicitar a la capa de contexto, qué guardar en memoria y cuándo dar por terminada una tarea. Es la capa más visible para el usuario y, paradójicamente, la que menos código suele tener: en muchos sistemas reales no es más que un bucle que llama al LLM con un prompt cuidado, recoge su salida, ejecuta lo que el modelo haya decidido y vuelve a empezar. La inteligencia, si es que hay tal cosa, vive en el modelo; lo que esta capa aporta es la coreografía, la orquestación.

La virtud de este sistema en cinco capas es que separa con claridad tres preocupaciones que en los primeros agentes -los de hace dos años, que ahora ya vemos con cierta condescendencia- estaban revueltas: el conocimiento (qué sabe el sistema), el estado (qué recuerda) y el razonamiento (qué decide hacer con ello). Cuando esas tres cosas viven en el mismo prompt, todo es frágil. Cuando se separan, cada capa se puede evolucionar, depurar y reemplazar por su cuenta. La capa de datos se versiona como cualquier base de datos. La de memoria se monitoriza con sus propias métricas de hit ratio. La de herramientas se prueba con tests unitarios. Y la de agente, que es la más impredecible, aunque también se puede controlar con guardrails, queda aislada lo suficiente como para que su no-determinismo no contamine al resto.

Esta arquitectura, además, deja al modelo en el sitio que le corresponde. El LLM no es la aplicación; es un componente de la aplicación, probablemente el más caro y el más caprichoso, pero un componente al fin y al cabo. Las cinco técnicas del context engineering son, en el fondo, formas de tratarlo como tal, como un servicio externo con una interfaz limitada, al que conviene mandarle exactamente lo que necesita, ni más ni menos, y al que conviene no pedirle cosas para las que hay herramientas mejores.

9. Gobernanza del contexto

Termino esta introducción al context engineering con una cuestión con la que llevamos años lidiando en el mundo del software y que también se está llevando a los sistemas basados en LLMs. Por mucha ingeniería de contexto que se haga, si nadie sabe qué entró en el prompt en el momento en que el modelo respondió aquello tan raro, no hay forma de depurar nada. El contexto, igual que el código, igual que los datos, igual que cualquier otro insumo del sistema, necesita gobernarse. Y esto, que en otros campos de la ingeniería se da por descontado, en el mundo de los LLMs todavía está algo lejos.

Gobernar el contexto significa, fundamentalmente, cuatro cosas. La primera es versionarlo. Los prompts del sistema, las plantillas, los esquemas XML que estructuran el contexto, las instrucciones que definen a cada subagente, todo eso son artefactos que cambian a lo largo del tiempo y cuyos cambios afectan al comportamiento del modelo de forma a veces dramática. Y, por lo tanto, conviente tratarlos como cualquier otra pieza de código código, esto es, con control de versiones, pull requests, revisión, release, etcétera.

La segunda es trazar qué contexto influyó en cada respuesta. En un sistema con RAG, reranking, memoria persistente y routing dinámico, una misma pregunta puede recibir respuestas distintas según qué fragmentos se hayan recuperado, qué memoria se haya consultado y qué subagente haya intervenido. Si esa trazabilidad no se registra, las respuestas del sistema son objetos opacos sobre los que no se puede razonar. Si se registra, en cambio, podemos volver atrás meses después y reconstruir por qué el modelo dijo lo que dijo.

La tercera es la higiene del contenido. Lo que vive en los almacenes que alimentan el contexto, ya sean bases documentales, índices vectoriales o memorias persistentes, envejece. Los documentos quedan obsoletos, las políticas cambian, los hechos sobre el usuario dejan de ser ciertos. Sin un proceso explícito de revisión, depuración y caducidad, el sistema acaba sirviendo contexto que era válido hace dos años y que hoy es directamente incorrecto. Y esto implica flujos de revisión humana y automatizada que decidan qué se queda, qué se actualiza y qué se descarta, y con qué frecuencia.

Y la cuarta es el control de quién escribe en el contexto. Como hemos visto, si la memoria persistente acepta inyecciones sin control, el sistema puede quedar expuesto a prompt injection diferido. De hecho, el problema de la seguridad afecta a toda la cadena. Como ocurre con los formularios de una web, cualquier punto del sistema donde entre información que vaya a acabar en un prompt es una puerta por donde puede colarse contenido malicioso, sesgado o simplemente erróneo. Gobernar el contexto implica preguntarse, para cada una de esas puertas, quién tiene permiso para abrirla, bajo qué condiciones y con qué garantías de revisión posterior.

Nada de esto es nuevo. Es básicamente lo mismo que se hace en cualquier sistema serio con sus datos: control de versiones, trazabilidad, calidad, permisos, seguridad por diseño, principio del menor privilegio. Son prácticas muy interiorizadas en el mundo del software convencional que se deben ir traslandando a los sistemas agénticos, ya que su descuido puede ser igual de dañino. Prácticas que hoy parecen exageradas, como versionar prompts, auditar memorias o restringir quién escribe en los almacenes, en nada van a ser tan obvias como hoy lo son las migraciones versionadas en una base de datos.

Bueno, volveré sobre esta cuestión en otro artículo ad hoc. De momento lo dejo aquí.

10. Epílogo: harness engineering

El context engineering se puede considerar una de las caras de algo más amplio que la industria empieza a llamar harness engineering: la idea de que un agente es un modelo más un arnés -todo lo que envuelve al LLM y no es el LLM- y que el arnés, no el modelo, es lo que decide si la cosa funciona en producción. El contexto es solo una pieza de ese arnés; la memoria, las herramientas, la orquestación y los protocolos entre agentes son las otras. El reto de los próximos años será ver cómo se integra todo en un marco coherente.

Pero lo más probable es que dentro de cinco años no hablemos ya ni de context engineering ni de harness engineering sino, simplemente, de ingeniería de software. Que es, al final, donde acaban todas las disciplinas basadas en ceros y unos.

Para saber más

Sobre la problemática del contexto

• Hsieh, Cheng-Ping; Sun, Simeng; Kriman, Samuel; Acharya, Shantanu; Rekesh, Dima; Jia, Fei; Zhang, Yang; Ginsburg, Boris. RULER: What's the Real Context Size of Your Long-Context Language Models? arXiv preprint arXiv:2404.06654, 2024. arXiv:2404.06654
• Kamradt, Greg. LLMTest_NeedleInAHaystack. GitHub repository, 2023. GitHub: LLMTest Needle In A Haystack
• Liu, Nelson F.; Lin, Kevin; Hewitt, John; Paranjape, Ashwin; Bevilacqua, Michele; Petroni, Fabio; Liang, Percy. Lost in the Middle: How Language Models Use Long Contexts. arXiv preprint arXiv:2307.03172, 2023. arXiv:2307.03172
• Mu, Jian; Zhang, Qixin; Wang, Zhiyong; Yang, Menglin; Qiu, Shuang; Qin, Chengwei; Dai, Zhongxiang; Shu, Yao. Self-Reflective Generation at Test Time. arXiv preprint arXiv:2510.02919, 2025. arXiv:2510.02919
• Zhang, Muru; Press, Ofir; Merrill, William; Liu, Alisa; Smith, Noah A. How Language Model Hallucinations Can Snowball. arXiv preprint arXiv:2305.13534, 2023. arXiv:2305.13534

Sobre context engineering

• Lütke, Tobi. Tweet sobre context engineering. 19 de junio de 2025. Enlace
• Karpathy, Andrej. Tweet sobre context engineering. 25 de junio de 2025. Enlace
• Schmid, Philipp. The New Skill in AI is Not Prompting, It's Context Engineering. philschmid.de, 30 de junio de 2025. Enlace
• Ji, Yichao (Manus). Context Engineering for AI Agents: Lessons from Building Manus. Manus Blog, 2025. Enlace
• Anthropic Engineering. Effective Context Engineering for AI Agents. 2025. Enlace
• Griciūnas, Aurimas. State of Context Engineering in 2026. SwirlAI Newsletter, 2026. Enlace
• Hua, Qishuo; Ye, Lyumanshan; Fu, Dayuan; Xiao, Yang; Cai, Xiaojie; Wu, Yunze; Lin, Jifan; Wang, Junfei; Liu, Pengfei. Context Engineering 2.0: The Context of Context Engineering. arXiv preprint arXiv:2510.26493, 2025. arXiv:2510.26493

Sobre selección y reranking

• Dixit, Vaibhav. Reranking in RAG: Cross-Encoders, Cohere Rerank & FlashRank. Medium, marzo 2026. Enlace
• EY/KA Lab. Reranking in RAG: Enhancing Accuracy with Cross-Encoders. 2024. Enlace

Sobre compresión y olvido

• Jiang, Huiqiang et al. LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models. EMNLP, 2023. arXiv:2310.05736
• Pan, Zhuoshi et al. LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression. 2024. arXiv:2403.12968
• Kang, Minki et al. ACON: Optimizing Context Compression for Long-Horizon LLM Agents. ICLR, 2026. arXiv:2510.00615
• Du, P. Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers. 2026. arXiv:2603.07670
• Nayak, P. Automatic Context Compression in LLM Agents: Why Agents Need to Forget and How to Help Them Do It. The AI Forum, Medium, 2026. Enlace
• Santoni, C. Contextual Memory Virtualisation. Imperial College London, 2026. arXiv:2602.22402

Sobre estructuración del contexto

• Alpay, F.; Alpay, T. XML Prompting as Grammar-Constrained Interaction. 2025. arXiv:2509.08182
• Liu, Z. et al. Enhancing LLM's Cognition via Structurization. 2024. arXiv:2407.16434
• Duarte, R. Markdown vs. XML in LLM Prompts: A Comparative Analysis. 2025. Enlace
• Anthropic. Use XML Tags. Documentación oficial. Enlace

Sobre aislamiento y routing

• Liu, J. et al. RCR-Router: Efficient Role-Aware Context Routing for Multi-Agent LLM Systems. 2025. arXiv:2508.04903
• Patel, N. Dynamic Attentional Context Scoping (DACS). 2026. arXiv:2604.07911
• Ruan, J. T. Context Engineering in LLM-Based Agents. Medium, 2025. Enlace
• PromptLayer. Dynamic Multi-Agent Orchestration Learns Task Routing. 2026. Enlace
• Swfte AI. Intelligent LLM Routing: How Multi-Model AI Cuts Costs by 85%. 2026. Enlace
• LogRocket. The LLM Context Problem in 2026: Strategies for Memory, Relevance, and Scale. 2026. Enlace
• Anthropic; Google. Model Context Protocol (MCP) y Agent-to-Agent (A2A). Estándares abiertos de comunicación entre agentes, 2024-2025.

Sobre memoria aumentada

• Sumers, Theodore R.; Yao, Shunyu; Narasimhan, Karthik; Griffiths, Thomas L. Cognitive Architectures for Language Agents (CoALA). Transactions on Machine Learning Research, 2024. arXiv preprint arXiv:2309.02427, 2023. arXiv:2309.02427
• Packer, Charles; Wooders, Sarah; Lin, Kevin; Fang, Vivian; Patil, Shishir G.; Stoica, Ion; Gonzalez, Joseph E. MemGPT: Towards LLMs as Operating Systems. arXiv preprint arXiv:2310.08560, 2023. arXiv:2310.08560
• Chhikara, Prateek; Khant, Dev; Aryan, Saket; Singh, Taranjeet; Yadav, Deshraj. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv preprint arXiv:2504.19413, 2025. arXiv:2504.19413
• Rasmussen, Preston; Paliychuk, Pavlo; Beauvais, Travis; Ryan, Jack; Chalef, Daniel. Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv preprint arXiv:2501.13956, 2025. arXiv:2501.13956
• Park, Joon Sung et al. Generative Agents: Interactive Simulacra of Human Behavior. 2023. (Uso temprano del concepto de episodic stream.)
• LangChain. Memory Overview. Documentación oficial de LangGraph. Enlace

Sobre gobernanza del contexto

• OWASP Foundation. OWASP Top 10 for LLM Applications 2025. Noviembre 2024. PDF oficial
• Palo Alto Networks Unit 42. When AI Remembers Too Much: Persistent Behaviors in Agents' Memory. Octubre 2025. Enlace
• Devarangadi Sunil et al. Memory Poisoning Attack and Defense on Memory-Based LLM-Agents. 2026.
• MemoryGraft: Persistent Compromise of LLM Agents via Poisoned Experience Retrieval. Diciembre 2025.
• Lakera. Indirect Prompt Injection: The Hidden Threat Breaking Modern AI Systems. 2026. Enlace
• Sawant, Udayan. Observability in Production LLM Systems. Medium, abril 2026. Enlace
• Portkey. The Complete Guide to LLM Observability for 2026. Enero 2026. Enlace

Sobre harness engineering

• Hashimoto, Mitchell. Agent Harness. Febrero 2026. (El post que popularizó el término.)
• Fowler, Martin (ed.). Harness Engineering for Coding Agent Users. Martin Fowler Blog, abril 2026. Enlace