# Notes are the hub. Agents do the legwork.

- Canonical: https://matheja.me/how-i-work/
- Site: Ben Matheja (https://matheja.me), llms.txt: https://matheja.me/llms.txt

How I work · PKM & AI

I keep one Markdown vault in Git, with a daily journal at its centre. AI agents read from it, work in small, reviewable steps, and write what they learn back. Here is the setup and why it looks the way it does.

![A forest track covered with fallen leaves, running between tall conifers towards the light.](https://matheja.me/assets/img/forest-path-2023-800.jpg)

_A forest track in winter. (Photo: Ben Matheja)_

## The loop

The loop

> **Diagram:** From capture to published note. Capture flows into the daily journal, the hub. The journal links into the PARA vault with OKF frontmatter. A main agent session plans from the vault and hands focused tasks to minions, which open merge requests. Results flow back into the journal; notes marked publish go to matheja.me after a deny-list check.

## One vault, in Git

Everything lives in a single Obsidian vault of plain Markdown, organised with PARA: projects, areas, resources, archive. It syncs through Git only. On the phone, an iOS Shortcut pulls when Obsidian opens and commits when it closes, so conflicts became rare instead of weekly.

I write in whichever language the thought arrives in. Roughly half the vault is German, half English, and that is fine for me and for the agents.

## The daily journal is the hub

Every day gets one note. It links to the projects I touched, the decisions I made and the notes that changed. Agents start their work there, so they see what I see. Anything worth keeping moves out into a permanent note, and the journal shrinks to a short index of the day.

## One TODO.md, run like GTD

Every task I have lives in a single `TODO.md` at the root of the vault, grouped by area: house, family, homelab, travel, taxes. There is no second list and no task app; I dropped Todoist when this one started to work. Each daily journal shows the open tasks through a Dataview query rather than a copy, so there is one list and many views of it.

The rules come from Getting Things Done, kept small. Everything is captured first, in the journal’s inbox, and then clarified into a next action. A task is one scannable line that says what to do and where to look, never how: anything that needs more than a sentence becomes a project note or a sub-bullet, and the checkbox links to it. Agents follow the same rules. They add tasks when they find work, tick them off when they finish it, and never leave a task buried in a journal.

What I do not do yet is the part GTD rests on: the weekly review. The journals are there and the list is there, but nobody sits down once a week to go through both, so stale tasks pile up and the [Now page](https://matheja.me/now/) lags behind. That is the next habit to build, with an agent preparing the review from the week’s journals and the list, and me doing the deciding.

## OKF and vk

The Open Knowledge Format gives every note a small, predictable frontmatter: type, status, tags, related notes. `okf` backfills it and checks it, so agents never have to guess what a note is. `vk` installs the same skills and templates into every vault for every agent I use, from one source.

## A main session and minions

One long-running Claude Code session acts as the lead. It reads the issue, plans, and hands each focused task to a minion: a fresh agent with its own worktree, one branch and one merge request. Minions report back in a file; the main session reviews, I merge. The rule that makes this work: a minion never merges, deploys or touches another minion’s branch.

A densely linked vault is great for thinking and expensive for agents: every link is a reason to read one more note. I keep agent context narrow on purpose.

## One MCP gateway for my agents

This is the part I am proudest of. An agent is only as useful as what it can reach, and the Model Context Protocol (MCP) is the standard way to hand tools to one. But one server per tool means one URL, one login and one config entry per tool and per agent. So I built a gateway: a small service of my own, about five hundred lines, that runs on my cluster and is deployed by Flux like everything else. In front it offers one endpoint and one login, [Authentik](https://goauthentik.io) over OAuth. An agent signs in once and sees every tool, sorted into groups. A client that should see only one group connects to that group’s own path.

> **Diagram:** How my AI agents reach the lab through one MCP gateway. Agents on top, one gateway, then the servers it fronts. Claude Code and OpenCode connect to the self-built MCP gateway, one endpoint behind one login, OAuth through Authentik. The gateway sorts what it offers into seven groups: photos, docs, music, ops, ai, google and network. Behind the groups sit eight MCP servers, each wrapping one service. Six are my own code: Immich MCP for Immich in the photos group, Paperless MCP for Paperless-ngx and Linkwarden MCP for Linkwarden in the docs group, Jellyfin MCP for Jellyfin in the music group, Observability MCP for Prometheus, Loki and Tempo in the ops group, and Vast MCP for Vast.ai GPU models in the ai group. The other two are upstream open source projects: Google Workspace MCP for Calendar and Contacts in the google group, which I run as it is, and UniFi MCP for the UniFi Network controller in the network group, which I imported into my own repository with a small patch.

_Agents on top, one gateway, seven groups, eight MCP servers. Solid chips are my own code, the dashed ones are upstream projects._

Behind the gateway sits a small fleet of MCP servers, each wrapping one tool and reachable only through the gateway:

MCP servers behind the gateway| Server | Wraps | What agents can do | Group |
| --- | --- | --- | --- |
| Immich MCP | Immich | search photos by meaning, browse albums and people, tag and organise | photos |
| Paperless MCP | Paperless-ngx | search, read, convert and tag documents | docs |
| Linkwarden MCP | Linkwarden | search, file and tag bookmarks | docs |
| Jellyfin MCP | Jellyfin | list and curate playlists | music |
| Observability MCP | Prometheus, Loki, Tempo | query metrics and logs, search traces, read alerts | ops |
| Vast MCP | Vast.ai | list, deploy and stop GPU models | ai |
| Google Workspace MCP | Google Calendar and Contacts | read and write events and contacts | google |
| UniFi MCP | UniFi Network | read the network, change selected parts after a preview | network |

Six of the eight are my own code, small Python services. Google Workspace MCP and UniFi MCP are upstream open source projects. I run Google Workspace MCP as it is; I imported UniFi MCP into my own repository with a small patch.

The payoff is that one session can cross tools that know nothing about each other: ask Prometheus why an alert fired and read the matching Loki logs, then file the fix as a bookmark. The tools stay where they are, and the gateway holds no data of its own beyond login registrations.

Why self-built? The off-the-shelf gateway I tried first came with hundreds of settings, dozens of database tables and three containers for a feature set I would use five percent of. A small gateway that is the only trust boundary, with every server behind it, is easier to reason about. The lab behind it is described in [The Tools Behind My Homelab](https://matheja.me/2026/10/09/what-i-host-in-my-homelab.html).

## My setup

Tools I use every day| Tool | Role | Why this one |
| --- | --- | --- |
| Obsidian | Writing and linking | Plain Markdown on disk, nothing locked in |
| Git | Sync and history | Works on every device, every change reviewable |
| Claude Code | Main session and minions | Strong at planning, good at long tasks |
| MCP gateway | Agent access to the lab | One endpoint, behind SSO |
| okf, vk | Vault hygiene and shared skills | Written by me, for exactly this |