Los agentes de IA parecen tener continuidad, pero por defecto no la tienen. Cada sesión es una invocación nueva con una ventana de contexto limitada y una reconstrucción aproximada de lo que ocurrió antes. El problema no es "hacer un prompt más largo". El problema es decidir qué información merece sobrevivir, dónde vive, cómo se consulta, cuándo caduca y cómo se evita que una memoria vieja contamine decisiones nuevas.
A eso me refiero cuando hablo de context engineering para agentes IA con memoria persistente: no es una técnica aislada de prompting, sino una capa de producto e infraestructura. En mis sistemas bajo solu30, la memoria de agentes no es un archivo gigante pegado al prompt. Es una combinación de base de datos, scopes, TTL, reglas de promoción y recuperación selectiva. En el sistema de memoria que opero para mis agentes bajo solu30, la memoria con TTL adecuado redujo los conflictos de contexto en 3 veces comparado con sistemas que acumulan todo sin expiración. Una memoria sin TTL es una deuda que crece hasta contaminar decisiones.
El problema real: agentes sin estado
Un agente que trabaja sobre código, operaciones o producto necesita continuidad. Tiene que recordar convenciones del repositorio, decisiones tomadas en sesiones anteriores, preferencias del usuario, restricciones de seguridad y tareas que no deberían repetirse.
Pero el modelo no tiene estado durable. El historial crece, mezcla información relevante con ruido y suele contener datos que ya no son válidos.
Por eso separo memoria de conversación. La conversación es evidencia. La memoria es una síntesis operacional de esa evidencia. Esa diferencia es importante: no todo lo que se dijo en una sesión debe convertirse en memoria. Una buena memoria es pequeña, verificable, consultable y tiene un alcance claro.
Principios de diseño
La capa de context engineering para agentes IA con memoria persistente que uso parte de cuatro principios.
Toda memoria tiene scope. Una preferencia personal no debe mezclarse con una regla de un repositorio. Una decisión de arquitectura de un proyecto no tiene por qué afectar otro producto.
Toda memoria tiene vigencia. Algunas cosas son permanentes, como "no modificar archivos de autenticación sin instrucción explícita". Otras son temporales, como "la rama actual tiene tests fallando por una migración incompleta". Sin TTL, la memoria se transforma en deuda.
La recuperación debe ser selectiva. El agente no necesita toda la memoria. Necesita la memoria relevante para esta tarea, este usuario y este momento.
La memoria tiene que ser auditable. Quiero saber de dónde salió una afirmación, cuándo fue escrita y cuándo debería revisarse.
Scopes: personal, ecosystem, project, repository, task, session
| Scope | Ejemplos de contenido | TTL recomendado |
|---|---|---|
| personal | Preferencias de comunicación, idioma, horarios | Sin expiración |
| ecosystem | Reglas de seguridad transversales, convenciones globales | Sin expiración |
| project | Objetivo del producto, stack, clientes actuales | 1 año |
| repository | Convenciones de código, archivos sensibles, comandos | 6 meses |
| task | Estado parcial de tarea activa | 14 días |
| session | Resumen de la sesión actual | 7 días |
La estructura de scopes es la parte más importante del diseño. Sin scopes, la memoria se vuelve una bolsa de texto.
type MemoryScope =
| "personal"
| "ecosystem"
| "project"
| "repository"
| "task"
| "session";
personal contiene preferencias durables del usuario. ecosystem contiene reglas que cruzan varios proyectos. project describe un producto o iniciativa. repository baja al nivel del código. task contiene memoria temporal vinculada a una tarea activa. session es memoria efímera con TTL corto.
El orden de aplicación importa: primero cargo reglas globales y preferencias personales, después contexto de ecosystem, luego project/repository, y al final task/session.
Esquema de base de datos
Para memoria dinámica prefiero base de datos. Necesito filtrar, ordenar, expirar, auditar y relacionar registros.
create table agent_memories (
id uuid primary key,
user_id uuid not null,
scope text not null,
scope_key text not null,
kind text not null,
content text not null,
confidence numeric not null default 0.7,
importance integer not null default 3,
source_type text not null,
expires_at timestamptz,
promoted_at timestamptz,
archived_at timestamptz
);
scope dice el tipo de alcance. kind ayuda a clasificar: preference, rule, decision, fact, warning, command, failure, pattern. source_type es crítico: una memoria puede venir de una sesión, un PR o una promoción manual.
TTL: la defensa contra contexto viejo
Tres señales de que la memoria necesita TTL más agresivo:
- El agente hace referencia a decisiones que ya cambiaron — stack o arquitectura que ya no aplica.
- La memoria crece más de 20 por ciento por semana sin revisión — acumulación sin curaduría.
- El agente contradice instrucciones actuales con "antes dijiste" — memoria vieja dominando sobre instrucción nueva.
El TTL no es un detalle operativo. Es una defensa de calidad.
const defaultTtlByKind = {
session_summary: "7 days",
task_state: "14 days",
investigation_note: "30 days",
repository_command: "90 days",
architecture_decision: null,
user_preference: null,
safety_rule: null,
};
null significa sin expiración automática, no sin revisión. Para memorias permanentes conviene tener un campo review_after.
Promoción: de sesión a memoria durable
La mayoría de las memorias empiezan como notas de sesión. Promuevo una memoria cuando cumple al menos una de estas condiciones: representa una instrucción explícita del usuario, corrige un error que ya ocurrió y probablemente se repetiría, describe una convención estable del proyecto, o fue confirmada por código o documentación.
No promuevo observaciones vagas como "parece que este repo usa X" si no fueron verificadas. Tampoco promuevo estados transitorios sin TTL corto.
Recuperación: qué entra al prompt
La recuperación ocurre antes de llamar al modelo. Una estrategia simple:
- Identificar usuario, ecosistema, proyecto, repo y tarea.
- Cargar reglas críticas no expiradas.
- Recuperar preferencias personales relevantes.
- Traer memorias del proyecto y repo por scope.
- Ejecutar búsqueda semántica contra la tarea actual.
- Ordenar por importancia, especificidad, recencia y confianza.
- Recortar al presupuesto de tokens.
El resultado final no debería ser una lista interminable. Prefiero un bloque compacto que el modelo pueda consumir directamente.
Para ver cómo se conecta esto con el sistema de coordinación, el artículo sobre trabajar con agentes IA sin perder contexto describe la capa operativa desde el lado del equipo. El artículo sobre CLAUDE.md como contrato muestra cómo documentar las reglas que la memoria debe respetar.
Si estás construyendo una capa de memoria para agentes y querés revisar el diseño, trabajo en eso desde solu30.
Preguntas frecuentes
¿Qué es context engineering para memoria persistente de agentes? Es el diseño de la capa que decide qué información debe sobrevivir entre sesiones. No se trata de hacer prompts más largos, sino de definir memoria con alcance, caducidad, recuperación selectiva y reglas claras.
¿Por qué un agente IA necesita memoria persistente? Porque por defecto el modelo no tiene estado durable entre sesiones. Si querés que recuerde decisiones o restricciones de seguridad, esa información debe guardarse fuera del modelo.
¿Cuál es la diferencia entre conversación y memoria? La conversación es evidencia de lo que ocurrió en una sesión. La memoria es una síntesis operacional, pequeña y verificable, que decidís reutilizar en futuras tareas.
¿Por qué no conviene guardar toda la conversación como memoria? Porque el historial mezcla información útil con ruido y datos vencidos. Una observación vieja puede contaminar decisiones nuevas del agente.
¿Qué elementos debe tener una buena arquitectura de memoria para agentes? Una base de datos durable, scopes para separar contextos, TTL para caducar información, reglas de promoción y recuperación selectiva.