Memoria y estado para agentes de IA
Crear un agente de IA puede resultar complicado. Mantenerlo en marcha durante un despliegue de seis meses es increíblemente difícil.
Los LLM no tienen estado por diseño. Cada llamada comienza desde cero, sin recordar lo que sucedió antes. Los primeros desarrolladores de agentes solucionaron este problema volcando todo el historial de conversaciones en la ventana contextual y esperando lo mejor.
Ahora sabemos que ese enfoque fracasa rápidamente. La latencia aumenta y la capacidad del modelo para usar realmente lo que está en contexto se degrada: los hechos relevantes quedan enterrados, y cuando hay dos versiones de un hecho en la ventana, no hay garantía de que elija la actual. Los costos de los tokens también aumentan, aunque el almacenamiento en caché rápido ha suavizado ese golpe para los prefijos estables. La solución no es una ventana de contexto más grande; se trata de tratar la memoria y el estado como decisiones arquitectónicas deliberadas, no como ideas tardías.
Antes de entrar en los patrones, vale la pena ser preciso acerca de lo que significan esos dos términos, porque son fáciles de combinar.
El estado es una instantánea. Es todo lo que el agente sabe actualmente sobre una tarea en este momento: en qué paso se encuentra, qué devolvió la última llamada a la herramienta, qué variables está rastreando. Piense en ello como una pizarra. Se actualiza constantemente a medida que avanza la tarea, y cuando finaliza la sesión, desaparece, a menos que persista deliberadamente, de lo que se trata el Patrón 2.
La memoria es el mecanismo que transporta información a través de un límite: el siguiente turno, la siguiente sesión o un agente completamente independiente que se ejecuta más tarde. La memoria de trabajo es el caso de horizonte más corto (giro a turno); Sesiones de memoria semántica y episódica.
Los dos interactúan en un ciclo específico. Al comienzo de una tarea, el agente lee de la memoria para construir su estado inicial: carga hechos relevantes, reglas de comportamiento aplicables y registros de fallas pasadas en tareas similares. Durante la tarea, el agente actualiza el estado continuamente mientras trabaja. A medida que la tarea avanza y concluye, escribe partes seleccionadas de ese estado en la memoria para que el siguiente turno o sesión pueda beneficiarse de lo que acaba de suceder. La memoria alimenta el estado; El estado se retroalimenta a la memoria.
Esta distinción es importante porque los modos de falla son diferentes. Un estado roto significa que el agente pierde la noción de lo que está haciendo a mitad de la tarea. La memoria rota significa que el agente no puede aprender, no puede personalizar y trata cada interacción como una pizarra en blanco. Ambas fallas son comunes en los sistemas de producción y requieren soluciones diferentes.
Los cinco patrones siguientes abordan ambos: los patrones 1 y 2 gestionan el estado; 3 y 4 construyen la capa de memoria que persiste a lo largo de las sesiones; y 5 restringe ambos.
1. La reserva de trabajo en contexto (ejecución a corto plazo)
El concepto
La memoria de trabajo mantiene el estado efímero de la sesión actual: el aviso activo, los giros conversacionales recientes y las salidas de herramientas en vivo. Piense en ello como el espacio disponible a corto plazo del agente, que se vacía cuando finaliza la sesión.
Cómo funciona
En lugar de dejar que la lista de mensajes crezca indefinidamente, el búfer de trabajo actúa como una ventana deslizante. El agente escribe los pasos de razonamiento inmediatos en un bloc de notas. A medida que el búfer se acerca a un límite de tokens, un proceso de resumen comprime los giros más antiguos en un resumen de fondo denso, manteniendo las conclusiones lógicas y descartando los resultados sin procesar de la herramienta. Cuando finaliza la tarea, el búfer se vacía: todo lo que vale la pena conservar se extrae a almacenes a largo plazo y el resto se descarta.
Vale la pena señalar: ese resumen en mitad de una conversación puede reescribir el prefijo del mensaje, lo que invalida el caché KV y crea un pico de latencia en la siguiente llamada. Es una verdadera compensación para diseñar.
Cuando usarlo
Todo agente necesita esto. Es la base para manejar el razonamiento de varios pasos dentro de una sesión.
2. Puntos de control de ejecución (tolerancia a fallos y pausa)
Una vez que tenga una estrategia para gestionar lo que el agente guarda en la memoria durante una sesión, la siguiente pregunta es qué sucede cuando se interrumpe esa sesión.
El concepto
Las tareas de larga duración fallan. Un agente puede agotar el tiempo de espera, alcanzar un límite de velocidad o hacer una pausa esperando que un humano apruebe una acción. Los puntos de control guardan el estado del flujo de trabajo del agente en una base de datos para que la ejecución pueda reanudarse exactamente donde se detuvo, sin volver a ejecutar el trabajo que ya se completó.
Cómo funciona
Los marcos basados en gráficos modelan los flujos de trabajo como nodos y bordes. Después de cada paso, el marco conserva el estado del flujo de trabajo, incluidas las variables, el historial y la posición actual, en un almacén duradero como PostgreSQL o SQLite. Si el agente falla, recarga el último punto de control y retoma desde allí.
Una cosa que a los practicantes les molesta regularmente: la reanudación no proporciona una semántica de exactamente una vez. Si un nodo se ejecutó parcialmente antes de fallar (digamos que envió un correo electrónico o escribió una fila de la base de datos), puede ejecutarse nuevamente al reanudarse. Los nodos de efectos secundarios deben ser idempotentes. También tenga en cuenta que los identificadores de archivos abiertos y los objetos del cliente no se pueden controlar, lo que limita lo que puede poner en estado de forma segura.
Cuando usarlo
Esencial para sistemas con presencia humana, flujos de trabajo regulados donde las acciones necesitan aprobación y cualquier tarea a largo plazo susceptible a fallas de red.
3. Memoria semántica (conocimiento entre sesiones)
Los puntos de control manejan la continuidad dentro de una tarea. Pero ¿qué pasa con el conocimiento que necesita sobrevivir en sesiones completamente separadas?
El concepto
La memoria semántica es lo que sabe el agente: hechos, preferencias del usuario y conocimiento del dominio que persisten en sesiones independientes.
Cómo funciona
Los hechos se extraen de forma asincrónica y se almacenan en una base de datos externa, generalmente un almacén de vectores con filtrado de metadatos, a veces combinado con un gráfico de conocimiento donde el recorrido de las relaciones realmente importa. Cuando llega una consulta, el sistema recupera los hechos más relevantes y los inserta en el mensaje antes de que el modelo los vea. Tenga en cuenta que la extracción puede costar una llamada de LLM adicional o más, según la arquitectura, y, a menudo, una por turno.
Un conflicto alrededor del cual diseñar: si un usuario menciona “uso Postgres” en marzo y “migramos a Snowflake” en julio, ambos hechos terminan en la tienda. La recuperación podría sacar a la luz cualquiera de los dos. La invalidación de hechos, a través de la ponderación de lo reciente, la lógica de sustitución o TTL, es lo que realmente resuelve el problema de hechos obsoletos planteado en la cima.
También vale la pena mencionarlo explícitamente: las credenciales y los secretos no son memoria semántica. No almacene claves API en un almacén recuperable. Una inyección rápida o una recuperación demasiado ansiosa podrían emitirlos en una respuesta modelo. Los secretos pertenecen a un administrador de secretos, donde el agente obtiene un identificador de credenciales cuyo valor nunca ve.
El riesgo inverso también importa: el contenido que no es de confianza (una página raspada, un mensaje de usuario, el resultado de una herramienta) extraído a la memoria semántica como un “hecho” puede llevar persistentemente al agente en la dirección equivocada. Debido a que no existe un equivalente rápido de parametrización, ni una separación estricta entre instrucciones y contenido, el etiquetado de procedencia hace el trabajo: rastrear de dónde vino un hecho y determinar su influencia en consecuencia.
Cuando usarlo
Asistentes personales, copilotos de codificación o agentes empresariales que necesitan recordar el estilo de código preferido de un usuario, las pautas arquitectónicas o las convenciones de esquema de base de datos en todas las sesiones.
4. Registros de eventos episódicos (reflexión histórica)
La memoria semántica almacena lo que sabe el agente; La memoria episódica almacena lo que hizo el agente.
El concepto
La memoria episódica actúa como un libro de contabilidad cronológico de la trayectoria de ejecución del agente: objetivo, plan, llamadas de herramientas, resultado.
Cómo funciona
Cuando finaliza un flujo de trabajo, un proceso en segundo plano registra esta trayectoria completa. Antes de que el agente emprenda una tarea similar, consulta este registro. Si anteriormente falló una consulta de base de datos debido a un error de sintaxis, la memoria episódica muestra ese contexto para que el agente no repita el error.
Una advertencia: los seguimientos de fallas recuperados son de asesoramiento, no de restricciones. El modelo puede ignorarlos. También existe un riesgo de envenenamiento: si una falla ambiental puntual se registra como una falla estratégica, le estás enseñando persistentemente al agente la lección equivocada. Inicie sesión con eso en mente.
Cuando usarlo
Agentes de codificación autónomos, canales de ingeniería de datos y sistemas de planificación que necesitan aprender de los errores del pasado sin intervención humana.
5. Segregación de múltiples ámbitos (privacidad empresarial)
Una vez que la memoria persiste, la pregunta es quién puede verla. En el momento en que su sistema atiende a más de un usuario, la memoria debe quedar aislada.
El concepto
La memoria no es un único depósito compartido. Un hecho aprendido mientras ayudaba al Usuario A nunca debe revelarse al Usuario B.
Cómo funciona
Cada escritura en memoria se etiqueta con alcances de identidad: user_id, session_id, org_id. La recuperación filtra estrictamente según el token de autenticación del usuario activo. Cuando sea posible, aplique esto en la capa de almacenamiento, a través de espacios de nombres por inquilino o seguridad a nivel de fila, en lugar de depender únicamente de los filtros de consulta de la capa de aplicación. Una cláusula WHERE olvidada no se abre; El aislamiento de la capa de almacenamiento falla al cerrarse.
Este es un requisito previo para el cumplimiento de la privacidad de los datos, no la línea de meta. El problema más difícil es la eliminación: cuando un usuario ejerce su derecho de eliminación, debe eliminar no sólo sus datos sin procesar sino también las incrustaciones, los resúmenes y los hechos extraídos derivados de ellos.
Cuando usarlo
Cualquier producto SaaS, sistema multiinquilino o implementación empresarial donde se deban imponer límites de datos.
Resumen
Una cosa que ninguno de estos patrones cubre por sí solo son los límites de crecimiento. Durante un despliegue de seis meses (el marco con el que comenzó este artículo), los almacenes semánticos y episódicos acumularán entradas casi duplicadas, obsoletas y ruido. La calidad de la recuperación se degrada a medida que las tiendas se llenan y los costos aumentan con ellas. Los TTL, los trabajos de consolidación y las políticas de poda no son un pulido opcional; son parte de la memoria operativa a escala.
La ventana de contexto no es una base de datos. Cuando se desacopla la memoria en distintos componentes, buffers de corto plazo para la ejecución, registros episódicos para la experiencia y almacenes semánticos para los hechos, se obtienen sistemas que realmente aprenden, se mantienen dentro de los límites de los datos y se mantienen en producción.