Cómo construí Dome: de un knowledge base propio a un entorno con IA nativa que gestiona su propio desarrollo

Dome no nació como producto. Nació de una frustración.

Tenía todo mi conocimiento repartido entre carpetas, apps y pestañas del navegador: papers, notas y PDFs sin conexión entre sí. Probé NotebookLM y otras herramientas de gestión de conocimiento, pero ninguna cubría lo que yo necesitaba de verdad: un sitio local, propio, donde todo estuviera indexado, buscable y conectado, con búsqueda semántica sobre mis propios documentos.

Así que dejé de buscar la herramienta perfecta y me puse a construirla. Al principio era eso y solo eso: un knowledge base para pensar mejor.

De base de conocimiento a gestor de proyectos

Lo interesante pasó después, casi sin darme cuenta.

Cuando tienes todo tu conocimiento en un solo sitio, empiezas a pedirle cosas. Y cuando le pones un agente encima, deja de ser un archivo y se convierte en un espacio de trabajo. Dome fue mutando: de guardar papers a organizar proyectos en pipelines, crear hitos e issues, y llevar el tracking del desarrollo… de sí mismo.

Y lo hice con una idea clara: cada paso de un pipeline puede ser manual o delegado a un agente. Puedo mover una tarjeta a mano, o dejar que un agente redacte la propuesta, genere el informe o prepare el siguiente paso por mí. El pipeline se ejecuta solo cuando quiero que se ejecute solo.

Sincronizado con mi GitHub

El desarrollo de Dome vive en GitHub, así que conecté las dos cosas.

Dome se sincroniza con mi repositorio y me deja seguir milestones, issues y releases desde un Kanban (o un Gantt) dentro de la app. Cada tarjeta es un issue real, cada columna un milestone (v2.9.0, 2.8.0, 2.7.0…), y puedo abrir el detalle de un issue con sus comentarios y su actividad sin salir de Dome. Cada hito del proyecto se planifica, se sigue y se cierra desde aquí, y desde el mismo sitio salta al calendario.

Tiempo y correo, sin salir de la app

Otras dos piezas que quería fuera de las pestañas del navegador: mi tiempo y mi correo.

Le pido a Many (mi copiloto) que gestione mi calendario, y este se sincroniza con los releases y milestones de Dome y con mis pipelines. Cuando saco una versión o cierro un hito, aparece en el calendario sin que yo mueva un dedo. Y desde Dome controlo mi correo personal: Many busca, lee y resume mis emails sin que yo salga de mi espacio de trabajo.

Extensible: skills, MCP y un marketplace que crece

Dome no es una caja cerrada.

Usa skills (capacidades en formato archivo) y servidores MCP para conectarse a servicios externos, y tiene un marketplace donde poco a poco se van añadiendo MCP, agentes, skills y plugins. Añadir una nueva integración no significa reescribir la app: significa instalar algo del store.

---

El motor: de LangGraph + deepagents a un harness nativo

La decisión técnica más importante del proyecto fue quitar la abstracción del medio.

Empecé, como casi todo el mundo, sobre LangGraph + deepagents. Funcionaba, pero era una caja negra sobre el loop del agente: poco control sobre las tools y el estado, difícil de auditar, difícil de optimizar. Cada vez que quería entender por qué el agente hacía algo, chocaba contra capas que no eran mías.

Así que lo reescribí entero. Hoy Dome corre sobre un harness nativo (@dome/agent-core) que controla el loop completo (stream → tools → repeat) con validación de argumentos, hooks before/after para guardrails, caps y HITL (human-in-the-loop), y compactación de contexto. Los workflows ya no dependen de un StateGraph: los secuencia un ejecutor DAG topológico nativo.

El resultado: menos latencia y, sobre todo, todo auditable. Veo y controlo cada paso.

Las decisiones que importan (ingeniería, no magia)

Un agente que funciona de verdad es una suma de decisiones pequeñas y aburridas hechas bien:

• Base de datos. SQLite con better-sqlite3 en el proceso principal más migración incremental a Drizzle. Aprendí por las malas a nunca tocar el WAL al arrancar: borrar los sidecars -wal/-shm en el preflight me costó perder registros recién creados. Ahora se recupera y se verifica, nunca se borra a ciegas.
• Prompts. Optimizados por presupuesto de tokens y ensamblados por secciones, no un muro de texto.
• Tool surface. Mínima y explícita. Solo las tools que el agente necesita, no un cajón de sastre. Menos superficie significa menos errores y decisiones más nítidas.
• Safeguards. Guardrails reales: HITL, caps de iteraciones, validación de argumentos antes de ejecutar. La seguridad no es un extra, es parte del loop.

Qué cambia frente a otros harness (Hermes, OpenClaw)

Existen harness excelentes: Hermes, OpenClaw y otros. ¿Qué aporta lo mío?

No pretendo competir con un harness genérico. Mi aporte es que el mío es propio, a medida y pegado a mi conocimiento:

1. Nativo y auditable. Sin caja negra: veo y controlo cada paso del agente.
2. Papers a features. Aprendo directamente de los papers, los implemento y los mido dentro de Dome. El paper deja de ser teoría el día que lo puedo medir en mi propia herramienta.
3. Integrado en mi KB. El agente no vive en una terminal aparte: vive dentro de mi base de conocimiento, con acceso a mis papers, mis notas y mi contexto real.

Ese es el diferencial. No es “otro agente más”, es un agente que conoce lo que yo sé.

El nuevo día a día: Many revisa mi código

La pieza que cerró el círculo fue automatizar mi propio flujo de trabajo.

Hoy Many y el agente hacen code review de Dome: leen el diff de una rama antes de que la mergee, detectan el await que falta, el guard que no puse, el borrado en cascada que sí está bien. Procesos que antes eran manuales ahora son automáticos, y viven dentro del mismo entorno donde estudio, planifico y construyo.

Por qué hago esto

Porque construir tu propia herramienta te obliga a entenderla de verdad. Cada paper que leo lo puedo probar. Cada decisión de arquitectura la vivo en mi día a día. Y cada mejora hago en Dome, Mejora mi conocimiento.

Dome empezó porque ninguna herramienta hacía lo que yo necesitaba. Terminó siendo el sitio donde investigo, planifico y construyo. Construido dentro de Dome.