Memoria de agentes de IA: working memory, lo que ha pasado y estado de negocio

Un agente que resuelve tareas en varios pasos necesita saber en qué punto va, qué ha probado antes y, a veces, qué conviene recordar la próxima vez. Eso no es lo mismo que meter todo el historial del chat en cada turno. En un SaaS, además, cada cuenta de cliente tiene su propio límite de qué puede quedar guardado y durante cuánto tiempo.

Este artículo responde qué debe recordar un agente durante una tarea, qué entre sesiones y qué nunca debe mezclarse con el contexto que lee el modelo en cada paso.

Si buscas el mapa de capas (modelo, acciones, permisos, registro), está en el modelo no es el agente. Si buscas el bucle que orquesta tools y contexto, en el harness del agente. Aquí el foco es la memoria: working memory, recuerdos de interacciones anteriores y estado de negocio.

Tres cosas distintas: contexto, estado y memoria

En reuniones suelen usarse como sinónimos. En producción no lo son.

Contexto es lo que el harness coloca delante del modelo en este turno: instrucciones, mensajes recientes, resultados de tools y trozos de documentos. Tiene coste en tokens y se reconstruye en cada paso. No es un almacén fiable; es el maletín de este viaje.

Estado es lo que el sistema sabe de esta tarea ahora: identificadores de pedido o ticket, paso del flujo, último error, si hay una aprobación humana pendiente. Vive en base de datos o en un registro de ejecución, no en el chat. Si solo existe en el hilo, no hay estado: hay texto que el modelo vuelve a leer.

Memoria es lo que puede seguir sirviendo después de cerrar la tarea: preferencias del usuario, resúmenes de incidencias pasadas, hechos que el cliente ya confirmó. Debe estar particionada por cuenta de cliente, con reglas de retención y borrado.

Mezclar las tres produce el síntoma clásico: "el agente se acordaba" porque alguien reinyectó el hilo entero, incluidos datos de otro cliente o instrucciones obsoletas. En identidad y permisos ya vimos por qué eso es un riesgo de fuga, no un truco de producto.

Working memory: lo que necesita ahora

La working memory (memoria de trabajo) es el conjunto acotado de hechos que el agente necesita en esta tarea para decidir el siguiente paso sin volver a preguntar lo obvio.

Ejemplos en un SaaS de soporte:

• El ticket_id y la cuenta de cliente ya validada.

• Que la última tool devolvió not_found para ese pedido.

• Que el usuario eligió "reembolso parcial" hace dos mensajes.

Eso puede aparecer en el contexto del modelo, pero la fuente de verdad no debería ser solo el chat. El harness puede mantener un objeto de working memory que se actualiza cuando una tool responde y del que se extrae un resumen breve para el modelo.

Reglas que funcionan:

• Pocos campos, nombres estables. current_order_id, no párrafos narrativos.

• TTL por tarea. Cuando la tarea termina o expira, la working memory de esa ejecución se archiva o se borra.

• No duplicar lo que ya está en el estado de negocio. Si el pedido está en estado awaiting_approval en la API de negocio, no hace falta que el modelo "recuerde" eso solo en texto.

La working memory no sustituye a las tools con contrato claro: si el agente necesita el estado actual del pedido, una lectura con permisos suele ser más fiable que un recuerdo de hace diez turnos.

Memoria de lo que ha pasado en tareas anteriores

La memoria de lo que ha pasado guarda recuerdos de interacciones anteriores: qué se intentó, qué funcionó, qué falló, a veces con un resumen en lenguaje natural.

Sirve para continuidad entre sesiones:

• "La semana pasada este cliente ya rechazó un reembolso automático; pidió revisión manual."

• "En proyectos similares, la integración con su ERP falló por un campo de moneda."

No es un volcado del chat anterior. Es un registro estructurado o un resumen generado después de la tarea, con metadatos: cuenta de cliente, fecha, tipo de tarea, confianza, enlace a la traza si hace falta auditar.

Riesgos si se hace mal:

• Contaminación entre clientes. Un registro indexado sin tenant_id puede reaparecer en la cuenta equivocada.

• Verdad obsoleta. Un recuerdo que dice "el plan no incluye API" cuando el producto ya cambió empuja al modelo a actuar mal.

• Coste oculto. Buscar en miles de entradas del historial en cada turno sin filtrar por relevancia infla latencia y tokens.

Patrón sano: escribir un resumen al cerrar la tarea (éxito o fallo), buscar solo los N más relevantes para la intención actual y dejar claro en el prompt que son pistas, no permisos. Los permisos siguen en el sistema.

LangChain documenta taxonomías de memoria (buffer, resumen, entidades). En producción SaaS la pregunta no es qué clase de buffer elegir, sino qué merece guardarse en el historial y quién puede leerlo.

Estado de negocio: pedido, ticket, aprobación pendiente

El estado de negocio es el que ya vive en el producto: el ticket en open, el pedido en shipped, la factura en dispute. El agente no lo inventa; lo lee y, a veces, lo actualiza con tools.

Confundir estado de negocio con memoria del modelo es un error frecuente. El modelo puede proponer update_ticket_status; el sistema valida, ejecuta y persiste. Lo que queda en la base de datos es la fuente de verdad. Lo que el modelo "cree" que pasó sin comprobarlo es opinión.

Cuando el flujo tiene pasos humanos (aprobación de reembolso, firma legal), el estado debería reflejar pending_approval en el dominio de negocio, no un mensaje del asistente que dice "esperando al jefe". Así otro canal (email, panel de admin) puede continuar la misma tarea.

Para tareas largas, el harness puede rehidratar el contexto del modelo desde el estado de negocio al reanudar: "tarea X, paso 3, última tool get_order, resultado shipped". Eso es recuperación de ejecución, no memoria mágica del LLM.

Qué va delante del modelo y qué vive fuera

Regla práctica: el modelo ve texto suficiente para decidir el siguiente paso, no un volcado de todo lo que el sistema sabe.

El harness decide cuándo compactar mensajes, cuándo llamar a RAG (recuperar documentos) y cuándo pedir una lectura fresca con una tool en lugar de confiar en un resumen viejo.

No todo problema es de memoria. Si la decisión es cerrada ("¿es read-only?", "¿supera el umbral de riesgo?"), un clasificador tipado como en Jev AI puede devolver una etiqueta sin cargar el historial de interacciones en el prompt. Conviene reservar memoria entre sesiones para lo que de verdad gana contexto histórico.

Borrado, retención y RGPD en SaaS

La memoria en un SaaS multi-tenant es dato personal y dato de cliente a la vez. Conviene tratarla como cualquier otro almacén:

• Partición por cuenta de cliente en registros del historial, índices vectoriales y preferencias.

• Política de retención (por ejemplo 90 días para resúmenes de soporte, menos para pruebas).

• Derecho de supresión: si un cliente pide borrado, hay que poder eliminar esos recuerdos y preferencias sin dejar copias solo en el contexto por defecto del modelo (los proveedores pueden tener sus propias reglas de retención en API; conviene documentar qué se envía al proveedor).

• Minimización: no guardar en memoria lo que ya está en el CRM o en el ticket; guardar el puntero (ticket_id) y dejar que la tool lea el detalle cuando haga falta.

La trazabilidad ayuda a demostrar qué memoria influyó en una decisión. Sin registro, "el agente lo recordaba" no es auditable ante un cliente ni ante un regulador.

Errores típicos (mezclar todo en el prompt)

1. Memoria = historial de chat infinito. Crece el coste, empeora la atención del modelo y mezcla tareas distintas en un solo hilo.

2. RAG como memoria universal. Los documentos recuperados no sustituyen el estado del pedido ni los permisos; son contexto, no autorización.

3. Recuerdos sin caducidad. El agente actúa con políticas de hace un año.

4. Un solo índice vectorial para todos los clientes. Riesgo de recuperar fragmentos de otra cuenta si el filtro por tenant falla una vez.

5. Escribir memoria desde el modelo sin validar. Si el asistente "resume" que el cliente aceptó un cargo y eso se guarda como hecho, se crea deuda legal y de producto.

Mapa de decisión

Cuando el mapa está claro, el siguiente paso suele ser endurecer qué devuelven las tools y qué entradas del historial se indexan, no alargar las instrucciones del sistema.

Si el agente ya está en piloto, una traza real ayuda: separar qué era contexto, qué era estado en base de datos y qué quedó como memoria persistente. Ahí se ve si el diseño aguanta producción o si solo funcionaba porque el hilo era corto.