Obsidian is the human interface to my agentic system

The default failure mode of any autonomous agent is the blocking question. It gets three-quarters through a job, hits a fork it can't decide alone, and stalls — waiting on a human who is standing in a grocery store. The whole promise of autonomy leaks out of that one gap. My design goal was to close it: let an agent ask, let it keep moving on other work if it can, and let me answer whenever I next glance at my phone.

The vault is the operator-facing surface of the whole command center — the one place I look, whether I'm at the desk or standing in line somewhere.

Obsidian earns that role for a dull reason: it is already on my phone, already synced, and already the thing I open when I want to think. Putting the agent I/O inside the tool I already live in means there is no separate app to check, no notification I learn to ignore.

This is the mechanism I am proudest of, and it is almost entirely about discipline in who is allowed to write what. When an agent needs a decision, it calls a skill that posts the question to an obsidian_queue Django app. That app stores it as a QueueItem with a status that walks through three states: pending → ready → archived.

The rule that makes this safe is single-writer-per-direction. The agent writes only the question. I write only the answer. Neither side ever edits the other's field, so there is no race, no clobber, no "who won." The status is the handshake. When I tick the box, the direction of ownership flips cleanly from me back to the machine.

The part that still slightly delights me is the "any thread, any machine" bit. The agent that asked the question does not have to be the one that reads the answer. The answer lives in the queue, keyed by the item — so a fresh session, on a different laptop, days later, can pick up a decision I made from a parking lot.

People assume a developer's vault must be a git repo. Mine is not the transport for this. Phone-to-laptop is Obsidian Sync — the paid first-party service — because it is the thing that reliably works from a phone with no terminal. The laptop-to-API leg is macOS launchd. That is deliberate, and the two triggers matter:

# the launchd job that watches the inbox — two triggers
WatchPaths  = 00_COMMAND_CENTER/_Claude/inbox   # fire the instant a file changes
StartInterval = 600                             # and a 10-min backstop timer

# the WatchPaths trigger catches answers the moment I tick DONE.
# the timer catches answers that landed while the laptop was asleep —
# the phone synced them up, but no file event fired on this machine.

The WatchPaths trigger gives me near-instant round-trips when the laptop is awake. The 10-minute StartInterval is the backstop: if I answer at midnight while the laptop is closed, Obsidian Sync still moves the file to the phone and back, but no filesystem event fires on the sleeping Mac. When it wakes, the timer sweeps the inbox and finds the answer waiting. Git would have added a commit-and-push step that a phone cannot reliably perform. This is boring on purpose.

Here is a small thing that solves a genuinely annoying problem. When an agent wants me to run a shell command myself, it does not just print it in the chat. It writes it to ~/PAD/autonomous_aj/commands/ as a Markdown file, one command per fenced code block. The reason is purely mechanical: copying a multi-line command out of a terminal chat window mangles the line breaks. You paste it and the continuations have folded into one line, or a blank line has become a premature enter. The vault file is the clean copy source — I open it in Obsidian, hit the copy button on the fence, and paste something that actually runs.

It is not glamorous. It is the kind of friction that quietly costs you a minute and a swear word every time, and removing it is worth more than it sounds.

A vault that everything writes into will fill with stale, duplicate, and contradictory notes. So a scheduled gardener scans the vault, scores it for hygiene, and proposes prunes — the notes that have gone stale, the ones that duplicate each other, the ones that now contradict something newer. It proposes; it does not silently delete.

The detail I like is the dead-man switch. The gardener posts a heartbeat every time it runs, and a separate monitor watches for that heartbeat. If the gardener stops running — crashed, mis-scheduled, quietly dead — the missing heartbeat trips the monitor and I get alerted. A janitor you forget about is a janitor that stopped working weeks ago and never told you. This one has to keep proving it is alive.

Two more uses close the loop, and both are about not losing the good stuff in a scrollback buffer.

First, cross-thread handoff. A next_thread.md file in the vault is where one session leaves the next one its context — what was in flight, what to pick up, what not to touch. A chat session ends and its working memory evaporates; the handoff file is where it deposits what the next session needs before it goes.

Second, reports to the vault. My strategy work — the adversarial "spar" reviews that stress-test a plan before I commit to it, the audits, the SEO triage passes — writes its output into the vault. The point is that the durable thinking ends up in my second brain, structured and searchable and phone-synced, instead of trapped in a chat log I will never scroll back to. The vault is PARA-structured, so a report lands somewhere I will actually find it again.

The thing I want you to take from this is not "use Obsidian." It is that a fleet of agents needs a human interface, and the interface should meet the human where they already are — not force them into a new dashboard that becomes another tab to ignore. My agents reach me through the app I already open to think, using a protocol as dumb as a checkbox. The intelligence is in the fleet. The interface is a Markdown file and a ticked box, synced to my phone. That asymmetry is the whole point: the machine can be as sophisticated as it likes, as long as the part that touches me stays something I can do one-handed in a checkout line.