Building Vault v2: Making My Second Brain Dependable

This has probably been the longest build I’ve taken on for PersonalOS. I’m hoping it also becomes one of the most meaningful.

The goal sounds straightforward: make the same second brain available across my phone, iPad, work laptop and Mac mini. I use Claude and Codex today, and eventually want other interfaces—including GrokBot and self-hosted models—to use the same underlying system. Wherever I’m working, I should be able to find useful information, capture a thought and check whether an action completed. Access from my work laptop will also depend on what its environment permits.

Getting a demo to do that is one problem. Getting it to work reliably with years of personal notes, overlapping automations, sensitive information, intermittent connectivity and multiple AI tools is a much larger one.

We’ve reached a real checkpoint. I’ve connected Claude to a dedicated test service, submitted a note from my iPad, watched it become a file on the Mac mini, and asked Claude to confirm that it was saved. That complete path works in an isolated test environment. It has not been activated against my everyday vault yet.

The other half—helping AI retrieve the right information more accurately and efficiently—has been harder. Our new retrieval system still hasn’t earned its way into production.

What I’m trying to build

My existing second brain lives in Obsidian. Underneath the interface, it’s a collection of Markdown files: ordinary text documents with links, headings and a little structured information. Git keeps their history.

That foundation stays. I want to keep owning readable files, rather than make a particular AI product the only way to access my information.

Vault v2 adds services around those files. The intended division is simple: notes hold context and history; Todoist will hold task state; AI helps me find information and carry out approved actions. A small dashboard should tell me when something needs attention.

The operating principle is: AI works autonomously within guardrails. I review exceptions and make decisions.

I don’t want to approve every routine step. I do want to know when an action is ambiguous, a permission is missing, or a change would affect something outside the agreed scope.

Where the work happens

There are several moving parts, but each has a specific job.

• Obsidian and Markdown files: the durable home for my notes.
• Mac mini: runs the worker that turns an approved capture into a note.
• Vercel: hosts the internet-facing connection used by the AI client.
• Neon Postgres: holds queued capture requests and authentication data in their respective databases.
• Local SQLite database: tracks execution and recovery on the Mac.
• Claude, Codex and future interfaces: give me conversational access to the same underlying system.

MCP—the Model Context Protocol—is the interface that lets compatible AI clients call tools exposed by the service. The planned tools include querying notes, retrieving supporting passages, capturing new notes and checking action status. We’re releasing these capabilities in stages: the current production candidate enables capture and status first. Querying remains part of the goal, with activation waiting on retrieval quality and access checks. Capture-only is a rollout stage, not the finished product.

A capture gets a receipt-like identifier. The cloud service queues it, the Mac worker picks it up, and the client can ask whether it is still queued or has been applied.

That separation matters. If the Mini is offline, an accepted request can wait in the queue, subject to its expiration period. It cannot become a local note until the worker runs. The system should say “queued” rather than pretend the note has already been saved.

The milestone that now works

The most tangible result so far is a real test through Claude on my iPad.

I signed in, approved the connector, and asked it to capture a short synthetic note. The service returned a queued request. We then ran the worker against a purpose-built test vault containing no real notes.

The worker created exactly one note in its inbox, recorded the result, and removed the capture text from the active queue. A later status call from Claude reported “applied” with the note reference.

This was more than a local script pretending to be a client. It exercised the hosted connection, login, consent, token exchange, database queue, Mac worker and final status response.

It also tested a crucial distinction: the successful note landed in the test vault, not my everyday Obsidian vault. The test proves the path works. Production readiness requires the remaining checks and a deliberate rollout.

The difficult part: finding the right evidence

I expected an index over my notes to make AI retrieval faster and better. That assumption hasn’t held up consistently.

We compared two approaches: an AI using ordinary file tools, and an AI using the new pos retrieval tool. We used the same questions and evaluated correctness, citations, supporting evidence, context consumed and elapsed time.

In one full evaluation, all 174 planned sessions completed. The new system still missed the acceptance criteria.

The clearest finding was the difference between finding a file and finding an answer.

The index was very good at identifying the right source file. But it often returned a title, outline or citation without the passage needed to answer the question. The AI sometimes stopped there instead of reading further.

Imagine asking whether you still owe someone a follow-up. A search result pointing to the correct meeting note is useful. The sentence saying “we already completed that last week” is what decides the answer. A filename alone doesn’t do that.

Other misses came from conversations that didn’t contain the query’s obvious keywords. A later discussion could change a project’s direction without repeating the project name. A keyword search could find the polished project page and miss the conversation that superseded it.

The underlying search tool itself was fast—tens of milliseconds in the reported tests. The whole AI interaction wasn’t consistently faster. Search choices, extra reading and answer generation consumed the time.

We tried showing supporting excerpts and reducing duplicate results. Some changes improved individual rankings, but the measured answers didn’t improve enough to justify release. I’m keeping that distinction visible: a promising implementation is not the same as a demonstrated user benefit.

The old system was creating noise

An inventory of the vault uncovered another problem: repeated task information.

Daily notes contained hundreds of generated checkbox lines copied from a much smaller set of actions. One action appeared in dozens of journals. Empty template boxes and historical checklists made the apparent task backlog much larger than the live one.

After classification and deduplication, 1,520 open checkbox lines became 317 distinct live actions, including decisions and migration candidates.

For retrieval, those copies can be misleading. An old task copied into a newer daily note can look more current than the meeting that resolved it. Repetition can crowd the better evidence out of search results.

Down-ranking those copies improved source rankings in test experiments. It still didn’t solve enough of the end-to-end retrieval problem.

This is also why I’m resisting a dramatic folder cleanup. We first need to preserve unique commitments and establish where task state belongs. Moving tasks to Todoist is still pending live acceptance and migration decisions. Deleting apparent clutter before that would risk deleting the only record of something I promised to do.

Reliability exposed problems a happy-path demo wouldn’t

The capture path uncovered failures at several different layers.

On the iPad, the consent page initially wouldn’t return to Claude. The server had accepted the approval, but a browser security policy blocked the redirect. Our script-based tests missed it because they didn’t enforce that browser rule.

A later test deployment inherited an encrypted signing key from another environment while using a different secret. Login and consent worked, but issuing a token failed. That taught us to treat copied authentication state as part of deployment, not just application code.

Retries and crashes required their own design. If a response gets lost, submitting again must not create a second note. If the worker crashes after writing a file but before recording success, recovery needs to recognize its earlier work.

We tested that crash window explicitly. Recovery found the note and completed the record without writing it again.

We also investigated intermittent vault-write test failures. The captured failures pointed to the simulated editor’s in-place saves and interference from scheduled Git snapshots. That led to a narrower test correction, while preserving strict checks for unexpected production changes.

Some work really was necessary engineering. Some was correcting our own test setup, coordination and assumptions. Both belong in this build log.

Secure storage without making my own notes unusable

Another correction was conceptual. I need to store work notes securely and retrieve them usefully. A blanket folder exclusion doesn’t meet that need.

We separated four questions: may this information be stored, may I retrieve it, may a particular AI provider process it, and may it be published? Approval of one does not automatically approve the others.

For the first capture trial, the scope is intentionally small: ordinary personal test content, explicit labels, new inbox files only, and a low daily cap. Labels are assertions supplied by the client; they do not magically detect sensitive content.

Database permissions are separated too. The web route can submit requests and inspect status. The worker can obtain a payload through its claim. The authentication service has its own restricted role. Each component gets the access it needs for its job.

The build also prompted backup work that was valuable on its own. Older plaintext archives were replaced with encrypted copies, verified through fresh downloads and restore checks. Recovery instructions were exercised, and several commands that would have failed during an emergency were corrected.

That is progress even before the new AI interface reaches production.

Using agents without creating more work

Claude and Codex have helped with coding, investigation, evaluation and review. Parallel agents let independent work move together, but they also introduced coordination costs.

We’ve had to deal with overlapping Git activity, usage limits, interrupted runs and supposedly independent evaluation questions that shared evidence with development work.

The process is becoming more deliberate: give each agent a bounded job, choose a model appropriate to it, freeze the code used in a measurement, checkpoint interrupted work, and avoid repeating completed work without a reason.

I’ve also stopped treating token consumption as an achievement. What matters is whether the system produces a useful, dependable result. More agents and more tests only help when they resolve something we actually need to know.

What remains

There are two different finish lines.

The first is a small production capture release. The test path works. Remaining work includes the final review fixes, a strict test of the complete release candidate, scheduled-cleanup evidence, rollback verification and production-specific deployment checks. Then comes an approved rollout and a real-device check against the production service.

Execution scripts are being prepared to verify each stage and resume from checkpoints. The aim is to approve a concrete scope once, then let the routine work proceed without babysitting every command.

The second is dependable retrieval and the broader workflow. Retrieval still needs better evidence selection and independent evaluation. Todoist needs live acceptance and a careful task migration. Shared-file editing has additional checks beyond this new-file-only capture release. Access for additional AI clients also needs its own verification.

I’m not assigning a completion percentage to that larger goal. The capture work is approaching a controlled rollout; the retrieval work still has an unresolved quality problem. Those are different kinds of remaining work.

What the finished experience should feel like

Eventually, I want to use my phone, iPad, work laptop or Mac mini, capture a thought, and know whether it is waiting or safely saved. I want to ask what changed in a project and receive an answer supported by the relevant passages. I want one place to manage tasks, clear handling rules for sensitive notes, and visible exceptions when something cannot be completed safely.

I want to be able to change AI tools without rebuilding the system around a new chat history. And I want a backup I can actually restore.

This checkpoint isn’t a claim that all of that is finished. It is evidence that part of it now works, and a more honest understanding of what the rest requires.

If the build succeeds, its most meaningful result will be less maintenance: fewer copies, fewer manual handoffs, and fewer reasons to wonder whether an automation did what it said it did.