Every AI keynote shows the same demo. The assistant reads your inbox, pulls up the right document, joins your meeting, and reminds you what you promised someone last Tuesday. It looks like magic. Then you close the tab, go back to your real job, and none of it is real.
Think about what your job actually runs on. The decision you sent by email three weeks ago. The one slide that mattered in a sixty-slide deck. Who promised what in a meeting nobody wrote down. That pile is your real memory of the work, and it sits scattered across a dozen apps with no reason to talk to each other. People call that pile a second brain. Yours is useless to an AI that can't reach it.
The model isn't the problem. It's plenty smart already. The problem is that it's blind. It doesn't know your people, your projects, how your org is wired, or how you like things done. None of that is in the model. It's in everything you've already written down, and the model can't see a word of it. So I spent a few weekends on one question: if nobody is going to hand me the connector, how much of that demo could I build myself?
If you've watched one of those demos and wondered why nothing like it ever works at your actual job, that gap is the whole story here. The fix is one idea you can use on any AI project, whether or not you ever build a setup like mine.
The connector gap
The demos skip the boring part. That assistant works because someone wired it into a sandbox where the calendar, the mail, and the documents are one click away. You're watching the one example that was prepped to go smoothly, in an environment built to make it look effortless. Real work is messier than the rehearsal. Plenty of workplaces, for good reasons, won't hand a personal script the keys to your mailbox, and the convenient note-takers want to ship your meeting audio to someone else's cloud. So the moment you care where your data goes, the easy connectors fall away, and you're left with a model that can reason about anything you paste in and reach nothing on its own.
So you get a strange split. The intelligence is racing ahead and getting cheaper by the month. The plumbing that connects it to your real life is barely moving.
The bottleneck for useful AI is rarely the model. It's whether your data is somewhere the model can reach, and whether you know how to put it to work once it's there.
So I started building one
Rather than wait for a vendor to ship the connector, I tried building one myself. Not a clever agent. Not a magic prompt. A pipeline. It started as a weekend experiment and quietly turned into something I run most mornings.
Two tools do the heavy lifting, and both deserve a one-line introduction if they're new to you. Obsidian is a free note app where every note is a plain markdown file on your own disk, linked to the others. The folder that holds all of them is called a vault, and that vault is my second brain. If you'd rather not start from an empty folder, the vault template is on GitHub. Claude Code is Anthropic's AI assistant that runs in your terminal and can actually read and write files on your machine, which is what lets it run the vault instead of just chatting about it. If you've never touched it, I wrote a beginner's series on getting started with Claude Code.
The idea is simple. Everything from my work life flows into one folder Claude can read. Emails land there. Meeting transcripts land there. So do the documents I get sent and the half-formed notes I write to myself. Once the data sits somewhere the model can see, it can finally do the thing the keynote promised. The whole trick was getting it into the room.
Plain text matters more than it sounds. A file is the one format a human and an AI can both open, diff, and reason about without anything breaking, which is the same reason I edit this site's content as files instead of running raw SQL against production. No proprietary format, no lock-in. If every tool I use disappeared tomorrow, the Obsidian vault is still a folder of readable text.
One door in, sorted folders out
Everything enters through the same door and leaves sorted. The daily cycle is short:
- New emails, transcripts, documents, and quick notes all land in one
00-Inboxfolder. - Once a day, sometimes every second day when things are quiet, I run a single command. Claude reads the inbox and works out what each file is.
- It cleans each one up, pulls out the people, projects, and action items, and writes a proper note.
- The note goes to the folder it belongs in. The source leaves the inbox, which returns to empty.
The vault itself is a handful of numbered folders, each with one job:
| Folder | What lives there |
|---|---|
00-Inbox |
The landing zone. Every new file drops here first, then gets sorted out. |
01-Daily |
One note per day, topped with an AI-written morning briefing. |
03-Projects |
A file per project or workstream I'm tracking. |
04-People |
A file per person, created the first time they show up in my mail or a meeting. |
05-Interactions |
The processed meeting and email notes. The bulk of the vault. |
07-Areas |
Goals and dashboards, like a running list of open tasks. |
08-Reference |
Documents turned into markdown, so a slide deck becomes readable text. |
09-Archive |
Finished projects and past quarters, moved out of the way. |
Zoom into any one of those dots and you get a file like this. A project note the pipeline keeps current, where every name and decision is a link back out into the graph:
---
name: Self-Serve-Checkout
status: active
owner: "[[Ivan-Misic]]"
type: project
---
# Self-Serve-Checkout
## Key stakeholders
- [[Ivan-Misic]] (owner)
- [[Dana-Holt]] (sponsor)
- [[Marco-Ruiz]] (engineering)
## Open items
- [ ] [[Marco-Ruiz]] confirm the build is feature-complete [due:: 2026-05-16]
- [ ] [[Dana-Holt]] sign off on go/no-go criteria [due:: 2026-05-16]
## Decisions log
| Date | Decision | Owner | Status |
|-|-|-|-|
| 2026-05-15 | Target Monday, May 18 for go-live | [[Dana-Holt]] | confirmed |
The folders, the linking conventions, and the Claude Code skills that run them are the part I can hand over, and they're up on GitHub.
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2">
<path d="M9 19c-5 1.5-5-2.5-7-3m14 6v-3.87a3.37 3.37 0 0 0-.94-2.61c3.14-.35 6.44-1.54 6.44-7A5.44 5.44 0 0 0 20 4.77 5.07 5.07 0 0 0 19.91 1S18.73.65 16 2.48a13.38 13.38 0 0 0-7 0C6.27.65 5.09 1 5.09 1A5.07 5.07 0 0 0 5 4.77a5.44 5.44 0 0 0-1.5 3.78c0 5.42 3.3 6.61 6.44 7A3.37 3.37 0 0 0 9 18.13V22"></path>
</svg>
Claude + Obsidian vault template
PUBLIC REPO · CLONE OR DOWNLOAD ZIP
<a href="https://github.com/imisic/claude-obsidian-vault" rel="noopener">View on GitHub</a>
Getting data out of a locked box
Two sources were hard, and both for the same reason: the easy path was off the table.
For email, wiring straight into the mailbox API wasn't realistic, so I leaned on plumbing that was already there. A background workflow watches my mailbox and writes messages out as plain text files to Microsoft OneDrive. I don't pipe the whole firehose in: the export only fires on mail Outlook flags as important, my VIP senders plus the few I mark by hand, so what reaches the vault is already mail I've decided is worth keeping. OneDrive syncs that folder down to my laptop, and a scheduled task drops the files into my second brain's inbox every few minutes. That's the whole mechanism.
It felt like a downgrade until I realized plain text was the most reliable interface in the system. No tokens to refresh, no rate limits, no connection to drop at 2am. Each piece can fail on its own without taking the rest down. The fanciest part of the email path is a five-line script that tags messages I sent with a SENT- prefix, because the export leaves the From: field empty and that's the simplest way to tell which direction a mail went. The unglamorous fix kept winning.
Meetings were the other wall, and here I set myself a rule for the fun of it: capture them without handing the audio to someone else's cloud. Half the experiment was finding out whether that was even possible. It is. A small tray app records the call, transcribes it locally with speaker labels, and drops the text into the inbox. That audio never leaves the machine. On my card a one-hour meeting becomes a clean transcript in about six minutes, quicker on a stronger GPU and slower on a weak one, fast enough that the notes are waiting before the next call. The ones I don't catch that way go through a pocket recorder instead, and its audio does ride up to a cloud to get transcribed, the honest tradeoff for never losing a conversation I needed.
The output is just more text, dropped into the same inbox as everything else. One from a Friday morning, names changed:
MeetingSubject: New Feature Kickoff
MeetingDate: 2026-05-15T09:00:00
Attendees: Ivan, Dana Holt, Marco Ruiz
MeetingType: sync
[00:00:12] Dana-Holt: So the whole feature, end to end. Can we have it live Monday morning?
[00:01:47] Marco-Ruiz: Monday's a little tight, but yeah, should be fine.
[00:02:39] Ivan: Let's get that on the record.
That transcript is real in shape and, let's say, aspirational in content. Nobody has ever shipped a whole feature between a Friday kickoff and a Monday launch, and I've stopped expecting the meeting to admit it. The pipeline has no such hangups. It files the promise, links "live Monday morning" to Marco, and waits. A few Mondays later I can pull up the exact second optimism met a calendar. Remembering what everyone agreed to before they forget is one of the more useful things a setup like this does.
It's held together with tape in places. It's Windows-only because of how it grabs system audio, and it wants a decent GPU. But it runs every day, and the recordings stay mine.
What finally made it work wasn't a clever prompt. It was boring plumbing nobody bothers to demo.
The lesson worth stealing: don't pay a model to do a regex's job
If you take one thing from this, take this. My first version had the AI do everything: parse email headers, match names to people, score which messages mattered, group threads, spot duplicates. It worked, sort of. It was also slow, expensive, and weirdly inconsistent from one run to the next.
Then it clicked. A language model does not need to read a From: line. Parsing that line is string manipulation, and a small Python function does it perfectly, every time, for free. So I moved all the deterministic work into scripts and left the model only the part it's good at: reading a messy thread and telling me what matters.
| Let a script do it | Let the model do it |
|---|---|
| Parse headers, strip signatures | Read a messy thread and tell me what matters |
| Resolve names and emails to people | Pull the real action items out of the language |
| Score relevance by rules, dedupe | Judge whether a borderline message is a big deal |
| Write files, mask private details | Write the one-line summary I'll actually read |
The result was faster, cheaper, and steadier, because the unpredictable component only touches the unpredictable problem.
The rule that transfers to any AI project: hand the model the fuzzy, judgment-heavy part, and let plain code do everything else. Most "AI is too expensive" and "AI is too flaky" complaints are really that one mistake in disguise, paying a language model to do a regex's job.
The same idea splits the model's own work in two: a cheap model for volume, a smart one for judgment. The bulk work, like summarizing an email or a transcript, runs on a fast cheap model. The handful of jobs that need real judgment, like a weekly review or one-on-one prep, go to the strongest one. Most tokens run cheap, and the expensive brain only shows up when the writing has to be good, which keeps the daily cost around the price of a coffee.
There's a privacy dividend too, with an honest limit. Before the model reads an email, a script swaps email addresses, phone numbers, IPs, and anything else that scans as private in the body for tokens, and keeps the real values in a local map the AI never sees. It lowers what gets sent rather than removing it: the headers and the meeting transcripts still go through. The useful part is that the deterministic layer is also where I get to decide what the model is allowed to see in the first place.
I decide what it pays attention to
The system only does the work I point it at. I get far too much email to turn all of it into notes, and trying would only bury the handful of things that matter. So I don't process the whole inbox. I point the real work at what I actually need to walk into prepared: a one-on-one, the weekly meeting, a workshop, a project or a person I'm tracking. I control what goes in and what I ask for back. And whatever comes back has to be a scan layer, never a wall of text. The morning briefing takes two minutes to read, and every line links to the full note if I want to dig in. The notes point to people and projects, which point back. I'm not building a novel I'll never reread. I'm building an index I can skim, then drill into when something catches my eye.
Here is what lands in the daily note each morning, names changed. Two minutes to read, and every line is a link into the full note behind it:
# Friday, May 15
## Meetings today (1)
- New Feature Kickoff with [[Dana-Holt]] and [[Marco-Ruiz]]; agreed to target a Monday go-live. → [[2026-05-15-new-feature-kickoff|note]]
## Key emails
| | Topic | Summary | Source |
|-|-------|---------|--------|
| **!** | Launch checklist | [[Dana-Holt]] wants the go/no-go criteria locked before Monday; two items still open. | [[2026-05-15-email-launch-checklist|note]] |
## Decisions made
- Target Monday, May 18 for the feature go-live.
## Action items
**Mine**
- **!** Send the rollback plan to [[Marco-Ruiz]] before end of day → [[2026-05-15-new-feature-kickoff|Source]]
**Waiting on others**
- **!** [[Marco-Ruiz]] confirm the build is feature-complete → [[2026-05-15-new-feature-kickoff|Source]]
- **!** [[Dana-Holt]] sign off on the go/no-go criteria → [[2026-05-15-email-launch-checklist|Source]]
What this won't do
Let me be honest about what this is: a personal system, not a product. It took months of nights-and-weekends iteration, and it's tuned to exactly one person's job. The meeting recorder is Windows-only and needs an NVIDIA GPU. I'm not packaging that recorder up to hand out, at least not yet. It's an approach more than a product, and nothing in it is exotic enough to stop you building your own. Speaker identification is good with three or four voices and gets confused in a crowd. Drop the whole thing into your own role and you'd spend a while reshaping the rules before it fit.
None of that bothers me, because I wasn't trying to start a company. This was me testing how far one person could get with off-the-shelf parts. The answer was further than I expected, and now I've got a connector nobody was selling.
The moat was never the model
The vendors will close this gap. A year or two from now the official connectors will exist, the policies will catch up, and some of what I built will look quaint. I'm fine with that. The second brain is a folder of plain text, so when a better connector shows up I just point it at the same files and keep everything I've already gathered. Waiting would have meant another year of an AI that couldn't see my job, when the data problem was solvable right now with tools I already had.
That's the part worth carrying out of here, and it's bigger than my vault. The intelligence is already here, cheap and getting better on its own schedule. What's missing is almost always the pipe between that intelligence and your actual work. Build the pipe, even out of plain text files and a scheduled task, and you stop waiting for permission to have the thing from the demo.
I tinker with things like this for myself, the same way I built this site solo with Claude Code. The model was never the hard part. The plumbing was.
Where this goes next
This post is the overview. I'll take the individual pieces apart in follow-ups and link them here as they land:
-
Capture without an API: pulling email and calendar out of a corporate mailbox into the local
00-Inboxfolder, with Power Automate and a scheduled task. - Private transcription: how I turn meeting audio into text on my own GPU, with nothing uploaded.
- Script-first: why the deterministic work runs as plain Python and the model only does the part it's good at.
- The skills: how one command a day is wired together as Claude Code skills and rules.
Top comments (0)