dense-mem
Dense-Mem es un servidor de memoria para agentes de IA autocontenido que utiliza HTTP Streamable y el protocolo MCP.
Ficha actualizada 22 sept 2026, 22:53 · upstream 22 sept 2026, 22:44 · release v2.6.3
Qué es dense-mem
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Dense-Mem es un servicio autónomo que actúa como memoria para agentes de IA. Su arquitectura se basa en un modelo donde el LLM propietario del equipo gestiona la conversación y las juicios, mientras Dense-Mem se encarga de la evidencia duradera, la autorización del propietario, los eventos de ciclo de vida, la elegibilidad de soporte y una recuperación limitada (recall). El contrato de automatización externa es MCP a través de /mcp, mientras que las interfaces en el navegador son interfaces propias. PostgreSQL actúa como autoridad duradera para conocimiento, ciclo de vida, proveniencia, búsqueda, autorización y auditoría; Redis se utiliza únicamente para coordinación.
- Gestionar la memoria contextual de agentes LLM autoadministrados
- Almacenamiento seguro y auditado de evidencia de decisiones empresariales
- Creación de registros de ciclo de vida para activos digitales o procesos
- Soporte a equipos distribuidos con visibilidad compartida de conocimiento
- Registro de intentos de resolución de conflictos entre agentes
- Sistema de trazabilidad para auditoría regulatoria y compliance
- La evidencia es exacta, duradera y append-only; un cambio en el estado efectivo no elimina la proveniencia ni la línea de trazo.
- Las entidades y valores tipo son nodos semánticos. Las relaciones entre entidad y alias del propietario se convierten en aristas activas solo cuando su evidencia soporta la elegibilidad.
- La salida del proveedor es una propuesta; el estado duradero se decide mediante validación de esquema cerrado y política determinista del servidor.
- El recall por defecto excluye candidatos e hipótesis, devolviendo evidencia únicamente cuando su ruta de soporte activo es elegible para el tiempo solicitado.
- La visibilidad del equipo y la autoridad de mutación del propietario son entidades separadas. Un autor puede modificar solo su propia evidencia o registros semánticos que posea.
- En un entorno local sin Redis, la coordinación se realiza en el proceso local; para múltiples instancias es requerido Redis o una implementación equivalente distribuida.
- La durabilidad de conocimiento depende exclusivamente de PostgreSQL con pgvector como autoridad única; no hay respaldo secundario ni fallback.
- Existe un límite de 7 días para capturas de respuesta, lo que puede afectar la trazabilidad a largo plazo.
- No existe una API pública alternativa al MCP como contrato de automatización externa.
- La validación del modelo de verificador y asesorador se realiza antes de aceptar escrituras de memoria; modelos grandes pueden exceder el timeout por carga.
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Se requiere un entorno Docker con PostgreSQL + pgvector. Se ejecuta mediante docker-compose base que no necesita contenedor separado para migraciones, ya que las migraciones pendientes se aplican dentro de una sesión de base de datos antes del servicio. Para la versión v2.6.1, se debe detener todos los servidores, tomar un snapshot de PostgreSQL y aplicar el límite de servicio antes de iniciar el nuevo binario. La imagen healthcheck permite un margen de 30 minutos para migraciones pendientes; si POSTGRES_MIGRATION_TIMEOUT_SECONDS excede 1800 segundos, se debe ajustar la duración mínima del inicio del check de salud.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.