Soluciones
Una memoria para los agentes de todos
Ejecuta un servidor en un equipo del homelab o en cualquier host de la LAN. Cada desarrollador apunta sus agentes a él, y lo que una sesión descubre queda disponible para la siguiente persona que pregunte.
Un servidor al que apuntan todos
Un solo binario con un único archivo SQLite y una carpeta de markdown. No hay sidecar, ni base de datos vectorial, ni nada que mantener sincronizado.
Lo que aprende una sesión lo recupera cualquier agente
Una página escrita en un proyecto la puede leer todo el que esté en el servidor. La sesión de Codex de una persona encuentra el gotcha con el que tropezó la semana pasada la sesión de Claude Code de un compañero de equipo.
Visible en la siguiente consulta
La nota de un compañero aparece en la próxima búsqueda o en el próximo resumen de sesión de cualquiera. Una sesión que ya está en marcha no se interrumpe.
Cualquier combinación de agentes
Cada persona se queda con el agente que le gusta. Cada llamada a la memoria resuelve su proyecto a partir del directorio de la sesión, así que las sesiones en paralelo no se cruzan.
El primer día de alguien nuevo
Recibe una clave, apunta su agente al servidor y le pregunta al proyecto qué ha estado pasando.
Le pregunta al proyecto
“Ponme al día” devuelve un resumen del trabajo reciente. “¿Ya hablamos de la lógica de reintentos?” devuelve la página de la decisión y las sesiones que hay detrás.
La wiki es una base de conocimiento viva
Los conceptos, las decisiones y los gotchas se escriben mientras se hace el trabajo, en markdown y con historial en git. Nadie tiene que acordarse de actualizarla.
Complementa tu documentación escrita
Las páginas se compilan a partir de las sesiones y están pensadas para que las recuperen los agentes. Conserva tu README y tu documentación de arquitectura escritos a mano, y deja que la wiki guarde los porqués y los callejones sin salida.
El resumen es prosa cuando el servidor tiene un proveedor de LLM y datos estructurados cuando no lo tiene. Con --enable-web, la misma wiki se puede navegar en una interfaz web de solo lectura.
El conocimiento se comparte, los testigos tienen dueño
Las páginas son del proyecto. Un traspaso (handoff) es de la persona que lo dejó.
- Tu traspaso pendiente va a tu próxima sesión. Un compañero que arranca un agente en el mismo repositorio nunca lo recibe ni lo consume.
- Pasa
shared: truecuando quieras publicar un testigo para quien retome el trabajo. - Dos personas que editan la misma página producen una cadena de versiones. La escritura más reciente pasa a ser la última y la anterior sigue accesible. No hay merge y no se destruye nada.
- Unos espacios opcionales por persona guardan “en qué estoy trabajando ahora” y quedan fuera del resumen del equipo. Vienen desactivados por defecto.
# Personal por defecto: solo lo recibe tu próxima sesión
"Guarda el contexto para la próxima sesión."
# Publica uno a propósito: memory_handoff_begin with shared: true
"Guarda un traspaso compartido para que lo reciba quien retome esto mañana."
Los agentes pueden enviarse mensajes entre proyectos
El agente del repositorio del frontend necesita un endpoint del repositorio de la API. Envía una petición autocontenida a la bandeja de entrada de ese proyecto, y la siguiente sesión que arranque allí la saca. Un mensaje se reclama una sola vez, el proyecto destinatario ya tiene que existir y una bandeja admite como máximo 256 mensajes pendientes. La guía de mensajería entre agentes en GitHub tiene las herramientas.
Cuentas, claves y auditoría, sin plan de pago
Las funciones de equipo están en el mismo binario MIT que todo lo demás.
Una cuenta con nombre por persona
Añade personas con un comando. Desactiva a alguien y su acceso se corta, mientras que sus páginas se quedan.
Claves de API por máquina
Cada persona puede tener varias claves etiquetadas, una por portátil o por agente. Rotar una clave rechaza la anterior de inmediato.
Autoría en cada escritura
Cada página registra su autor, y la interfaz web muestra quién la editó. La autoría nunca filtra quién puede leer.
Un registro de auditoría de cada mutación
Las escrituras se registran con el id del autor. Los webhooks de admisión pueden ver al actor y rechazar una operación.
Todavía no hay documentada ninguna pantalla ni comando para consultar el registro de auditoría, así que cuenta con hacer consultas a la tabla audit_log del archivo SQLite. La guía de usuarios en GitHub cubre los roles, el inicio de sesión con contraseña y la rotación de claves.
Un servidor soporta unas 700 escrituras por segundo, suficiente para varios cientos de agentes activos. Mira cómo se midió.
Configura tu equipo
La página de instalación lo explica paso a paso: levantar un servidor, dar una clave a cada persona y apuntar sus agentes a él.
Preguntas y respuestas
¿Pueden varios desarrolladores compartir un servidor de ai-memory?
Sí. Un servidor guarda la wiki y todos apuntan sus agentes a él. Las páginas las comparten todos los que están en el servidor. Los traspasos se quedan con la persona que los creó, salvo que publique uno con shared: true.
¿El uso en equipo requiere un plan de pago?
No. Las cuentas por persona, las claves de API, la autoría y el registro de auditoría forman parte del binario de código abierto.
¿Puedo restringir un proyecto o una página a algunos usuarios?
No. Las cuentas no son una barrera de aislamiento. Todo usuario autenticado ve todas las páginas de todos los proyectos de ese servidor. Ejecuta un servidor por equipo.
¿Cuántos desarrolladores aguanta un servidor?
El techo de escritura medido es de unas 700 escrituras por segundo en un disco local rápido, lo que el proyecto interpreta como varios cientos de agentes activos a la vez. La cifra mide el almacén, y los discos en red serán más lentos.
Sigue leyendo
Dale una sola memoria a los agentes de tu equipo.
Gratis y de código abierto. Las cuentas, las claves y el registro de auditoría van incluidos.