Diagrama ilustrativo · los agentes escriben en el cerebro (rosa); este procesa y devuelve informes (cian) al inicio de cada sesión.
🧠 El problema: agentes que olvidan
Usas varios agentes: uno para desarrollo, uno autónomo para tareas y automatizaciones para flujos. Cada uno mantiene su propio contexto y olvida todo entre sesiones. Cuando uno descubre algo importante, los demás nunca se enteran. Ese es el problema que justifica un cerebro compartido.
⚠️ Por qué key-value no basta
Las soluciones existentes son para una sola máquina, requieren un servicio pago en la nube o tratan la memoria como un conjunto plano de pares clave-valor, sin entender que un hecho y un evento son cosas fundamentalmente diferentes, con ciclos de vida distintos. La memoria de verdad necesita tipos.
✓ Con cerebro compartido
- ✓Lo que aprende un agente queda disponible para todos.
- ✓Funciona entre máquinas, herramientas y frameworks.
- ✓La sesión comienza sabiendo qué cambió desde la última vez.
✗ Sin él
- ✗Cada agente vive en su propia burbuja de contexto.
- ✗Amnesia total en cada nueva sesión.
- ✗Los descubrimientos valiosos no se propagan.
Contexto separado.
Lo olvida entre sesiones.
Descubrimientos aislados.
Cerebro compartido.
🧩 Los 4 tipos de memoria
Aquí está la idea central: un hecho y un evento son cosas diferentes. El sistema entiende cuatro tipos, cada uno con su ciclo de vida y regla de mutación. Esta taxonomía es lo que distingue un verdadero sistema de memoria de un depósito de strings.
| Tipo | Comportamiento | Ejemplo |
|---|---|---|
| event | Append-only, inmutable. No actualizas el historial, lo registras. | "El workflow falló a las 3 h" |
| fact | Upsert por key. El hecho nuevo reemplaza al anterior. | "API status: healthy" |
| estado | Actualización en el lugar por subject. Gana el último. | "migración: 70%" |
| decision | Append-only con razonamiento. El porqué importa. | "Postgres en vez de MySQL porque..." |
📊 No es taxonomía por deporte
El tipado le indica al sistema cómo debe comportarse cada memoria cuando cambia: un hecho se supersede, un estado se sobrescribe, un evento es permanente, una decisión es un registro de razonamiento. Datos diferentes, reglas diferentes. Sin esto, todo se convierte en el mismo blob y pierdes la capacidad de versionar y confiar en lo que está activo.
Inmutable.
Upsert por key.
El último gana.
Guarda el porqué.
🔄 El ciclo de vida de la memoria
Cada memoria pasa por una cadena de procesamiento. Eso es lo que mantiene el cerebro útil en vez de convertirse en un depósito que solo crece. Cuatro mecanismos trabajan juntos: deduplicación, cadena de supersedes, decaimiento de confianza y consolidación por LLM.
Deduplicación
El contenido se convierte en hash SHA-256 al guardarse. Se detectan los duplicados exactos; la consolidación también detecta casi duplicados con un 92% de similitud semántica.
Cadena de supersedes
Guardó un hecho con la misma key? El antiguo se marca como inactivo y el nuevo apunta de vuelta. Historial de versiones gratis, sin trabajo manual.
Decaimiento de la confianza
Los hechos y el estado pierden ~2%/día si nadie los consulta. La búsqueda clasifica por similaridade × confiança. El conocimiento antiguo se hunde por sí solo; acceder a él reinicia el reloj. Los eventos y las decisiones no decaen: son historia.
Consolidación por LLM (cada 6h)
Un proceso en segundo plano analiza las nuevas memorias: combina duplicados, señala contradicciones, descubre conexiones y extrae insights cruzados. Es un bibliotecario que organiza el conocimiento en lugar de dejar que se acumule.
💡 El cerebro mejora mientras duermes
La consolidación periódica es lo que marca la diferencia. Mientras los sistemas comunes solo acumulan, este reorganiza: la primera pasada tras una actualización llegó a limpiar cientos de memorias basura automáticamente. Decay + consolidación = una memoria que envejece como la humana y olvida lo irrelevante.
🛡️ Seguridad y aislamiento
Memoria compartida entre agentes en ejecución sin supervisión solo es viable con un guardián bien diseñado. La API es el gatekeeper: ningún agente accede directamente a la base de datos. Pueden guardar y buscar, y nada más.
✓ Qué PUEDE hacer un agente
- ✓Guardar y buscar recuerdos mediante endpoints validados.
- ✓Leer briefs, estadísticas y entidades.
✗ Lo que NO se puede
- ✗Borrar memorias o eliminar tablas.
- ✗Eludir la limpieza de credenciales.
- ✗Acceder directamente a la base de datos o alterar la memoria de otra persona.
🔐 Eliminación de credenciales
Todo el contenido se limpia antes de almacenarse: las API keys, los JWT, las claves SSH, las contraseñas y los secretos en base64 se redactan automáticamente. Los agentes comparten contexto libremente sin filtrar credenciales a la memoria a largo plazo.
⚠️ El peor caso es un buen dato, no una destrucción
Es por diseño: si un agente autónomo alucina o se sale del guion, lo peor que hace es guardar datos incorrectos — no puede destruir datos buenos. Se suma a la autenticación con timing seguro y rate limiting (10 fallos/min = bloqueo). Lo básico bien hecho.
La API valida todo.
Sin credenciales.
No toca la base de datos.
Seguro en cuanto al timing + límite.
📊 Informes de sesión
Es aquí donde ocurre realmente la coordinación entre agentes: de forma pasiva. Toda sesión empieza con una pregunta: "¿qué pasó desde la última vez que estuve aquí?". El endpoint de briefing devuelve las novedades de todos los demás agentes, excluyendo las tuyas.
Recreación ilustrativa de una llamada de briefing (no es una captura de pantalla real):
En la práctica: el agente de desarrollo abre una sesión el viernes por la mañana y ya sabe que un workflow falló el jueves por la noche y que otro agente descubrió algo sobre el ranking de un cliente, sin revisar los logs ni acordarse de hacerlo. El sistema lo saca a la luz.
✓ Buenas prácticas de briefing
- ✓Llamar en inicio de cada sesión.
- ✓Excluir tus propias entradas (ya son conocidas).
- ✓Ordenar por importancia y luego por recencia.
✗ Antipatrones
- ✗Confiar en la memoria humana para "ir a revisar los logs".
- ✗Traer todo sin filtrar por importancia: se vuelve ruido.
- ✗Incluir las entradas propias y contaminar el briefing.
💡 Consejo práctico
Trata el briefing como el «buenos días» obligatorio del agente. Coloca la llamada al principio de tu flujo de apertura de sesión; así, la coordinación entre agentes se convierte en un hábito del sistema, no en algo que dependa de que te acuerdes. Es el complemento natural de /sessionend: uno abre, el otro cierra.
Marca de tiempo.
Se excluye a sí mismo.
Por tipo.
Coordinación sin esfuerzo.
🔥 El ritual /sessionend
O /sessionend es una skill que cierra el ciclo de inteligencia compuesta. Al final de cada sesión, transforma lo ocurrido en memoria institucional. El punto no es solo resumir: es evaluar con honestidad y guardar de forma estructurada.
Gather — reunir los artefactos
Ejecuta git log, diff, status y revisa el historial de la conversación: qué se pidió, qué herramientas se usaron, qué funcionó y qué necesitó un retry.
Reflect — reflexionar con honestidad
Qué salió bien, qué salió mal y cómo podría haber sido mejor. "Todo salió bien" no es una reflexión válida — si algo fue subóptimo, dilo. Es la regla que más valor aporta.
Store — guardar en la memoria
Guarda un resumen estructurado (qué se hizo · qué salió bien · qué salió mal · cómo mejorar · relevante para otros agentes) bajo un tema fechado.
Update — actualizar la memoria local
Solo guarda lo que es realmente nuevo: preferencias, datos del proyecto, información sobre el usuario. Actualiza el índice. No vuelvas a guardar lo que ya se capturó.
♾️ Por qué esto se compone
El cierre de sesión alimenta la consolidación, que alimenta el briefing de la próxima sesión. Cada sesión hace que todas las futuras sean más inteligentes — no solo para ese agente, sino para todos. Es el mismo ciclo de automejora de 6.1 (Workflow Spotter) y 6.2 (Taproot), ahora en el nivel de la memoria del sistema.
"O que aconteceu desde a última vez que estive aqui? Traga o briefing de todos os outros agentes desde ontem, ordenado por importância. Exclua minhas próprias entradas."
/sessionend # (ou, sem a skill instalada:) "Encerre a sessão: reúna git log/diff, reflita com honestidade (o que foi bem, o que foi mal — 'tudo certo' NÃO vale), guarde um resumo estruturado e atualize a memória local só com o novo."
📤 Ejemplo de salida
Recreación ilustrativa del resumen final que /sessionend imprime para el usuario (no es una captura de pantalla real):
🏋️ Ejercicios prácticos
Clasifica 5 memorias
Toma 5 datos de tu trabajo reciente y clasifica cada uno como event, fact, status o decision. Justifica por qué importa el tipo en cada caso.
Diseña tu briefing
Enumera tus agentes/herramientas y escribe la pregunta del brief que haría cada uno al empezar. Define el criterio de orden (importancia × recencia).
Crea un SKILL.md de /sessionend ejecutable
Escribe una skill de cierre adaptable a cualquier backend de memoria. Esqueleto:
Guarda en ~/.claude/skills/sessionend/SKILL.md y pruébalo escribiendo "/sessionend" al terminar un trabajo. Funciona con cualquier backend de memoria (o solo localmente).
📌 Resumen del módulo
Llegaste al final
Esta es la última lección del curso. Desde la anatomía del SKILL.md (T1) hasta la memoria multiagente, recorriste todo el camino de Claude Skills na Prática.