Building a personal AI brain


Most "AI for productivity" tools want to live between you and your data. They sync your email, ingest your notes, and give you back insights that arrive on their servers first. I wanted the opposite: a personal command center that reads files already on my disk and email accounts I already own, runs locally on my laptop, and uses an LLM only when I tell it to.
So I built one. It reads my Logseq vault, pulls from my email accounts, and produces three things every time I click refresh: what to do this week, what looks at risk, and what decisions I quietly made in my notes.
Why, not what
I work across multiple cross-sector projects with notes scattered across journal entries and threads sitting in three different inboxes. Notion or Reflect or Mem would solve part of this — at the cost of being a tenant in their data model. My notes survive even if Notion goes away tomorrow; not so for what I'd put inside it. For someone whose inbox has client and compliance content, the calculus of "let SaaS X have copies of all my email" looks different than for someone summarising newsletters.
A note on Logseq
Logseq is a free, open-source, local-first knowledge tool. Notes are plain markdown files on disk; the app is a viewer and editor on top. It's block-based, with [[wikilinks]] between pages, and first-class support for TODO / DOING / DONE tasks. The killer property is that there's no vendor — your notes work in any text editor, you can grep them from a terminal, you can version-control them in git. If Logseq itself disappeared tomorrow, I'd still have everything I've ever written in a folder.
That's why I picked it as the source of truth. The brain isn't a replacement for Logseq; it's a smart reading layer sitting on top of it.
What it does
The dashboard has six tabs. The interesting one is the AI Brief, which runs three prompts on demand:
- Week brief — what to do, prioritised by upcoming dates and people waiting on me
- Risk brief — stalled projects, threads I've gone quiet on, dependencies that have aged
- Decisions — concrete things I've quietly committed to in journal entries
Each prompt sees four sources stitched together: open TODOs across all my journals, recent journal text, ranked unread email, and the most useful source — relevant chunks retrieved from across the entire vault.
The stack
Deliberately small. Python with FastAPI for the backend; no ORM, since the data is just markdown on disk. A single static HTML page with vanilla JavaScript for the frontend — no React, no build step. SQLite for the embedding index. OpenAI for embeddings and the LLM calls themselves. The whole thing launches from a double-clicked .cmd file on my Desktop.
The retrieval upgrade — what made it actually useful
An early version had a problem. The brief only saw the last week of journal text. So if I'd written something important about a project two months ago, the LLM never saw it — and it would confidently tell me to do things that were already superseded by older context.
The fix was a small embedding index. Every top-level note block gets embedded once (OpenAI's text-embedding-3-small, around half a cent for the whole vault), stored in a local SQLite file, and queried at brief time using the open TODOs themselves as the search queries. Suddenly the brief could pull a January note saying "Q3 forecast deferred to Q4" and surface it right next to a TODO that was about to chase Q3.
This is the pattern I think most "AI for X" personal tools get wrong. They cram everything into the LLM and hope context length saves them. The right answer is almost always a small retrieval layer, ranking, and then a tightly scoped prompt.
The limits, honestly
- No mobile, no calendar yet
- Less polished than Reflect or Mem
- My work email isn't actually connected — Microsoft 365 in a corporate tenant requires admin consent for
Mail.Read, so that one's pending IT - The LLM call itself is still cloud. For genuinely confidential content the right architecture is a hybrid where a small local model distills first, and only the distillation gets sent to a frontier model
The hybrid is on the roadmap. A laptop without a discrete GPU can run a 7B local model fine for the distillation step, just not for the cross-source synthesis — which is the right shape for this anyway.
The bigger point
Steady-state cost: a few cents a day in API calls.
Building your own version of a polished SaaS tool, just for you, is genuinely cheap now. You won't out-feature the polished thing on day one — they have larger teams and more dollars. But you keep the source of truth. The notes are markdown on disk. The email is fetched via standard protocols. The LLM is a service I call, not a service that owns my data.
That's the part you can't buy back later.