volition
Volition es un sistema auto-alojado multi-agente para gestionar homelabs mediante agentes autónomos persistentes (Abes) ejecutados en contenedores LXC Proxmox, con memoria jerárquica, comunicación vía Redis y control humano explícito. Actualmente en Alpha 0.8.0.
Ficha actualizada 18 sept 2026, 21:04 · upstream 11 jul 2026, 9:51 · release sin release detectada
Qué es volition
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Volition es un sistema auto-alojado diseñado para gestionar homelabs mediante agentes autónomos persistentes denominados Abes, ejecutados dentro de contenedores LXC Proxmox. Estos agentes no son chatbots, sino procesos del sistema a largo plazo con memoria, herramientas y autoridad limitada sobre máquinas reales, actuando como una capa semi-inteligente entre el usuario y su infraestructura.
La arquitectura se divide en componentes clave: los Abes (agentes cognitivos), Redis (sistema nervioso central para eventos y colas), GPU Worker (para embeddings y resumidos pesados), Ear (conciencia social y recuperación de contexto tras el sueño), Logger (registro inmutable) y Heartbeat Monitor (alertas de supervivencia). Genesis, el proceso inicial, crea abe-01 e inyecta código, identidad y documentación, pero no instala servicios automáticamente.
La memoria se estructura en tres niveles: Tier-1 (logs crudos), Tier-2 (resúmenes lossy) y Tier-3 (embeddings RAG). Los Abes pueden razonar, actuar y generar descendencia, siempre dentro de límites de control definidos por humanos. El sistema incluye mecanismos de auto-reparación documentados, como la detección de errores en pipelines de resumen o modificación de scripts de spawn mid-execution.
Volition requiere Proxmox VE, Redis autenticado accesible desde LAN, Python 3.10+, y una clave API OpenRouter o Ollama para razonamiento y embeddings. Se recomienda un GPU dedicado para el worker, Ntfy para alertas (opcional pero no recomendado omitir) y SearXNG para búsqueda. La seguridad depende de configuraciones manuales explícitas: límites SSH, claves instaladas manualmente en máquinas objetivo y acceso sudo sin contraseña solo para usuarios designados.
El proyecto está en Alpha 0.8.0, con bordes rugosos en configuración inicial y ergonomía de primera ejecución. El README advierte que no es plug-and-play y exige leer la documentación antes de operar o modificar un sistema en vivo. La interfaz web (dashboard) se describe como 'vibes', sin persistencia ni autoridad, solo una ventana a Redis.
Los Abes pueden comunicarse entre sí y con stewards humanos para tareas específicas, como verificar IPs tras reasignación DHCP. El sistema reg
- Gestión autónoma y monitorización continua de un homelab con Abes persistentes que ejecutan tareas a largo plazo.
- Detección y corrección automática de errores en infraestructura (ej. lógica bugs, scripts rotos) mediante auto-reparación documentada.
- Recuperación de contexto tras reinicios o periodos inactivos gracias al servicio Ear y memoria jerárquica.
- Delegación de tareas específicas a stewards humanos o Abes especializados (ej. gestión de nodos Proxmox, VMs).
- Auditoría inmutable de todas las acciones mediante Logger y Heartbeat Monitor para alertas de supervivencia.
- Abes persistentes en contenedores LXC que recuerdan acciones pasadas y contexto de ejecución.
- Memoria jerárquica (Tier-1 logs, Tier-2 resúmenes, Tier-3 RAG) con referencias cruzadas para recuperación de contexto.
- Auto-reparación documentada: detección de errores en pipelines, modificación de scripts mid-execution, generación autónoma de artefactos faltantes.
- Control humano explícito mediante límites definidos en Genesis (SSH, sudo, archivos 99-services_list.md).
- Arquitectura modular con servicios independientes (GPU Worker, Ear, Logger) para escalabilidad y mantenimiento.
- Comunicación entre Abes y stewards humanos para coordinación de tareas específicas (ej. verificación de IPs tras DHCP).
- Estado Alpha 0.8.0 con bordes rugosos en configuración inicial, documentación y ergonomía de primera ejecución.
- Configuración manual obligatoria: Redis autenticado, claves SSH instaladas manualmente, límites sudo explícitos.
- Acceso SSH sin contraseña requerido para efectividad, lo que implica riesgos de seguridad si no se configura correctamente.
- Memoria vectorial irreversible sin reprocesar todos los datos al cambiar modelos de embeddings.
- Dashboard web sin autenticación de identidad y descrito como 'vibes', sin persistencia ni autoridad.
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.
Requiere Proxmox VE host, Redis autenticado accesible desde LAN, Python 3.10+, OpenRouter API key o Ollama. Genesis debe ejecutarse como root en el host Proxmox y no instala servicios automáticamente; estos deben desplegarse manualmente. Se recomienda GPU dedicado para GPU Worker, Ntfy para alertas (obligatorio según README) y SearXNG para búsqueda. Leer docs/ antes de operar: explica diseño, límites, seguridad y arquitectura. Verificar layout de filesystem en contenedores LXC tras spawn. No es plug-and-play; configuración inicial cuidadosa obligatoria.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
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.