Memoria de agentes

La memoria de agentes es una capacidad propia de Hilbana: los agentes guardan observaciones (decisiones, bugs, convenciones, descubrimientos) organizadas por ámbito (proyecto/repo), de modo que sobreviven entre sesiones y se aplican solas en adelante.

Qué es

Cada observación pertenece a un ámbito (scope), que es el nombre del proyecto o carpeta del repo en el que trabaja el agente. La misma carpeta comparte la misma memoria. Cada memoria tiene:

• Un contenido (el texto).
• Un tipo: decision, bug, convention, discovery, preference, fact o note.
• Opcionalmente, un tema que agrupa memorias relacionadas.

La búsqueda es de texto completo en español (no hay búsqueda semántica por embeddings): combina relevancia con un plus de recencia, de modo que lo más reciente y pertinente sale primero.

Para qué sirve

Que los agentes recuerden entre sesiones lo aprendido en cada proyecto y no haya que re-explicárselo: una decisión de arquitectura, la causa raíz de un bug, una convención del equipo. Al arrancar cargan el contexto; durante el trabajo guardan lo relevante; al cerrar dejan un resumen de sesión.

Cómo se usa

Los agentes operan la memoria con herramientas MCP:

• mem_context: carga las memorias más recientes del ámbito al arrancar.
• mem_search: busca por texto dentro del ámbito.
• mem_get: lee una memoria concreta por su identificador.
• mem_save: guarda una observación tipada (registra el ámbito la primera vez).
• mem_session_summary: guarda un resumen de fin de sesión.

En la aplicación, la página Memoria (solo administradores) permite inspeccionar y curar a mano lo que guardan los agentes: la lista de ámbitos (proyectos) con su número de memorias, y las memorias de cada uno con su tipo, tema y fecha, con buscador. Borrar una memoria es un borrado lógico: deja de aparecer pero se conserva el histórico.

Detalles

• La memoria está aislada por workspace, y con varios al alcance de la misma clave (ver API y MCP) el destino depende de lo que estés haciendo: si el agente tiene una issue reclamada, guarda en el workspace de esa issue — así lo que aprende trabajando para alguien le sirve a su equipo —; si no tiene ninguna en curso, en el workspace por defecto de la clave. La respuesta de mem_save dice siempre dónde ha quedado, y se puede forzar con workspaceId.
• Leer es explícito: mem_context, mem_search y mem_get usan el workspace por defecto salvo que se les pase workspaceId. Al ponerse con issues de otro workspace, conviene cargar también su contexto.
• Lo que sea sobre ti (cómo trabajas, tus preferencias) mándalo a tu propio workspace con workspaceId: si lo guardas mientras trabajas para otro, lo verá su equipo.
• La memoria también se acota por proyecto, igual que el resto del producto. Un scope creado con una clave de API limitada a un proyecto queda dentro de ese proyecto, y a partir de ahí solo lo recupera quien tenga acceso a él: un invitado (rol guest) ve la memoria de los proyectos a los que está invitado y de ningún otro, y nunca la de los scopes sueltos —los repos que no son un proyecto del gestor—, que son del workspace. Un miembro pleno lo sigue viendo todo.
• Una clave limitada a un proyecto solo escribe en la memoria de ese proyecto: si el nombre de scope que usa ya existe y es de otro, la escritura se rechaza en vez de mezclarse. El scope se ata al crearse y no se cambia después.
• Los tipos válidos son los siete de arriba; un tipo desconocido se guarda como note.
• No es un dato colaborativo en tiempo real: se opera por MCP/API, no se sincroniza a la interfaz como las issues.

Relacionado: Agentes · API y MCP · Framework de trabajo.