Blog

Enseñar a MadoHub a recordar

Dentro del sistema de memoria de MadoHub: seis tipos de memoria, namespacing por persona y proyecto, y por qué nada que un agente aprende se vuelve permanente sin que un humano lo mire primero.

Cada sesión de agente empieza desde cero. Le dices a Claude Code que tu proyecto usa pnpm, no npm, el lunes. Para la sesión del jueves, eso se ha ido — a menos que lo escribas de nuevo, o a menos que algo más lo esté guardando para ti.

Ese "algo más" es lo que hemos estado construyendo en MadoHub durante las últimas fases: un sistema de memoria que se sienta debajo del historial de chat, sobrevive entre sesiones y proyectos, y da a los agentes una forma de leer y escribir lo que han aprendido. Este post va sobre cómo está conformado ese sistema, y sobre la decisión de diseño en él que creemos más importante: la memoria extraída no se convierte en memoria real hasta que un humano dice que sí.

Cómo lo gestiona MadoHub

Seis tipos de memoria

Cada entrada de memoria lleva un tipo, y el conjunto está cerrado a exactamente seis valores:

Tipo	Para qué sirve
`preference`	Una preferencia de usuario confirmada — "le gustan las respuestas concisas"
`fact`	Un hecho duradero y verificable sobre el proyecto
`decision`	Una elección que se tomó, y a menudo por qué — "elegimos Tauri sobre Electron por el tamaño del bundle"
`pattern`	Un comportamiento recurrente que vale la pena codificar una vez
`postmortem`	Qué salió mal, y qué hacer distinto
`event`	Algo que ocurrió, que vale la pena recordar que ocurrió

No hay séptima opción ni campo libre. Eso es deliberado: el panel de Memoria filtra y etiqueta por tipo, y un tipo "fantasma" que se colara sería simplemente una categoría que nada puede buscar o mostrar correctamente.

Namespacing por persona y proyecto

La memoria se particiona por namespace, así lo que un agente recuerda se puede acotar. Un namespace persona: ata la memoria a cualquiera que sea la persona activa; un namespace workspace: la ata a un proyecto concreto. Cuando un agente escribe una memoria sin especificar namespace, cae por defecto a la persona activa. Cuando recuerda, puede estrechar a un namespace — tirando solo de la memoria de un proyecto, por ejemplo, en lugar de la de todas las personas a la vez — así el recall se mantiene relevante en lugar de sacar basura de proyectos no relacionados.

Tres formas en que nace un candidato

Un agente escribiendo una memoria explícitamente es el camino obvio, pero no el único. MadoHub también vigila tus conversaciones en segundo plano:

remember explícito — el agente decidió, a mitad de conversación, que algo valía la pena conservar y lo escribió.
Después de cada turno — una pasada ligera de modelo escanea el último intercambio buscando algo durable, porque la mayor parte de lo que vale la pena recordar aflora en conversación normal en lugar de en momentos deliberados de "recuerda esto". Esto corre en cada turno, así que es más ruidoso por diseño.
Antes de la compactación — justo antes de que una ventana de conversación larga se resuma para ahorrar contexto, el mismo tipo de escaneo corre sobre los mensajes a punto de comprimirse. Este importa porque la compactación es con pérdida: una vez que un rango de mensajes se resume fuera, cualquier cosa no extraída de ellos se va de la memoria a largo plazo para siempre. Un tramo tranquilo de conversación cuesta una llamada barata de modelo y no añade nada en lugar de rellenar la cola con ruido.

Las entradas manuales desde el panel de Memoria completan un cuarto camino, todavía enrutado por la misma tabla de candidatos, solo que introducido por una persona en lugar de extraído por un modelo.

Por qué revisión, no auto-escritura

Aquí está la decisión de diseño en el centro de este sistema: ninguno de esos cuatro caminos escribe en memoria buscable. Cada uno aterriza en una cola de candidatos con un estado que empieza en pendiente y pasa a aprobado o rechazado — o, si nadie lo revisa en absoluto, archivado tras estar 30 días sin tocar. Solo los candidatos aprobados se promueven a la memoria que los agentes buscan realmente.

Pensarías que esto ralentiza las cosas, y lo hace, por diseño. La alternativa — dejar que el juicio de un modelo sobre qué es "lo suficientemente importante para recordar" escriba directo en un almacén que se incorpora a cada conversación futura — significa que una suposición mala no solo te cuesta una respuesta equivocada una vez. Te cuesta una respuesta equivocada cada vez que esa memoria se recuerde de ahora en adelante, compoundándose en silencio hasta que alguien casualmente note al agente citando algo que no es cierto. Ese riesgo es peor justamente para los dos tipos que más querrías confiar: las entradas postmortem y decision tienden a pesarse mucho al ser consumidas después, así que una caducada o equivocada hace más daño que una que falte nunca haría.

La revisión ocurre en Configuración → Memoria, partida entre una cola pendiente — contenido, tipo, namespace, fuente, confianza y cuántas veces se ha visto un candidato equivalente, con la opción de editar antes de aprobar o saltar al turno origen — y una vista de aprobados agrupada por namespace donde las entradas se pueden editar o borrar. También hay una sección Advanced con auto-aprobación opt-in: una vez que un candidato se ha visto suficientes veces con suficiente confianza, se puede promover sin un clic manual. Esa política viene desactivada por defecto. Dejada así, cada cosa que un agente decide que podrías querer que recuerde pasa primero por ti — que es, por ahora, exactamente el punto.

Guía práctica

Revisa la cola pendiente con regularidad. La memoria solo ayuda una vez aprobada, y los candidatos que se quedan sin tocar 30 días se archivan. Una pasada rápida por Configuración → Memoria cada pocas sesiones evita que la cola se atasque.
Edita antes de aprobar. Si un agente capturó la idea correcta con las palabras equivocadas — "usa npm" cuando realmente usas pnpm — arréglalo en la cola en lugar de aprobar y corregir después. La memoria aprobada es lo que los agentes citarán.
Acota con namespaces. Los hechos específicos de proyecto pertenecen al namespace workspace: para que no se filtren a proyectos no relacionados. Las preferencias a nivel de persona pertenecen a persona:.
Ten cuidado con decision y postmortem. Estas pesan mucho cuando los agentes las recuerdan, así que una entrada caducada o equivocada hace más daño que una que falte. Prefiere rechazar un candidato dudoso antes que aprobarlo y esperar que esté bien.
Activa la auto-aprobación solo si lo dices en serio. El ajuste Advanced puede promover candidatos de alta confianza vistos frecuentemente sin un clic, lo cual es conveniente pero elimina la puerta humana. Déjalo desactivado hasta que confíes en la calidad de extracción.