Memoria en agentes de IA: qué guardar, comprimir y tirar
En una llamada a un modelo no hay memoria. Cada turno es una petición nueva y el modelo solo sabe lo que has montado esta vez. Todo lo que la gente describe como que el agente olvida, o que empeora en una ejecución larga, es una decisión que tomó tu código sobre qué arrastrar.
Aceptado eso, el diseño de memoria se vuelve un problema de ingeniería con forma conocida: qué es siempre relevante, qué es relevante hace poco, qué se puede resumir y qué conviene traer fresco en vez de guardar.
Las cuatro capas#
| Capa | Contenido | ¿Se recorta? | Tamaño típico |
|---|---|---|---|
| Fijada | Objetivo, restricciones, identidad, política | Nunca | 200–500 tokens |
| Reciente | Últimos turnos literales, con resultados | Ventana deslizante | 2–5 turnos |
| Comprimida | Turnos antiguos como notas factuales | Se reescribe al crecer | Menos de 500 tokens |
| Recuperada | Documentos traídos para este paso | Se descarta tras usar | Por paso |
Comprime hechos, no prosa#
El error habitual es resumir los turnos antiguos como narración: la clienta preguntó por su pedido y el agente lo consultó. Se lee bien y no ayuda. Comprime a los hechos que un paso posterior podría necesitar: pedido 4471, estado enviado, se pidió reembolso, política de 30 días, aún sin reembolsar. Estructurado, comprobable y diez veces más pequeño.
Comprime al llegar a un umbral, no en cada turno. Resumir resúmenes es cómo desaparecen los detalles en silencio.
Recuperar no es recordar#
Los documentos traídos de una base de conocimiento pertenecen al paso que los necesitó. Mantenerlos en el contexto después es la vía rápida a una ejecución hinchada, cara y distraída. Trae, usa, cita, descarta — y si un paso posterior necesita el mismo hecho, tráelo otra vez. Recuperar es barato; un contexto lleno de documentos viejos no.
Memoria persistente entre sesiones#
Los agentes de larga vida acumulan hechos útiles sobre una persona o cuenta: preferencias, decisiones previas, restricciones que no cambiarán. Guárdalos a propósito, en un registro pequeño y estructurado con un paso de escritura explícito, en vez de dejar crecer el historial. Tres reglas lo mantienen sano: escribe solo hechos sobre los que una ejecución futura actuaría, guarda siempre la procedencia y da a cada hecho una caducidad.
- Escribe a propósito: una llamada a herramienta, no un efecto colateral.
- Guarda fuente y fecha junto a cada hecho.
- Limita el tamaño y caduca lo que no se usa.
- Deja que la persona vea y corrija lo que se guarda sobre ella.
Síntomas y causas#
| Síntoma | Causa habitual |
|---|---|
| Olvida una restricción temprana | No estaba fijada y se recortó con el historial |
| La calidad baja tras varios pasos | Contexto diluido con salidas viejas |
| Repite un paso ya hecho | El resultado se comprimió sin marcador de finalización |
| El coste sube con la longitud | Los documentos recuperados se acumulan |
| Afirma algo caducado con seguridad | Memoria persistente sin caducidad ni procedencia |
Preguntas frecuentes
¿Cuánto historial guardar literal?
Tres a cinco turnos cubren casi todo el razonamiento sin dominar el contexto. Deja los resultados junto a su llamada y comprime lo anterior en hechos estructurados en vez de borrarlo en silencio.
¿Necesito una base vectorial para la memoria?
Para recuperar documentos, a menudo sí. Para el estado de una sola ejecución, no: eso es un objeto pequeño y estructurado en tu almacén. Mezclarlos da una máquina de estados difusa y un índice sin foco.
¿Cómo evito que la memoria persistente caduque mal?
Da a cada hecho fuente, fecha y caducidad, y haz que el agente prefiera lo recuperado fresco. Muestra el registro a la persona para que los errores se corrijan en vez de repetirse.
memoria de agentes iagestión de contextoresumen de conversaciónmemoria persistenteventana de contexto llm
