Ingeniería de contexto para agentes de IA: memoria, retrieval y contexto de trabajo
Una guía práctica de arquitectura para context engineering en agentes de IA: qué debe estar en contexto activo, qué conviene recuperar, qué debe persistir como memoria y cuándo recortar o compactar estado.
En este artículo
El problema con el contexto de un agente normalmente no es que el modelo tenga poca información.
Es que el sistema no ha decidido qué información merece estar activa en este momento.
Un agente puede tener acceso a una ventana de contexto grande, una base vectorial, memoria persistente, decenas de tools, una conversación extensa y estado de aplicación en tiempo real, y aun así rendir mal porque demasiada información irrelevante llega al modelo en el momento equivocado.
Ese es el problema central que intenta resolver la ingeniería de contexto —o context engineering.
Prompt engineering pregunta cómo deben redactarse las instrucciones. Context engineering plantea una pregunta de sistemas más amplia:
¿Qué información debe ver el modelo en este paso, de dónde debe venir, cuánto tiempo debe permanecer disponible y qué debe descartarse?
Para agentes, la diferencia importa porque el contexto no es estático. Cada tool call, observación, mensaje, documento recuperado, plan, error y resultado intermedio puede convertirse en contexto candidato para el siguiente turno.
La tarea de ingeniería no es maximizar contexto. Es curar el estado de trabajo.
Un modelo mental útil: cuatro cosas distintas
Contexto, memoria, retrieval e historial suelen tratarse como si fueran lo mismo. No deberían.
Una arquitectura práctica separa por lo menos cuatro capas.
1. Contexto de trabajo
El contexto de trabajo es lo que el modelo puede atender directamente durante el paso de inferencia actual.
Puede incluir:
- instrucciones del sistema;
- la solicitud actual del usuario;
- turnos recientes de conversación;
- definiciones de tools;
- resultados seleccionados de tools;
- documentos recuperados;
- un plan o estado de trabajo actual;
- observaciones del entorno.
Es el espacio de trabajo activo del modelo.
2. Retrieval
Retrieval es el mecanismo que decide qué información externa debe entrar al contexto de trabajo.
Esa información puede venir de:
- documentación;
- bases de datos;
- repositorios de código;
- bases de conocimiento;
- conversaciones anteriores;
- índices de búsqueda;
- archivos;
- APIs externas.
Retrieval no implica automáticamente memoria. Un sistema puede recuperar un manual de producto sin recordar nada sobre el usuario.
3. Memoria persistente
La memoria es información que se conserva intencionalmente entre turnos, sesiones o tareas porque puede mejorar el comportamiento futuro.
Ejemplos:
- una corrección hecha por el usuario;
- una restricción estable de un proyecto;
- una decisión ya aprobada;
- un modo de falla conocido;
- una preferencia que debe afectar respuestas futuras;
- un handoff compacto de una sesión de trabajo larga.
La memoria es una política de escritura tanto como una política de lectura. Un buen sistema debe decidir qué vale la pena guardar y cuándo vale la pena volver a cargarlo.
4. Estado externo
Parte de la información no debería representarse como memoria del modelo en absoluto.
El estado autoritativo ya puede vivir en:
- una base de datos;
- Git;
- un issue tracker;
- un calendario;
- un sistema de cuentas;
- un ledger de pagos;
- una aplicación en ejecución;
- un filesystem.
Si el agente puede consultar la fuente de verdad cuando la necesita, copiar ese estado a memoria a largo plazo puede volver el sistema menos confiable en lugar de más confiable.
La primera regla de diseño es simple:
No uses memoria para duplicar una fuente de verdad que el agente puede consultar directamente.
Ventanas de contexto más grandes no eliminan el problema de arquitectura
Es tentador asumir que context engineering será menos importante conforme crezcan las ventanas de contexto.
En la práctica, una ventana más grande reduce una restricción, pero deja intactas otras.
Anthropic describe el contexto como un recurso finito de atención y propone buscar el conjunto más pequeño de tokens de alta señal que aumente la probabilidad del comportamiento deseado. Su guía también señala un problema conocido: los contextos largos pueden acumular información irrelevante o desactualizada aunque técnicamente quepan dentro de la ventana del modelo.
La guía de OpenAI sobre session memory llega a una conclusión similar desde la implementación. Un agente de larga duración puede arrastrar demasiado historial, aumentando distracción, latencia y costo. Entre las herramientas propuestas están recortar turnos antiguos y comprimir historial en resúmenes en lugar de tratar cada token previo como si tuviera el mismo valor.
La distinción importante es:
La capacidad responde cuánto cabe. La ingeniería de contexto responde qué debería estar presente.
Son preguntas diferentes.
El contexto debe ensamblarse, no acumularse
Un agent loop ingenuo suele funcionar así:
- añade el mensaje más reciente;
- añade el tool call;
- añade el resultado completo de la tool;
- añade el siguiente mensaje;
- repite indefinidamente.
Esto convierte el transcript en el modelo de estado del agente.
Funciona para tareas cortas. Se vuelve frágil en trabajo prolongado.
Una arquitectura más sólida ensambla el contexto de cada paso desde fuentes controladas.
Por ejemplo:
- instrucciones estables del sistema;
- objetivo actual;
- representación compacta del progreso;
- sólo los turnos recientes que siguen siendo relevantes;
- tools necesarias para la fase actual;
- evidencia recuperada para la pregunta actual;
- estado vivo de sistemas autoritativos cuando sea necesario.
El transcript completo puede seguir almacenándose para observabilidad y auditoría sin obligar al modelo a releerlo en cada turno.
Precarga únicamente lo que sea predeciblemente útil
Parte del contexto sí debe estar disponible desde el inicio.
Buenos candidatos para precarga incluyen:
- instrucciones que definen la tarea;
- límites de seguridad y permisos;
- requisitos de salida;
- un número pequeño de restricciones estables del proyecto;
- contratos de tools que el modelo necesita entender inmediatamente.
Malos candidatos incluyen:
- colecciones completas de documentación;
- todos los resultados de tareas anteriores;
- todas las tools soportadas por el sistema;
- logs extensos;
- repositorios completos;
- todo el historial de interacción del usuario.
Mientras más incierta sea la relevancia de cierta información, más sentido tiene recuperarla después en lugar de precargarla.
Por eso la guía actual de Anthropic enfatiza just-in-time retrieval: mantener referencias ligeras disponibles y permitir que el agente cargue información profunda sólo cuando la tarea realmente la requiere.
Retrieval debe responder una pregunta concreta
RAG suele presentarse como una solución genérica al problema de contexto.
Pero la calidad del retrieval depende de qué incertidumbre intenta resolver el sistema.
Antes de recuperar información, conviene preguntar:
- ¿Qué incertidumbre intenta reducir el agente?
- ¿Qué fuente sería autoritativa para resolverla?
- ¿Cuánta evidencia es suficiente?
- ¿Qué tan fresca debe ser?
- ¿Qué permisos aplican?
Supongamos que un agente está investigando un incidente de producción.
Retrieval útil podría incluir:
- el error actual;
- la configuración del servicio afectado;
- cambios recientes en ese componente;
- el runbook de ese servicio.
Recuperar veinte documentos genéricos de arquitectura porque son semánticamente parecidos puede hacer al modelo menos enfocado.
El trabajo de Anthropic sobre Contextual Retrieval aborda una parte de este problema: los chunks pueden perder significado cuando se separan de su documento original, por lo que añadir un contexto compacto del documento antes de indexar puede mejorar el retrieval posterior.
El principio más general importa más que la técnica específica:
retrieval debe conservar suficiente significado para que la evidencia recuperada siga siendo útil una vez dentro del contexto de trabajo.
La memoria debe conservar información difícil de reconstruir
Un sistema de memoria persistente aporta más valor cuando la información es importante y costosa de inferir otra vez.
La arquitectura del agente de datos interno de OpenAI es un ejemplo útil. El agente guarda correcciones, filtros y restricciones no evidentes que son importantes para consultar correctamente datos internos. No utiliza la memoria como una copia del data warehouse. Los datos vivos y metadatos siguen consultándose desde sus sistemas autoritativos.
Esa separación es una buena regla de diseño.
Buenos candidatos para memoria suelen ser:
- correcciones del usuario;
- terminología específica del proyecto;
- restricciones estables;
- decisiones y su justificación;
- lecciones de fallos;
- preferencias duraderas;
- handoffs compactos de tareas.
Malos candidatos suelen ser:
- respuestas temporales de APIs;
- inventario actual;
- balances en vivo;
- logs crudos;
- documentación que cambia rápidamente;
- información que puede volver a consultarse de forma barata y autoritativa.
El costo de una mala memoria no es sólo almacenamiento.
Una memoria desactualizada puede empujar activamente al agente hacia una acción incorrecta.
La memoria necesita reglas de escritura
La arquitectura de memoria más peligrosa es “guardar todo lo que parezca útil”.
Eso crea un segundo historial sin control.
Un sistema más sólido define criterios explícitos de escritura.
Antes de persistir algo, pregunta:
- ¿Es probable que vuelva a importar?
- ¿Seguirá siendo cierto el tiempo suficiente para ser útil?
- ¿Reconstruirlo después sería costoso o poco confiable?
- ¿Guardarlo introduce riesgo de privacidad o permisos?
- ¿Puede consultarse la fuente de verdad original en su lugar?
Puedes pensar en la memoria como un cache con consecuencias semánticas.
Guardar lo incorrecto no es neutral.
Los agentes de larga duración necesitan compaction
Incluso un contexto activo bien curado puede crecer demasiado.
Compaction consiste en reemplazar una gran cantidad de contexto anterior por una representación más pequeña de la información que debe sobrevivir.
Un estado compactado útil puede conservar:
- el objetivo;
- trabajo ya completado;
- decisiones tomadas;
- problemas pendientes;
- hipótesis actuales;
- archivos o recursos relevantes;
- validación ya realizada;
- siguientes pasos explícitos.
Y puede descartar:
- resultados redundantes de tools;
- hipótesis ya reemplazadas;
- confirmaciones repetidas;
- razonamiento intermedio extenso que ya no afecta la tarea.
Anthropic describe compaction y structured note-taking como técnicas centrales para agentes de horizonte largo. Su trabajo más reciente sobre managed agents separa todavía más claramente la sesión persistente de la ventana de contexto actual del modelo, porque no todo token histórico debe seguir activo para que el trabajo continúe.
Esa es una frontera arquitectónica útil:
la sesión es el registro durable; la ventana de contexto es el conjunto temporal de trabajo.
Trimming y compaction no son lo mismo
Las técnicas están relacionadas, pero no son idénticas.
Trimming elimina material de acuerdo con una regla.
Ejemplos:
- conservar sólo los últimos N turnos;
- eliminar resultados antiguos de tools;
- remover bloques previos de reasoning;
- conservar únicamente mensajes posteriores al último checkpoint.
Compaction transforma material en una representación más pequeña.
Ejemplos:
- resumir trabajo completado;
- convertir una interacción larga en un handoff estructurado;
- persistir decisiones en un objeto de estado de tarea;
- reducir varios traces de tools a conclusiones verificadas.
Trimming es más barato y seguro cuando el contenido antiguo es claramente desechable.
Compaction es mejor cuando la información debe sobrevivir pero el historial crudo es demasiado costoso o distractor.
Un sistema robusto suele utilizar ambos.
Los resultados de tools necesitan una política agresiva de contexto
Los resultados de tools son una de las formas más rápidas de contaminar el contexto de un agente.
Una sola página web, consulta SQL, salida de terminal o respuesta de API puede ocupar miles de tokens.
En vez de arrastrar resultados crudos indefinidamente, extrae lo que realmente necesita el siguiente paso.
Por ejemplo:
- página web → hechos relevantes + URL de fuente;
- tests → fallos + stack traces importantes;
- consulta de base de datos → filas necesarias para la decisión;
- búsqueda en repo → paths relevantes + excerpts;
- respuesta de API → transición de estado + identificadores.
Conserva el artifact original en un lugar recuperable cuando la auditoría importe.
No lo obligues a permanecer en contexto de trabajo sólo porque existió en un turno anterior.
Frescura y permisos también son context engineering
El contexto correcto no sólo debe ser relevante. También debe ser actual y estar autorizado.
Una memoria escrita hace seis meses puede contradecir el estado actual de una base de datos.
Un documento recuperado puede ser relevante pero no estar disponible para el usuario actual.
Un resultado de una tool puede exponer más información de la que necesita el siguiente turno.
Cada fuente de contexto debería llevar metadatos como:
- origen;
- timestamp o versión;
- ownership;
- scope de permisos;
- confianza o estado de verificación;
- política de expiración cuando corresponda.
Esto se vuelve especialmente importante cuando los agentes combinan conocimiento organizacional con información específica de usuarios.
Retrieval sin access control es un bug de seguridad.
Memoria sin política de frescura es un bug de confiabilidad.
Una arquitectura práctica de contexto
Un agente de producción puede usar una estructura por capas como ésta:
| Información | Ubicación por defecto | Política de carga |
|---|---|---|
| Reglas del sistema | Contexto de trabajo | Siempre |
| Solicitud actual | Contexto de trabajo | Siempre |
| Interacción reciente | Contexto de trabajo | Ventana acotada |
| Plan/progreso actual | Estado estructurado | Mientras la tarea esté activa |
| Documentación | Índice de retrieval | Bajo demanda |
| Estado vivo de aplicación | Fuente de verdad | Consultar bajo demanda |
| Restricciones duraderas | Memoria persistente | Recuperar cuando sean relevantes |
| Resultados crudos de tools | Artifact/log store | Sólo cuando sean necesarios |
| Historial de sesión largo | Registro durable | Compactar/recortar antes de pasarlo al modelo |
Los componentes exactos pueden variar, pero la separación importa.
Cuando todo se convierte en “memoria”, nada tiene un lifecycle claro.
Modos de falla comunes
Context stuffing
El sistema carga todo lo que podría ser relevante.
Resultado: alto costo de tokens, distracción y peor atención sobre la evidencia que realmente importa.
Memoria desactualizada
Información vieja se trata como autoritativa después de que el sistema real cambió.
Resultado: decisiones seguras en apariencia, pero basadas en estado obsoleto.
Retrieval ruidoso
Se recuperan documentos semánticamente relacionados aunque no respondan la pregunta actual.
Resultado: reasoning plausible pero desenfocado.
Summary drift
Compresiones repetidas eliminan detalles o modifican lentamente su significado.
Resultado: el agente conserva coherencia, pero sobre una representación incorrecta de la tarea.
Acumulación de tool results
Cada observación grande permanece para siempre en la conversación.
Resultado: el contexto útil queda enterrado bajo residuos operacionales.
Memory overreach
El sistema persiste información que debía ser temporal o privada.
Resultado: problemas de privacidad, permisos y comportamiento en sesiones futuras.
Evalúa la política de contexto como parte del agente
Context engineering debe evaluarse, no tratarse como plumbing invisible.
Experimentos útiles incluyen:
- historial completo vs. historial recortado;
- documentos precargados vs. just-in-time retrieval;
- resultados crudos de tools vs. observaciones extraídas;
- sin memoria vs. memoria estructurada;
- diferentes estrategias de compaction;
- inyección deliberada de memoria fresca y desactualizada;
- retrieval con y sin filtros de metadata.
Mide resultados downstream:
- task success;
- latencia;
- consumo de tokens;
- cantidad de tool calls;
- fallos de grounding o alucinación;
- recuperación después de sesiones largas;
- violaciones de policy;
- retrievals innecesarios.
El objetivo no es minimizar tokens por sí mismo.
El objetivo es maximizar evidencia útil por token de contexto activo.
La regla de diseño
Trata el contexto como un conjunto de trabajo, no como un archivo histórico.
Mantén pequeñas las instrucciones estables. Recupera conocimiento grande just-in-time. Persiste únicamente información costosa de reconstruir y con alta probabilidad de volver a importar. Consulta sistemas vivos en lugar de memorizar estado volátil. Recorta historial desechable. Compacta la información que debe sobrevivir.
La arquitectura de agente más fuerte no es la que recuerda todo.
Es la que puede decidir de forma confiable qué recordar, qué recuperar, qué volver a verificar y qué olvidar.