Docs / Base de conocimiento y memoria

Base de conocimiento y memoria

Por qué importa la memoria

Sin memoria persistente, cada especialista empieza de cero. El Developer no puede leer el registro de decisión del Arquitecto. El especialista de QA no sabe qué construyó el Developer. Tendrías que copiar el contexto manualmente entre cada paso — lo que cancela el propósito de tener un equipo.

ASDT resuelve esto con una base de conocimiento. Cada artefacto que produce un especialista se guarda con una clave estable. El siguiente especialista lo recupera automáticamente por clave. El contexto fluye hacia adelante sin intervención manual, incluso entre sesiones separadas por días.

Cómo fluye el conocimiento

Cada paso de cada especialista produce un artefacto. Ese artefacto se guarda en la base de conocimiento con dos identificadores:

• Un título legible por humanos — ej. "add-auth/developer/dev-implementation"
• Una clave estable para recuperación automática — usada por los especialistas siguientes para obtener exactamente el artefacto que necesitan

Cuando corre el siguiente especialista, consulta la base de conocimiento por clave. Si el artefacto existe, procede normalmente. Si falta, anota la brecha en open_items y continúa con lo que tiene disponible — sin errores duros, sin pipelines bloqueados.

Esto significa que el orden de ejecución es flexible. Podés empezar con cualquier especialista. Podés pausar entre pasos — incluso cambiar de asistente — y la base de conocimiento retiene el estado. Un artefacto guardado desde Claude Code puede ser leído por un paso posterior corrido en OpenCode, y viceversa, porque ambos leen y escriben en el mismo almacén de Engram.

Memory providers

ASDT requiere un memory provider — un almacén persistente que sobrevive a los cierres de sesión y hace los artefactos disponibles entre distintas invocaciones de especialistas.

Un memory provider le da a ASDT:

• Persistencia entre sesiones — el output del Arquitecto del lunes está disponible para el Developer del jueves
• Scope por proyecto — los artefactos de proyectos distintos no se mezclan
• Recuperación por clave — búsqueda determinística sin matching difuso

Hoy, Engram es el memory provider soportado. Más providers están planificados.

Engram — implementación actual

Engram es un servidor MCP (Model Context Protocol) que provee memoria persistente y con scope de proyecto para asistentes de IA.

Engram tiene que estar corriendo antes de invocar cualquier especialista (o cualquier memory provider que tengas configurado). Los artefactos guardados en Engram sobreviven al cierre de una sesión del asistente — esa es la propiedad de la que ASDT depende para la continuidad del pipeline entre sesiones, ya sea que uses Claude Code u OpenCode.

Instalación

Seguí la guía de setup de Engram para instalar e iniciar el servidor MCP. Luego conectalo a la configuración MCP de tu asistente — Claude Code y OpenCode exponen cada uno su propio setup de MCP, así que seguí el del asistente que uses. Ambos se conectan al mismo servidor de Engram; solo cambia la ubicación de la configuración.

Verificar que está corriendo

/asdt-init

El especialista de init verifica la conectividad con el memory provider como parte del setup e informa si el servidor MCP es inalcanzable.

Cómo se almacenan los artefactos

Cada artefacto se guarda con cuatro campos:

Title

add-auth/developer/dev-spec El nombre legible del artefacto.

Topic Key

asdt/add-auth/developer/dev-spec La clave con la que se recupera automáticamente, sin matching difuso.

Type

decision La categoría del artefacto — architecture, decision, bugfix, etc.

Project

asdt El proyecto al que pertenece, para que los resultados no se mezclen entre proyectos.

Cuando un especialista necesita un artefacto previo, llama a mem_search — la llamada de búsqueda que un especialista usa para ubicar un artefacto por su topic_key (la etiqueta exacta con la que se guardó y con la que se lo vuelve a encontrar) — y luego a mem_get_observation, la llamada que trae el contenido completo una vez que la etiqueta coincide. Es una búsqueda de un paso — sin matching difuso, sin escaneo de contexto.

Continuidad entre sesiones

Retomar un pipeline después de cerrar una sesión es igual que continuarlo en medio de una:

/asdt-developer Implementar basándose en el ADR del Arquitecto

El Developer busca el artefacto del Arquitecto en la base de conocimiento por clave. Si lo encuentra, procede normalmente. Si no, anota el input faltante y continúa con el contexto disponible.

Los límites de sesión no importan. El output del Arquitecto del lunes es tan legible para el Developer del jueves como si hubieran corrido uno tras el otro.

Scope por proyecto

Cada llamada a mem_save — la llamada de guardado que un especialista usa para almacenar su propio artefacto — incluye un campo project. ASDT deriva el nombre del proyecto de .asdt/config.yaml o del nombre del directorio. Los artefactos son buscables dentro del scope de un proyecto — correr ASDT en dos proyectos distintos no mezcla su memoria.

Qué no es Engram

Engram no es un sistema de archivos. Los artefactos son documentos, no archivos de código. Cuando el Developer produce snippets de código como parte de su artefacto de implementación, esos snippets viven dentro del documento de Engram — son especificaciones de qué escribir, no archivos en disco. El humano (o el asistente de IA en un paso posterior) los aplica al codebase real.

Esta separación es intencional. Los archivos de código tienen historial de git. Los artefactos tienen la base de conocimiento. Cada uno vive donde corresponde.