How I built Dome: from a personal knowledge base to a native-AI environment that manages its own development

Dome did not start as a product. It started out of frustration.

I had all my knowledge scattered across folders, apps, and browser tabs: papers, notes, and PDFs with no connection between them. I tried NotebookLM and other knowledge-management tools, but none of them covered what I actually needed: a local, self-owned place where everything is indexed, searchable, and connected, with semantic search over my own documents.

So I stopped looking for the perfect tool and started building it. At first it was just that: a knowledge base to think better.

From knowledge base to project manager

The interesting part came later, almost by accident.

When you have all your knowledge in one place, you start asking it for things. And when you put an agent on top, it stops being an archive and becomes a workspace. Dome kept mutating: from storing papers to organizing projects in pipelines, creating milestones and issues, and tracking the development… of itself.

I built it with one clear idea: every step of a pipeline can be manual or delegated to an agent. I can move a card by hand, or let an agent draft the proposal, generate the report, or prepare the next step for me. The pipeline runs itself only when I want it to.

Synced with my GitHub

Dome’s development lives on GitHub, so I connected the two.

Dome syncs with my repository and lets me track milestones, issues, and releases from a Kanban (or a Gantt) inside the app. Each card is a real issue, each column a milestone (v2.9.0, 2.8.0, 2.7.0…), and I can open an issue’s detail with its comments and activity without leaving Dome. Every milestone gets planned, tracked, and closed from here, and from the same place it jumps to the calendar.

Time and inbox, without leaving the app

Two more pieces I wanted out of my browser tabs: my time and my email.

I ask Many (my copilot) to manage my calendar, and it syncs with Dome’s releases and milestones and with my pipelines. When I ship a version or close a milestone, it shows up on the calendar without me lifting a finger. And from Dome I control my personal inbox: Many searches, reads, and summarizes my emails without me ever leaving my workspace.

Extensible: skills, MCP, and a marketplace that grows

Dome is not a closed box.

It uses skills (file-based capabilities) and MCP servers to connect to external services, and it has a marketplace where MCP servers, agents, skills, and plugins are added over time. Adding a new integration does not mean rewriting the app: it means installing something from the store.

---

The engine: from LangGraph + deepagents to a native harness

The most important technical decision of the project was removing the abstraction in the middle.

I started, like almost everyone, on LangGraph + deepagents. It worked, but it was a black box over the agent loop: little control over tools and state, hard to audit, hard to optimize. Every time I wanted to understand why the agent did something, I hit layers that were not mine.

So I rewrote it entirely. Today Dome runs on a native harness (@dome/agent-core) that controls the full loop (stream → tools → repeat) with argument validation, before/after hooks for guardrails, caps and HITL (human-in-the-loop), and context compaction. Workflows no longer depend on a StateGraph: a native topological DAG executor sequences them.

The result: lower latency and, above all, everything is auditable. I see and control every step.

The decisions that matter (engineering, not magic)

An agent that actually works is a sum of small, boring decisions done well:

• Database. SQLite with better-sqlite3 in the main process plus an incremental migration to Drizzle. I learned the hard way to never touch the WAL on startup: deleting the -wal/-shm sidecars in the preflight cost me freshly created records. Now it recovers and verifies, never deletes blindly.
• Prompts. Optimized by token budget and assembled by sections, not a wall of text.
• Tool surface. Minimal and explicit. Only the tools the agent needs, not a junk drawer. Less surface means fewer errors and sharper decisions.
• Safeguards. Real guardrails: HITL, iteration caps, argument validation before executing. Safety is not an add-on, it is part of the loop.

What changes versus other harnesses (Hermes, OpenClaw)

There are excellent harnesses out there: Hermes, OpenClaw, and others. So what do I bring?

I am not trying to compete with a generic harness. My contribution is that mine is my own, tailored, and glued to my knowledge:

1. Native and auditable. No black box: I see and control every step of the agent.
2. Papers to features. I learn directly from the papers, implement them, and measure them inside Dome. A paper stops being theory the day I can measure it in my own tool.
3. Integrated in my KB. The agent does not live in a separate terminal: it lives inside my knowledge base, with access to my papers, my notes, and my real context.

That is the difference. It is not “yet another agent”, it is an agent that knows what I know.

The new day-to-day: Many reviews my code

The piece that closed the loop was automating my own workflow.

Today Many and the agent do code review on Dome: they read the diff of a branch before I merge it, catch the missing await, the guard I forgot, the cascade delete that is actually fine. Processes that used to be manual are now automatic, and they live inside the same environment where I study, plan, and build.

Why I do this

Because building your own tool forces you to truly understand it. Every paper I read, I can test. Every architectural decision, I live with day to day. And every improvement I ship to Dome, I ship to myself.

Dome started because no tool did what I needed. It ended up being the place where I research, plan, and build. Built inside Dome.