Sitemap
Christopher Ramm

Christopher Ramm

DCX CTO Germany @ Capgemini | Salesforce Certified Technical Architect | Salesforce MVP | cramm.dev

My Second Brain Has a Cockpit Now. Claude Does the Driving.

9 min readOct 22, 2026

--

Obsidian is where I read my vault. To clear hundreds of open questions in one afternoon, I needed a different view, and Claude to carry the answers in.

Press enter or click to view image in full size
Obsidian for reading, a cockpit for deciding, Claude for the work.

Earlier this month I wrote that I stopped taking notes. Claude Code now maintains my second brain: immutable sources in one folder, a linked Markdown wiki in another, and one schema file with the rules. I read it in Obsidian and Git keeps the history.

That part works [Thank you, for all the comments and improvement tips!]. The wiki has passed a thousand pages since then, and Claude still writes every one of them.

But I left one page out of that article, because I had not solved it yet. The page was called open questions.

Every time Claude ingests a source, it finds things the source raises but does not answer. Who decides this? Which version is actually live? Is this still true after last week’s meeting? Claude cannot answer those questions. Only I can. So it wrote them down, one line each, on one page.

After a few weeks that page had more than hundred lines. Every ingest added to it. Nothing ever left. It was the most honest page in my vault and the least useful one.

Recently Tejas Sharma argued that Obsidian is now a database. Add a few properties to your notes, and the vault behaves like a table that you and an AI can query and I totally agree. The challenge is now how do you can easily consum it? This article is about the view I built for exactly that job, and about Claude as the vehicle that does the work behind it.

A view that shows loose ends does not close them

Tejas’s argument goes like this. The bottleneck of every knowledge system was never ideas or tools. It was maintenance. His opening line says it best: “The connections were never the hard part. Making them by hand was.” Plain Markdown files turned out to be the winning bet, because an agent can read and write them all day. Add properties and Obsidian’s Bases, and the vault “starts behaving like rows in a table that both you and an AI can query.”

My vault confirms most of it. Same layout: raw sources that never change, a wiki the model owns, a CLAUDE.md as the job description. Claude does the filing and the linking. I read the result in Obsidian, follow the links, look at the graph.

His last setup step is a Base that lists every page whose status is open. He calls it “your dashboard of loose ends.”

That is exactly where my problem started. I already had a dashboard of loose ends: the hundred-line page. Seeing the loose ends was never the issue; it was more the question how to process them in a suitable way. And keep all pages consistent.

For that I needed a different kind of view. Not one for reading or querying, but one for working through a queue as fast as possible, where every click turns into a clear job for Claude.

Why the open questions pile up

The model is very good at finding gaps. Give it a meeting summary, a mail thread or a slide deck, and it tells you what the source leaves open. That is a feature I value — creating connections and dots. It is also an asymmetry: the agent writes questions at machine speed, and I answer them at human speed (in the best case) or just ignore them because I have the answers in my brain.

And this obviously has an impact on my vault.

The list only grew. Every ingest appended and I didn’t closed anything. A question about a meeting three weeks ago looked exactly as urgent as one from this morning. The real questions drowned.

Answers left no trace. When I answered in a chat, Claude updated the right pages. But the evidence was my sentence in a chat window. The wiki then said “according to Christopher”. That overshadows the real source or evidence.

Decisions blurred into rewrites. When the model rewrites a page, the result is its best reading of the sources, not a commitment anyone made. A later agent reads that page and reopens a settled question with full confidence. Stefan Iarca describes this failure precisely in his piece on where teams should keep decisions.

Readers of my first article pushed on the same spot. One comment asked about provenance and confidence. Another made me check how often my sources actually contradict each other. So I measured it. Of roughly three-digit number open questions at the time, about one in five was a contradiction. Some were a newer source replacing an older one. Some were real conflicts. Some were simply two legitimate points of view.

None of this gets solved by a smarter model. It gets solved by a clear contract about who writes what.

In October I added two rules to my schema. Decisions go into a sealed register: one page per decision, with assumptions, rejected options and the conditions under which to revisit it. Only I change its status and anything I say in a chat is filed verbatim in the raw folder before the wiki changes. Pankaj’s The AI Second Brain Stack made that second point sharper than I had.

Rules in a schema file do not answer a single question, though. I still had hundreds of them. I needed a faster way through the queue that keeps the evidence intact and leaves the actual work to Claude.

The Vault Cockpit: one view, four choices

The Vault Cockpit is a small local web view on the same folder Obsidian reads. It is not a plugin and not a second database. It reads Markdown files and writes Markdown files, and every wiki page it mentions opens in Obsidian with one click. One command starts it: Python standard library, no dependencies, bound to localhost, no external calls.

The first line of its README describes the split: The model writes. The human decides.

What I see first. Five counters at the top: open, due today, suggestions by Claude, decisions to review, queued for Claude. Below them the open questions, filterable by domain, status, owner and age.

What one question looks like. The question, where it came from, the wiki pages it touches, and its history. Behind it sits one Markdown file per question, with an ID, an owner, a status and the date it was opened. The open-page became about 300 of those files.

Get Christopher Ramm’s stories in your inbox

Join Medium for free to get updates from this writer.

What I do. I type my answer. Most answers are one line. One of them was simply: “The app is live in the AppStore as Miasanrot, version 1.3.5” That was all the question needed. Then I pick what happens next:

  • Claude works it in.
  • Still open, follow up later, with a date. The question disappears until that date.
  • Just close. Nothing to work in.
  • Record as a decision. The answer becomes an entry in my decision register.

The form shows which files will be written. I save, and my words are stored verbatim as evidence in the raw folder before anything else changes.

Triage in batches. Claude marks questions that look done, stale or duplicated, each with a reason I can check at a glance. They show up in one list. I set a verdict per line, or select all when the reasons hold.

Claude is the vehicle

The cockpit itself calls no AI. No API key, no model, no network. It is the steering wheel. Claude Code is the vehicle that moves the work.

The handover is a single sentence. The inbox view has a button that copies it: “Work through the vault cockpit inbox.” I paste it into Claude Code in the vault folder. A skill tells Claude the rest: read each answer from the raw folder, update the affected wiki pages, cite the evidence, report the item as done.

Claude drives the same tool from the command line:

vault-cockpit add "Which market goes first?" --page project-alpha --origin "Ingest 2026-10-17"
vault-cockpit inbox --json
vault-cockpit done O-0042
vault-cockpit suggest O-0043 stale "The meeting on 2026-10-02 is over."

That is also how future questions arrive. When Claude ingests a new meeting summary or mail and finds a gap, it adds an item instead of appending a line to a page. The question shows up in my cockpit with its source attached, and the queue never turns back into a wall of text.

Press enter or click to view image in full size
Claude brings the questions in and carries the answers back. The human only steers.

Why the vault stays clean

Speed only helps if nothing breaks. Every action, a click in the cockpit or a command from Claude, runs as one transaction: evidence, item, log, generated overview and index, then the vault’s own lint. If any count gets worse, every file is restored and nothing is written. If everything passes, exactly the touched files go into one Git commit. Never a push.

The overview page of open questions still exists, but it is generated from the item files after every change. Nobody edits it by hand, not even Claude. Decisions follow the same rule: Claude may fill in a decision’s assumptions and rejected options, and flag it when a trigger to revisit it may have fired. Only I can mark it valid, superseded or withdrawn.

What happened when I switched it on

I migrated the real vault on a Saturday, just before noon. By late afternoon I had answered close to 280 questions. That is roughly one per minute. Claude worked through the inbox in parallel, hour by hour, a few minutes behind me. More than 200 answers were in the wiki by the end of the day. Claude also proposed close to 40 triage verdicts, about half of them “stale”.

A few days later, the vault holds only two open items. Eleven are waiting for a date. Everything else is answered, with my own words on file.

Press enter or click to view image in full size
One page that only grew, versus one file per question with an owner, a status and a history.

Reality check

The human is still the bottleneck, on purpose. hundred answers in an afternoon sounds like automation, but every one of them went through my head — hopefully. A reader of my first article warned that an AI-maintained second brain fills up with things that never went through your head. Fair point. The cockpit is the one place where everything does.

“Not decided yet” needs a home. Some of my answers were exactly that. Without a waiting status and a date, those questions would have stayed open forever, or worse, been closed by a confident rewrite. So I created now a parking lot for them.

Claude does not start by itself. The cockpit never calls Claude. Someone has to paste the prompt, or a scheduled routine has to pick up the inbox. In my vault, every session that touches the vault starts with a look at the inbox. Answers that sit there for days are just a nicer version of the old page.

Read in Obsidian. Decide in the cockpit. Let Claude drive.

Tejas ends his piece with: “Let the AI be the librarian. You go decide something.” I agree. I would add one thing: give yourself a place that is built for deciding fast, and let every decision turn into a job the AI can finish.

My split today is simple. Obsidian is where I read and think. The cockpit is where I answer and decide. Claude Code is the vehicle that carries every answer into the wiki and brings back the next questions.

This is a personal vault. The same split applies to every enterprise agent that reads company context. Someone has to answer the questions the agent cannot. The answer has to land somewhere with evidence. And someone has to own the right to close. Where does that happen in your agent setup today?

The Vault Cockpit is on GitHub under the MIT license: github.com/rammc/vault-cockpit. It comes with a fictional demo vault, so you can click through it without touching your own.

--

--

Christopher Ramm
Christopher Ramm

DCX CTO Germany @ Capgemini | Salesforce Certified Technical Architect | Salesforce MVP | cramm.dev