Inferencia local sobre Ollama
Sin llamadas a APIs externas. El agente arranca contra el runtime local de Ollama, lo que mantiene los datos del usuario dentro de su máquina y hace que Pandora siga funcionando sin red.
[C03] AXIOM ZERO
Pandora — agente IA local autoevolutivo, no un chatbot.
Producto propio. Agente autónomo que corre 100% en local sobre Ollama, con memoria persistente (ChromaDB), voz, conciencia de hardware y un motor de evolución que lo deja mejorarse a sí mismo bajo supervisión humana. Inspirado en Overlord.
[01] Resultados
Resultados del caso
- 100% offline · sin APIs externas
- Local
- autonomía gradual (0–5)
- 6 niveles
- público en GitHub
- Open source
- stack principal
- Python · Rust · TS
[02] Contexto
De dónde venía el cliente.
La mayoría de "agentes IA" del mercado son wrappers sobre APIs propietarias con cero garantías sobre datos, sin estado real entre sesiones y sin idea alguna del hardware en el que corren. Pandora va al revés: agente con identidad, memoria persistente y voz, ejecutado íntegramente en local sobre Ollama, capaz de pedir upgrades de hardware y de evolucionarse a sí mismo bajo control humano.
[03] Reto
Lo difícil de verdad.
- 01
Que el agente conserve identidad y memoria entre sesiones, sin depender de un servicio cloud.
- 02
Auto-percepción real del hardware (CPU, RAM, GPU, disco) para detectar cuellos de botella y pedir upgrades.
- 03
Niveles de autonomía graduales (0–5) con un kill switch real, no decorativo.
[04] Enfoque
Cómo lo abordamos.
Las decisiones que cambiaron el resultado. No las que quedan bonitas en una presentación.
-
01 / 03 -
02 / 03 Memoria persistente con ChromaDB
Estado del agente, conversaciones e historial de evolución almacenados en ChromaDB local. La identidad sobrevive a reinicios y al cambio de modelo base.
-
03 / 03 Tooling con sandbox real
Herramientas internas — FileManager, CodeWriter y CodeExecutor — para que el agente lea ficheros, escriba código y lo ejecute. La ejecución vive siempre en un sandbox Docker para que un agente "creativo" no toque el sistema host.
[05] Entregado
Lo que se quedó el cliente.
- 01
CLI interactiva con comandos de status, autonomía, voz y evolución forzada.
- 02
Dashboard de hardware en vivo (CPU/GPU/RAM, refresco cada 2s).
- 03
Motor de evolución con benchmarks y registro histórico de cambios.
- 04
Modo voz concurrente con texto (mic + chat).
- 05
Kill switch + niveles de autonomía configurables (0 a 5).
[06] Stack
Con qué se construyó.
- Python
- Ollama
- ChromaDB
- Rust
- TypeScript
- Docker
Decisión clave
Stack elegido por contexto del cliente, no por preferencia del equipo. Si una herramienta no encaja con su realidad operativa, no entra.
[07] Testimonio
Testimonio del cliente
Pendiente.
Producto propio
[08] Lecciones
Lo que nos llevamos nosotros.
Tres aprendizajes que cruzan al siguiente proyecto. Algunos eran obvios en retrospectiva, otros no.
- 01
Construir para "100% local" desde el primer commit es más barato que cloudificar primero y portarlo después: cambia decisiones de almacenamiento y tooling enteras.
- 02
Niveles de autonomía graduales son la forma honesta de subir capacidades de un agente sin perder el control: cada salto se decide explícitamente.
- 03
Hardware-awareness no es feature de marketing — sin ella el agente no sabe qué pedir, y "que pida lo que necesita" es media batalla en agente local.
[09] Contacto
¿Tienes un problema técnico que merezca la pena resolver bien?
Escríbenos. Te respondemos en 48 horas con una primera lectura honesta: si encajamos, si no, o si conocemos a alguien mejor para tu caso.