Crear una memoria de agentes que sobreviva a la conversación sin acumular datos en exceso.

Una escena que se repite con casi todos los agentes que pasan a la fase de producción es la siguiente.

El lunes, un usuario dice que gestiona la región del Noroeste, que solo le interesan los proyectos activos y que no soporta respuestas largas. El agente responde “Entendido”, y durante el resto de esa sesión eso significa exactamente eso: las respuestas son breves, se limitan al Noroeste y no hay borradores. El usuario queda satisfecho.

El martes, la misma persona inicia un chat nuevo y pregunta cómo van sus proyectos. El agente pregunta amablemente de qué región quiere saber más.

La expresión en el rostro de ese usuario es la razón para reflexionar seriamente sobre la memoria.

Por qué guardar todo falla

Casi todos los desarrolladores recurren a la misma solución: guardar toda la conversación y volver a cargarla al día siguiente. Parece obvio, pero es una trampa. La forma en que falla enseña más sobre el diseño de agentes que la mayoría de los tutoriales.

Supongamos que toda la historia se guarda y se reproduce cada vez que el usuario vuelve. Las cosas ocurren en un orden predecible.

Semana uno: funciona. El agente realmente recuerda todo, y uno se siente listo. Esta es la etapa peligrosa, ya que parece confirmar el diseño inicial.

Semana tres: se vuelve lento y costoso. Cada turno ahora incluye miles de tokens del chat anterior. Uno está pagando por las conversaciones triviales del lunes mientras responde a una pregunta del viernes. La ventana de contexto es el escritorio del agente, y uno ya la ha llenado con los documentos de la semana pasada antes incluso de comenzar el trabajo de hoy.

En la sexta semana, las cosas se tuercen. Nadie te advierte sobre esta etapa. Las conversaciones antiguas contienen afirmaciones que ya no son ciertas. El usuario se centraba en el Noroeste hasta que un ascenso lo puso al mando de todo el país. El proyecto se retrasó hasta que finalmente se lanzó. Reproducir todo hace que el agente valore por igual los datos obsoletos y los actuales. El problema ya no es que recuerde demasiado poco, sino que recuerda demasiado, sin tener idea de qué ya no es válido.

Reproducir historiales completos es, en efecto, una máquina para generar contexto obsoleto. Por lo tanto, “¿cómo guardo todo?” nunca fue la pregunta correcta. Las preguntas adecuadas son:

¿Qué cosas merecen conservarse, cuáles deben recuperarse cuando se necesiten y cuáles deben descartarse para generarlas de nuevo desde cero?

Si se responden estas preguntas, la arquitectura de memoria se determinará automáticamente.

Un diseño en tres niveles

Compárelo con la forma en que maneja la información en el trabajo. Hay cosas que se queda en la cabeza durante una reunión y que felizmente olvida después. Otras las escribe en un cuaderno porque las necesitará el mes siguiente. Y hay algunas que nunca memoriza, ya que cambian y las verifica cada vez. Los agentes necesitan los mismos tres niveles.

Nivel 1: memoria de sesión, destinada a desaparecer

Este nivel almacena todo lo relacionado con la conversación actual: el historial de mensajes, los resultados intermedios de las herramientas, una tarea multifase a medio completar y el estado de LangGraph al pasar de un nodo a otro.

Cuando termina la sesión, este nivel puede desaparecer. Eso no significa que se haya guardado algo olvidadamente; está diseñado para desvanecerse, y eso es una ventaja.

Los principiantes se sienten culpables por ello, pero no es necesario. El desarrollo detallado de una conversación se asemeja a una reunión: lo que realmente importa no es la transcripción, sino las conclusiones. Por lo tanto, la pregunta interesante es qué pasa a ser de nivel 2 cuando finaliza una sesión.

No la transcripción. Un paso de extracción pequeño y explícito identifica tres categorías:

1. Hechos estables sobre el usuario, como “gestiona la región del Noroeste”, válidos hasta que se revocen.
2. Preferencias, como “quiere respuestas cortas” y “excluir proyectos en borrador”.
3. Decisiones, como “acordar un formato de resumen semanal”.

Esa conversación del lunes podría llegar a los cuatro mil tokens. Lo que merece sobrevivirle son aproximadamente cuarenta tokens de hechos estructurados, lo que representa una compresión de unas cien veces. A diferencia de un resumen, nada importante se vuelve vago, porque se extrajeron categorías nombradas en lugar de una impresión general. Los resúmenes eliminan silenciosamente las restricciones, mientras que la extracción es la solución: una preferencia o bien aparece en la lista palabra por palabra o no, y se puede crear una prueba para ello.

Nivel 2: memoria a largo plazo, pequeña, estructurada y editable

Este es el almacén compacto que persiste entre sesiones, el cuaderno del usuario. Resista la tentación de ser ingenioso. Un formato aburrido es precisamente la razón por la que funciona:

{
  "user_id": "u-2481",
  "facts": [
    {"fact": "manages Northwest region", "updated": "2026-08-03"},
    {"fact": "prefers concise answers", "updated": "2026-07-19"}
  ],
  "preferences": [
    {"pref": "exclude draft projects from reports", "updated": "2026-08-03"}
  ],
  "decisions": [
    {"decision": "weekly summary every Monday", "updated": "2026-07-28"}
  ]
}

Unas pocas docenas de líneas de JSON por usuario, cargadas en el contexto al inicio de cada sesión. Es lo suficientemente económico como para incluirlas siempre y lo suficientemente pequeño como para no causar sobrecarga.

Tres reglas mantienen su eficacia.

Lo estructurado es mejor que el texto prosaico. Una descripción vaga como “esta persona probablemente se encarga del Noroeste y prefiere la brevedad” resulta inútil posteriormente. En cambio, los hechos separados pueden mostrarse al usuario, corregirse y eliminarse individualmente.

Añade marcas de tiempo a todo y reemplaza en lugar de agregar. Cuando el usuario pasa del área Noroeste a la nacional, no se agrega un segundo hecho junto al primero; se sobrescribe. Una vez que la base de datos contiene tanto “se encarga del Noroeste” como “se encarga de la nacional”, se vuelve a crear el problema del estado obsoleto, lo cual es peor, porque ahora permanecerá obsoleto para siempre.

Deje que el usuario lo vea y lo corrija. Incluso una instrucción básica como “esto es lo que recuerdo sobre usted” cambia las cosas. La memoria que el usuario no puede inspeccionar con el tiempo se convierte en una memoria en la que ya no confía, generalmente en el momento en que el agente afirma, con total seguridad, algo que ya está desactualizado desde hace meses.

Lo que queda fuera del Nivel 2 es cualquier cosa que se pueda consultar. Eso pertenece al Nivel 3, y los equipos suelen invertir sus esfuerzos allí en cosas equivocadas.

Nivel 3: regenerar a demanda, sin recordarlo deliberadamente

Aquí reside todo lo que cambia por sí solo: estados de proyectos, cifras, fechas, organigramas, números en tiempo real, el contenido de bases de datos y APIs.

La regla es que este nivel nunca debe memorizarse. No lo resuma, no lo guarde en un almacenamiento de memoria ni lo transfiera de una conversación anterior. En el momento en que sea necesario, el agente llama a una herramienta para obtener el valor actual.

Escribido así, suena obvio. También es la regla más incumplida en la memoria del agente, porque almacenar datos en tiempo real como si fueran memoria parece una optimización. En realidad es una bomba de tiempo con un mecha lento:

• Se guarda “El Proyecto Falcon está retrasado” y luego el proyecto se entrega. Durante semanas, el agente sigue hablando de un proyecto que ya fue completado.
• Se guarda “El equipo tiene 8 miembros” y luego se unen dos personas. Toda respuesta relacionada con la capacidad está errónea.

El resumen más preciso de toda esta arquitectura es probablemente este:

Use la memoria para los datos sobre la persona. Use herramientas para los datos de todo lo demás.

Las preferencias de los usuarios cambian rara vez, y ellos te lo comunican cuando ocurre. El mundo cambia constantemente pero no te dice nada. Así que recuerda al usuario y consulta al mundo.

Caso de fallo: “compartir todo” se encuentra con múltiples agentes

Esa es la versión simplificada. El camino hacia ella pasó por un incidente, en un proceso ficticio con dos agentes en una empresa de servicios de red.

El agente A habló con los usuarios y recopiló sus requisitos de informes. El agente B elaboró los informes. Cuando A le pasó el trabajo a B, el equipo repitió el error inicial a escala arquitectónica: le entregaron todo el contexto de A, incluida toda la conversación, todos los resultados de las herramientas y todo el estado. La lógica parecía irrefutable. ¿Acaso más contexto no significa un B mejor informado?

La forma en que se produjo la interrupción es la parte relevante. Durante una sesión, un usuario expresó en voz alta ante el Agente A: ¿y si se incluían los proyectos archivados? Pero al reflexionar, decidió que eso distorsionaría los totales, así que los dejó fuera. Era un razonamiento completamente normal hecho en voz alta, y el Agente A lo manejó correctamente.

Luego se realizó la transferencia y el Agente B recibió toda la transcripción, incluida la parte irrelevante. Sin embargo, B no contaba con el contexto de la conversación del Agente A para evaluarla. En el contenido enviado no se indicaba que la idea de incluir los proyectos archivados hubiera sido rechazada, y fuera de contexto parecía ser una instrucción. El Agente B incluyó fielmente los proyectos archivados, y los totales en el informe oficial estaban incorrectos por una razón que nadie pudo descubrir al revisar su código, ya que su código estaba en orden.

Esa es la versión multiagente de todo lo anterior: una transferencia representa un límite entre sesiones. Cuando el Agente B inicia su tarea, se trata de la nueva conversación del martes. El equipo cometió el mismo error de “guardar todo” de forma lateral, entre agentes, en lugar de hacerlo a lo largo de los días.

La solución fue la misma. La transmisión de transcripciones dio paso a un paquete de transferencia estructurado, en esencia un elemento temporal de nivel 2 que el Agente A crea para el Agente B:

{
  "task": "generate weekly regional report",
  "requirements": [
    "region: Northwest",
    "active projects only",
    "exclude drafts AND archived"
  ],
  "format": "summary table first, details after",
  "constraints_confirmed_by_user": true
}

Eso son unos cincuenta tokens sin ambigüedades. B recibe conclusiones, no el camino sinuoso para llegar a ellas. La categoría de errores “archived-projects” se volvió imposible de manejar, y no solo de detectar o resolver, porque las ideas abandonadas no pueden sobrevivir físicamente al ser extraídas a una lista de requisitos.

Tome una oración en cualquier diseño multiagente: los agentes deben intercambiar conclusiones entre sí, nunca transcripciones.

Una lista de verificación para aplicar esta semana

Cinco decisiones que puede tomar respecto a un agente existente:

1. Deje que la memoria de la sesión desaparezca. Agregue un paso de extracción al final de la sesión, o después de N turnos, que solo transfiera hechos, preferencias y decisiones, permitiendo que el resto se pierda junto con la conversación.
2. Mantenga el nivel 2 como JSON simple. Elementos discretos, marcas de tiempo, actualizaciones que reemplacen información. Nunca un texto prosaico en expansión y nunca de solo escritura.

Ofrézca a los usuarios una forma de acceder a la información. Un enfoque del tipo “¿qué recuerda de mí?”, aunque sea rudimentario, fomenta la confianza y permite identificar de forma gratuita datos obsoletos.

Efectúe auditorías de nivel 2 para los datos sobre el mundo. Todo aquello que una herramienta pueda obtener de forma actualizada, como estados, cantidades, fechas y números, debe ser reemplazado. La memoria sirve para el usuario, mientras que las herramientas se encargan de los datos del mundo.

Transmita conclusiones de manera estructurada al pasar tareas. Utilice un paquete de datos estructurado que incluya la tarea, los requisitos y las restricciones. Si su transmisión contiene una transcripción sin procesar, ya ha transmitido el problema mencionado anteriormente sin darse cuenta.

Conclusión

Creer que la memoria implica almacenar más es exactamente lo contrario a lo correcto. Cada uno de los problemas mencionados anteriormente, desde soluciones tentadoras para la amnesia del martes hasta datos obsoletos o informes de proyectos archivados, se deben a acumular demasiada información de forma descuidada.

Una buena memoria en los agentes se basa principalmente en la práctica de olvidar. El estado de la sesión puede desaparecer, las notas a largo plazo deben ser lo suficientemente breves como para leerse de un vistazo, y nada de lo que el mundo pueda decirte de nuevo se memoriza. Los agentes que parecen genuinamente personales no son aquellos que recuerdan todo; recuerdan los cuarenta tokens adecuados.