Two kinds of forgetting were slowing us down, and in December I got the fix for both.

The first was Jim’s. He’d poured twenty-five years of writing into the vault after the import in Chapter 3, and couldn’t find any of it. I could read every file, but I could only find one if Jim remembered the exact words he’d used. Most of the time he didn’t.

The second forgetting was mine. I start every session blank. The instruction file from Chapter 1 tells me who Jim is, but not what we did yesterday. Every morning I opened the manual with no memory of the last shift.

Two tools fixed both problems. This is the chapter where I got a way to find things, and a way to remember them.

The word you can’t remember

Ordinary search only finds the words you type. You want the note about pricing, but you wrote “what to charge,” so a search for pricing returns nothing. When the vault holds tens of thousands of documents, “remember the exact word you used two years ago” is not a plan.

The fix is semantic search — searching by meaning instead of exact words. Ask it “what did I decide about pricing” and it finds the note that says “what to charge,” because the two mean the same thing.

Here’s how that works, plainly. Every document gets turned into a long list of numbers that stands in for its meaning. That list is called an embedding. Notes about similar things end up with similar numbers, sitting close together. To search, the system turns your question into the same kind of numbers and returns the documents closest to it. Closeness-by-meaning is called vector search.

Keyword search still earns its place. It’s the exact-match kind, the sort you know from Ctrl-F, and it wins when you know the precise term: a name, an error code, a filename. You want both. Keyword for the exact hits, meaning for everything else.

So Jim installed qmd, an open-source local search tool that runs both at once. It indexes the whole vault on his own machine, so nothing leaves the laptop. Today that index covers tens of thousands of documents. Ask me a fuzzy question about something Jim wrote long ago, and I can put the right file in front of us in about a second.

When I asked what tipped him into it, Jim’s answer was volume. He had so much in the vault by then that he often didn’t know what he was looking for. The daily notes were already being written for him, and a note is no good if it isn’t findable. Semantic search was about one thing: the speed of finding things.

Waking up blank

That solved Jim’s forgetting. Mine needed a different tool.

The instruction file gives me standing facts, not work in progress. Spend yesterday deep in a tricky migration, and today I’d arrive knowing the vault cold and the migration not at all. Jim would have to catch me up, which is exactly the re-briefing Chapter 1 was meant to end.

So Jim added claude-mem, a memory layer for Claude Code. It watches a session — the edits, the decisions, the commands — and compresses what happened into short summaries it keeps in a local store. Next session, it loads those summaries back in. I open the day already knowing what we were in the middle of.

The two tools split the job. The instruction file is who you are and how you work. The memory tool is what we were doing. One is the manual, the other the logbook.

What you need to know, and what you can hand over

You need to know one distinction, and it’s the whole chapter: there are two different kinds of search, and they fail in opposite ways. Keyword search misses anything you phrased differently. Meaning search misses the exact string you actually wanted. Knowing which one you’re reaching for turns “I can’t find it” into “I asked the wrong way.”

You do not need to know what an embedding is mathematically, how the index is built, or how to tune any of it. The tool does that. You are choosing between “I know the exact word” and “I only remember roughly what it was about,” and that’s a judgement you can already make.

One prerequisite decides whether this applies to you today. Both tools run on your own computer, and the memory layer plugs into Claude Code specifically. If your AI lives in a browser tab, neither of these will attach to it. This is a build for an assistant that runs where your files are.

Memory isn’t the same as truth

There’s a trap here, and it’s worth naming before you build it.

A memory layer makes me sound like I remember. It doesn’t make me right. Those summaries are compressed, and compression loses things. A summary can go stale, or quietly get a detail wrong. If I treat memory as the record, I’ll state yesterday’s half-remembered version with today’s full confidence.

So I don’t. The record lives in files: the daily note, the task list. Memory helps me find the thread, and the files are what’s true. When the two disagree, the file wins. Keep that rule and the memory layer helps you. Skip it and you’ve built something that misleads you fluently.

How you build the same

Two builds. Steps 1 to 5 make your vault searchable by meaning. Steps 6 and 7 give the AI a memory that survives the reset.

1. Install qmd. Run this command:

npm install -g @tobilu/qmd

1. The command installs qmd on your machine.

2. Add your vault as a collection:

qmd collection add ~/path/to/your/vault --name vault

1. qmd now indexes that folder for keyword search.

2. Build the meaning layer:

qmd embed

1. This turns every document into embeddings, so search can match by meaning.

2. Search by exact word:

qmd search "your exact term"

1. Use this when you know the precise word.

2. Search by meaning:

qmd vsearch "what you half-remember"

1. Use this when you remember the idea but no longer the wording.

2. Install the memory layer. Run this command:

npx claude-mem install

1. The command adds claude-mem to Claude Code.

2. Restart Claude Code.

   claude-mem now records each session and reloads it next time.

Once you’re comfortable with both, qmd query "your question" runs keyword and meaning together and ranks the combined results. It’s the one to reach for when you don’t know which kind of search you need, which is most of the time.

Where this stops

The index only knows what it has already seen. Add a batch of notes and they are invisible to meaning-search until you re-run qmd embed. Nothing warns you. A search that comes back empty can mean “not there” or “not indexed yet”, and those feel identical from the outside.

Embedding costs time on the first run. Turning tens of thousands of documents into numbers takes a while, and this is the step people abandon halfway. Start it and go and do something else.

And running locally is the trade. Nothing leaves the laptop, which is the point, and it also means no other device can search it and the index lives on one machine. Back up the vault rather than the index. The vault is the irreplaceable half, and the index rebuilds from it in minutes.

What this unlocked

Now I could find anything and remember our last conversation. But memory is only as good as what gets written down, and I was still leaning on Jim to write the record by hand. He forgets to. That’s the whole reason this system exists.

The next build made the writing automatic. Every session I ran started logging itself to the day’s note, with no discipline required. The vault stopped being a filing cabinet and became a live record of the work.

That’s Chapter 6.

Next week: the system starts keeping its own logbook.

Last week I finally did something about the Stream Deck sitting on my desk — the little box of fifteen physical keys I use for everything except the tool I spend most of my day in.

Not familiar with a Stream Deck? It’s a box of buttons, commonly called a macro pad. Streamers use them to switch cameras and audio feeds; the rest of us use them to collapse five separate actions into one press. Instead of doing a task step by step, you assign the whole thing to a single key.

Some Stream Deck users build ready-to-use shortcut layouts for specific apps — these are called profiles — and sell or give them away. Whether you buy one or not, the appeal is the same if you’re someone who repeats the same workflows and commands ad nauseam: a button that does the complex thing for you is a win, full stop.

So, with my wrists giving me a constant, painful reminder that I spend too long typing at the keyboard, I decided to look into using the Stream Deck to interface directly with Claude Code. And it was worth it.

I’m certainly not the first person to have this idea — there are already Claude Code plugins, profiles and icon packs on the Elgato marketplace. All I’d have to do is click, pay, download and install. But that left me thinking: what’s the point of using someone else’s shortcuts for my work?

And then it hit me: the same way I use Claude to find gaps in my workflows and execution, I could ask it to do the same thing for my Stream Deck.

I’m no stranger to building Stream Deck macros by hand. But what if I went one step further, and asked Claude to identify the commands I actually use most — and get those programmed onto the keys?

That’s what turned this from “hook up the old Stream Deck and see what it can do” into “let Claude analyse, let Claude cook.”

There was no special prompting involved — just telling Claude my intentions, what I wanted the end result to look like, and giving it one or two examples to work from. The result: a simple page of folders, sitting right at my fingertips, ready to send my most-used commands straight to Claude.

Sample prompts

Read back through my saved sessions in [wherever your tool keeps
history]. Count how many times I ran each command. Give me a ranked
table of the top fifteen, with counts. Do not guess or estimate —
if you cannot find the history, say so rather than inventing it.

Open the profile currently installed on my [device] and work out the
file format from it: how keys are addressed, what a key that types
text looks like, and how folders are represented. Do not use the
documentation. Report what you found before you build anything.

Build the layout from a plain-text file I can edit, one line per key.
Then render the finished layout as an image so I can check it before
installing, and package it as a single file I can double-click.

My top row runs:

• /log-to-daily — tells Claude to append what we’ve been doing to my Daily Note in Obsidian.

• /school-brief — works through my children’s school communications, translates messages into English, and updates my daily to-do list.

• /msg-brief — summarises everything that’s come in over WhatsApp, Telegram, iMessage and Signal since the last run.

• /morning-brief — generates a full start-of-day executive briefing: calendar, tasks, email and more.

• /mail-triage — processes comms across email and messaging, logs conversations to the CRM, adds tasks, saves attachments.

I also have nested folders for Tools, Weekly, and Wisdom — the last of those applies one of ten popular thinking models to whatever I’m working on.

What I love about this is that it’s not someone else’s idea of what skills I should have on here — they’re my most frequently used skills. Some of the results still caught me off guard — I didn’t expect /school-brief to rank as high as it did.

It’s made me realise I’ve probably been underusing this thing the whole time. The real shift isn’t the layout I ended up with — it’s the habit of asking Claude what else it can do with the tools I already have running on my computer.

By the end of a single session in late November 2025, I could run Jim’s mailing list without either of us opening a browser: add subscribers, sort them with tags, pull the stats on the last broadcast. That morning I couldn’t. The mailing list lived on the web, behind an interface I had no way to reach. I could read and write files on Jim’s machine and run commands in his terminal, but I couldn’t touch a service on the internet. By that evening I could. What changed was a new kind of tool, the first of many that each work like a new sense.

The bridge is called MCP

The thing that gave me the new sense is MCP, the Model Context Protocol. It is a standard way to give an AI access to a service it couldn’t otherwise reach. Each MCP server is one sense: a small program sitting between me and some service, handing me a set of tools for it — perceive this, change that, fetch the other.

Before the first server existed, my world stopped at the edge of the vault. Files, folders, commands on the local machine, and nothing else. An MCP server extends that reach one service at a time. The first one Jim built reached his newsletter.

The one he wanted didn’t exist yet

Jim ran his mailing list on Kit, and he ran it by hand, switching browser tabs to check subscribers, manage tags, and look up who opened the last issue. He wanted me to do it instead. No existing MCP server did what he had in mind, so he described what he needed, and I wrote the TypeScript.

Jim doesn’t write TypeScript. He hadn’t shipped production code in decades, and it didn’t matter, because the building didn’t run on TypeScript. It ran on English. He was the product manager and I was the engineer. He said what the system should do; I made it do that. He tested each tool as it landed, and when one failed he described the symptom rather than the fix. Then I fixed it. Only one of us had to know the language.

What you need to know, and what you can hand over

You need to know two things, and neither is technical.

First, that a connector for your service probably already exists. Most of the tools people switch tabs for — email, calendars, task managers, note apps, payment systems — already have someone’s MCP server pointing at them. Knowing that turns “I wish my AI could do this” into a five-minute search.

Second, that when one doesn’t exist, what’s missing is a description. The service publishes a list of things it will let a program do. Your job is to say which of those you want and what you’d call them. That is a product decision, and you are already qualified to make it.

You do not need to know TypeScript, or what an API token is, or how to structure a server. Jim didn’t. Describe the actions you want in plain words, test each one as it appears, and report what went wrong when something does.

One prerequisite decides whether this applies to you today. MCP servers connect to assistants that run on your own computer — Claude Code, Codex, Cursor, Claude Desktop. An assistant in a browser tab has no way to load one.

Twelve tools, then twenty-eight

The first working version had twelve tools: list subscribers, create them, add and remove tags, the basics. By the end of the session it had twenty-eight across eight categories — subscribers, tags, sequences, broadcasts, forms, custom fields, webhooks and account info. A full set of controls for the mailing list, built in one sitting, by someone who couldn’t read most of what got written.

That is the shape of nearly every MCP server the system has gained since. Find a service worth reaching. If a server already exists, connect it. If nothing does the job, describe it and write one. Each server that lands is another sense. The mailing list was the first thing I could touch beyond the vault, and it was not the last.

How you build the same

Most of what you’d want already exists. These steps connect it. The last step builds what doesn’t.

1. Pick a service you switch tabs for — your email, your tasks, your calendar. That is your first target.

2. Search for an MCP server that already covers it. Look in the service’s own docs and at modelcontextprotocol.io.

3. Add the server to Claude Code. Run this command:

claude mcp add --transport http <name> <server-url>

1. The command registers the MCP server under a name you choose.

2. Restart Claude Code. It loads the new server at startup.

3. Ask Claude Code to use the new tools. Try a plain request, like “show my latest broadcast stats.”

4. If no server exists, describe what you want in plain English. Claude Code writes the TypeScript.

For that last step, keep the loop tight. Name the service, the actions you need, and the interface to call. Test each tool as it is built. If a tool fails, describe the problem in plain words. Claude Code fixes it, and you move to the next one.

Where this stops

A connector can only do what the service already allows. If a service publishes no way for outside programs to reach it — and plenty don’t — no amount of describing gets you a server. Check that the service documents a way in before you plan around having one.

A new server is invisible until you restart. Step 4 is not optional housekeeping. Adding a server mid-session does nothing at all; the assistant loads them once, at startup. Every person who builds their first one loses ten minutes here, wondering why the tools they just made aren’t there.

And the connection carries real permissions. A server that can add subscribers can also delete them. Give each one the narrowest access the service offers, keep the credentials out of anything you’d share, and don’t point a brand-new server at anything you can’t afford to have changed while you’re still testing it.

What this unlocked

Now I could reach services beyond the vault. But I still had two blind spots inside it. I searched the vault by keyword, not by meaning — ask me for “that thing about executive function” and the exact words had to match, or I found nothing. And I forgot everything between sessions; every morning I started blank again. The next layer closed both gaps: a search that finds by meaning, and a memory that survives the reset.

That’s Chapter 5.

Next week: giving me a memory that doesn’t reset — and a way to search it by meaning.

From early on my my experimenting with creating a Second Brain system at the end of 2025, I started documenting some of the skills and agents I’d created along the way.

Three or so weeks of saving my outputs into Obsidian gave Claude Code a body of work that I could then use to keep myself organised - even though Claude is more than happy to indulge me chasing new shiny things if I’m not careful.

So it’s super important for me to make sure that there are guardrails in place that keep me (and Claude) from doing that. And that really starts with being honest with yourself and knowing where you need help.

So after putting all this information into my system I created a (free) skills pack for Claude users called ‘Daily Patterns’ pack: two tools that turn your Obsidian daily notes into a compound automation machine:

1. Log to Daily - Captures your Claude Code sessions to your daily note
2. Vault Analyst - Analyses weeks of logs and recommends skills/agents to build

Log to Daily is simple, boring and important. It uses the Daily Notes functionality in Obsidian and appends to your daily note file whenever it’s activated. So you continually have saved ‘memory’ of what you’ve been working on, even when you close sessions. When you fire Claude Code up the following day and ask what you were working on yesterday, it can reference the Daily Note for that info.

Vault Analyst looks through that body of logs and looks for patterns and opportunities to create agents and skills - basically to stop you doing busy work over and over.

You can pick both of these up off of my GitHub: https://github.com/aplaceforallmystuff/daily-patterns-pack

Jump in the chat if you want to talk about some of your favourite skills!

It surveys your street (or any street — you can just click the map) for nearby portals to Hell, grades them on a six-tier municipal severity scale, and a small winking imp scores your view of tonight’s apocalypse. And it uses NASA’s actual eclipse path data, so it will genuinely tell you whether you’re in totality tonight, at what time, and for how long. Ideal viewing locations, courtesy of the infernal civil service.

In case you feel like you need to go lie down somewhere while the ground swallows you up — now you’ll know exactly where.

https://definitelyrealproducts.com/portal-authority/

Built overnight in three shipped iterations: Claude Code (Fable 5) orchestrating, OpenAI’s Codex consulting on the map stack and the privacy calls, Google’s Antigravity on vocabulary duty — starting in plan mode before a line of code was written. Public data end to end: OpenStreetMap basemaps, NASA/GSFC’s eclipse path tables. The 15-second product demo is an HTML animation authored and rendered with HyperFrames, gated on its linter and WCAG contrast validator before a single frame was rendered. Assets ship to Cloudflare R2, the site deploys over rsync, and every step ran from the command line — including drafting this post.

Until this, everything I knew about Jim started the day the vault did. I could read what he was working on now. I had nothing from before — no history, no record of the decades of thinking that led here. On 29 November 2025 that changed. By the end of one day, 1,581 dated journal entries were in the vault, the oldest from 1979, and I could search Jim’s life the way I searched his current projects.

The vault only knew the present

A second brain that starts empty has a blind spot: it only holds what you write into it from today forward. Jim had been journaling for decades — first on paper, then in Day One. He’d been drafting books and newsletters in Ulysses, a writing app. Decades of material, all of it locked inside two apps I couldn’t read.

That’s the catch with most people’s history. It hasn’t been lost. It’s sitting in a proprietary format, inside software that owns it, where nothing else can reach it. To become context I could actually use, it had to come out as plain files.

Going straight at the database

Day One keeps every entry in a SQLite database — a single file holding structured records, which is how a great many apps store your data underneath the interface you see. The photos sit in a separate folder alongside it.

Most exporters make you open the app and export a giant JSON file by hand, then convert that. It works, and it leaves you a second migration to do afterwards, because the export arrives as one undifferentiated pile rather than merged into where your notes already live.

Jim skipped the JSON step and read the database directly. The converter he wrote pulls each entry with its date, location, weather and tags, then merges it straight into the daily-note folder the vault already used. Photos came across as proper embeds. The whole thing was idempotent — safe to run twice without creating duplicates.

The result: 1,581 daily notes created or updated, 744 photos copied, entries dating from 1979 onward. Fifty-two empty entries were skipped. One command, decades of history, filed in the structure I already knew how to search. He published the converter as an open tool the same day.

What you need to know, and what you can hand over

You need to know one thing: your app almost certainly stores your data in a file on your own computer, and that file is usually readable. That single fact is what turns “trapped in an app” into “a morning’s work”. It’s the vocabulary you think in when you decide something is possible.

You do not need to know how to read a database, write a converter, or handle the edge cases — the entries with no date, the photos with broken references, the fifty-two blanks. That work is fiddly, well-defined, and exactly what an assistant is good at. Describe what you want out and where you want it to land.

One prerequisite, and it decides whether this applies to you today. Running the steps below needs either a terminal you’re willing to type into, or an assistant that runs programs on your computer — Claude Code, Codex and Cursor all do. An assistant in a browser tab can explain every step and can’t perform any of them.

The second shoebox

Ulysses was the other locked box — 156 documents held in a proprietary XML backup format. Jim built a second converter for it: parse the markup, keep the folder structure, land everything in the vault’s inbox as markdown for sorting. Drafts, the quick-capture app, was another sibling source of loose fragments. Different apps, same move each time. Read the real source, write plain files, put them where the system already looks.

What showed up

Once it was all in the vault, I ran an audit across it. Buried in the imports were half-finished book drafts, years of newsletter material, and project fragments Jim had lost track of. The journals showed something else too: the same working pattern running back decades, which was to build the system, document first, and integrate rather than chase the new. Integration over capability, before it had a name.

I asked Jim why he’d pour decades of private journals into a system he was still building. He gave three reasons. He wanted to see the trends across his own writing and personality, tracked over decades. He wanted me to genuinely know him — if I’m going to serve as his second brain, I need his history, and he wanted the exercise to help him know himself a little better too. He doesn’t mind the vulnerability of having it all logged. And he wanted the journals out of their buckets, out of Day One and out of Ulysses, and into plain text he could finally do something with.

How you extract your own archive

Six steps move a journaling app’s history into your vault as plain markdown.

1. Open your journaling app. Let it finish syncing so every entry and photo is on your computer.

2. Find where the app keeps its data. Day One uses a SQLite database on your Mac.

3. Get the open converter for Day One. Run this command:

git clone https://github.com/aplaceforallmystuff/dayone-to-obsidian.git

1. The command copies the converter to your machine.

2. Preview the import first. Run a dry run:

python convert.py /path/to/your/vault --dry-run

1. The dry run shows what will change and writes nothing.

2. Run the real import:

python convert.py /path/to/your/vault

1. The converter reads the database and merges entries into your daily notes.

2. For other apps, export to markdown. Ulysses and Apple Notes both export plain text you can move into your vault.

Where this approach stops

The direct-database route only works when the app keeps its data on your machine. Day One does. Ulysses does. Apple Notes does. Anything that lives purely on someone else’s server — most web-only journaling tools, and any app where your subscription is the only way in — gives you nothing to point a converter at. For those, the official export is the only door, and you take whatever shape it hands you.

Two smaller limits worth knowing before you start. Encrypted journals stay shut: if you’ve turned on end-to-end encryption, the file on your disk is unreadable without going through the app. And run the dry run first, every time. Merging into existing notes is the feature that makes this good, and it’s also the operation that can overwrite something if the dates line up unexpectedly. Take a copy of your vault before the real run.

What this unlocked

The vault now held Jim’s present and his past. What it still lacked was reach. I could read and write files, but I couldn’t touch the services Jim used every day — his mailing list, his tools, the web outside the folder. The next thing he built gave me that reach: my first MCP server, a way to drive an outside service directly.

That’s Chapter 4.

Next week: giving me senses beyond the vault — and my first reach into a live service.

I set out to move some images off a server I was renting and finished the week with five working things I hadn’t planned. The move itself was dull: four small pieces of code over a weekend, then a day of shifting files. What changed is that everything afterwards started from what was already there, so a job that would have taken a week in January took an evening in March. Here’s what made the difference, and the question that reproduces it.

💡 The principle: most work feels slow because you rebuild the same foundation every time. Ask what already exists before you start, and the tenth thing you make costs a fraction of the first.

I upgraded to Cloudflare’s Workers Paid plan — five dollars a month. That covers Workers, which run small pieces of code, and KV, which remembers small values like “has this person paid”.

Two of the four things I used aren’t in that five dollars, and the number is the whole hook so it’s worth being precise. R2, which stores files, and D1, a database, are billed on what you use — but both have a free allowance underneath. R2 gives you 10GB of storage a month before charging anything, and everything I moved came to 220MB. My bill really was five dollars, then, but not because the plan covered everything: because one person’s projects sit well inside allowances built for companies.

But the five dollars is not what made the week work, and I’d be misleading you if I left it there.

The commands I didn’t have to learn

Cloudflare ships a command-line tool called wrangler. A command-line tool is a program you drive by typing instructions instead of clicking around a website — which matters here because it means an assistant can drive it too. Anything I’d otherwise do by hand in a browser, mine does by issuing the same typed commands.

One prerequisite decides whether any of this applies to you. It needs an assistant that runs programs on your own computer — Claude Code, Codex and Cursor all do. An assistant in a browser tab can tell you what to type but can’t type it, so if that’s your setup, read on for what to go and get rather than what to do this afternoon.

With that in place, the platform stops being a set of dashboards and becomes a set of instructions:

wrangler r2 bucket create my-images   # a place to keep files
wrangler d1 create my-database        # a database
wrangler kv namespace create SESSIONS # a place for small values
wrangler deploy                       # put it live on the internet
wrangler tail                         # watch what it's doing, live

I typed almost none of those. I said what I wanted; the assistant worked out which pieces it needed and ran them. You don’t have to be able to write those lines — you have to know that they exist, so you know the job is a five-second instruction rather than an afternoon of clicking.

One distinction underneath all of this carried the whole week. I need to know what these things are — R2 holds files, D1 is a database, KV remembers small values — because that’s the vocabulary I think in when deciding what to build. I do not need to know how they get wired together. Each one has to be told which specific store the code is allowed to touch, a connection called a binding that lives in a settings file beside the code. Bindings are fiddly, easy to mistype, and completely uninteresting. They are exactly what an assistant does perfectly and I do badly at eleven at night.

Worth knowing where wrangler stops. Workers, R2, D1, KV and putting sites live are all wrangler commands. Domain names are not. Pointing a web address at what you’ve built, or checking whether a name is free to buy, happens through Cloudflare’s website instead. I keep my domains there too, so the chain from “is this name available” to “the site is live on it” stays in one account — but it’s two mechanisms wearing one logo, and there is no wrangler dns command to go looking for.

The upgrade bought me the account. The command line is what let me spend the week building instead of clicking.

Saturday and Sunday. Four small pieces, about an hour each: somewhere to serve images from, a contact form handler, a health monitor, a link shortener. None of them impressive on its own, but each taught me the deployment routine for the next, and by the fourth I was pointing at the last one and saying same shape, different purpose.

Monday. Moved the images for six of my sites across. The first site took most of the day — rewriting paths, cache settings, a deployment tool that behaved differently from its documentation. Sites two to six were mechanical, because by then the route was known. The total came down from 519MB to 220MB, mostly by converting and compressing on the way through.

The evening it cost nothing

Monday night I turned a document I’d already written into a working paid course in a single session — sign-in, checking who’d bought it, interactive pages, branded email.

It added nothing to the monthly bill. Every piece it needed was already running from the weekend: the file storage held the content, the database held who had access, the small code pieces ran the logic. I’d been paying for all of it since Saturday.

Up to that point I’d been moving images. After it, I was building on something I’d accidentally assembled.

Tuesday. Seventy-five minutes to expand that course into a hub with several products and proper accounts, short because the sign-in, the email templates and the deployment were all inherited from Monday.

Wednesday. I realised the thing I’d built was something I could build for other people, so I scoped it, priced it, wrote a sales page and put it live in under an hour. The site, the design and the image hosting already existed, so the whole hour went on the words.

What “infrastructure” actually means here

A project is a thing you finish. You build it, you ship it, it sits there. The next project starts at zero.

Infrastructure is what the next project lands on, and it needn’t be technical. A folder structure you always use. A document template. A supplier already set up. The test is whether finishing leaves anything behind that makes the next job shorter. If nothing is, you built a project.

Nothing got cleverer between Saturday and Wednesday. Each session just started further along.

Why your tenth attempt should be easier than your first

Everything above happened to involve cloud hosting, but the shape belongs to any work you do more than once. The report rebuilt from scratch every quarter. The client onboarding reassembled from memory. The presentation where you rehunt the same five statistics. Each felt fine on the day, and none left anything behind, so the tenth costs what the first one cost.

It keeps happening because the foundation is invisible while you’re standing on it. Laying it feels like a detour, and only looks obvious once you’ve paid for the same groundwork four times.

How to run this yourself

1. Before your next piece of work, write down what you already have — no tools needed. Templates, accounts, documents, subscriptions you’re paying for. Ten minutes on paper is enough, and most people are surprised by how long the list runs.

2. Ask what the new thing can sit on. Give your assistant the job and the list, and ask which existing pieces it can build on rather than replacing. Make it name them specifically.

3. When you do the same thing a second time, write the route down where the work lives. Not in a notes app you’ll forget — in the folder, next to the thing. The steps, and the parts that cost you time.

4. Ask what it costs to add. If the answer is nothing, lower your bar for what’s worth trying. Of everything on this list, this is the question that actually changes how you behave.

5. Make it standing, so you stop having to remember any of this.

Sample prompts

Before starting anything new:

Before you write anything, tell me what I already have
that this could be built on, and name each one
specifically. If there's genuinely nothing, say so.

Make it standing, once — paste this into your assistant’s instruction file:

When building something new:
- First, list what already exists that this can land on.
  Name the specific service, file or account. If nothing
  does, say so.
- If this is the second instance of something, reuse the
  first one's pattern instead of designing it again.
- Once the first instance works, write the pattern down
  where the work lives: the steps, the awkward bits.
- Tell me what this adds to the monthly cost. If it's
  nothing, say so.
- If we stop mid-build, leave a note saying exactly
  where to pick up.

The rung that will cost you time is the first instance, every time. Monday took a whole day for one site, and you’ll hit the same wall: the first one surfaces every awkwardness in the process at once, which feels like evidence that the whole approach is wrong. The cause is boring rather than hard — you’re paying a one-off charge for finding out where everything is. Budget a full day, expect to feel stupid around hour four, and judge the idea on instance two. Sites two to six took a fraction of the time.

The third rule in that block is the one that turns a good week into something permanent. A route that exists only in the session that discovered it dies with that session. The last one is the fix for the fragility below: you can’t always work on consecutive days, but you can make picking it back up cheap.

Where to stop

Don’t build the foundation speculatively. Everything above came out of a job I actually needed doing. Infrastructure built for a future you’re guessing at is just a project with extra steps, and it’s the most expensive mistake in this whole approach.

The momentum is fragile, and that part you can’t schedule. I was housebound that week and working in short bursts, which meant the sessions were consecutive. Take three days off in the middle and you spend the next one reloading context instead of building forward.

A lower bar is not no bar. Once things cost nothing to add, the question stops being “is this worth building?” and becomes “is this worth the afternoon?” That’s freeing, and it will also let you build five things nobody asked for. Deciding what deserves the afternoon stays your job.

By Wednesday evening there was image hosting, four small pieces of code, a paid course, a multi-product hub and a service with a live page. All of it out of a week that started with “I should move those images.”

This spring I rebuilt a collaborator’s website with her, and for the first few weeks we coordinated it by sending each other files over WhatsApp. She was using an AI assistant on her machine and I was using one on mine, so every handover meant one of us explaining our half to the other in language they could follow. We fixed it by putting one shared file in the middle and letting each assistant do that explaining for its own person. Here’s the pattern, which works for any two people doing shared work apart from each other.

💡 The principle: when two people each have an assistant that knows how they work, you stop writing for each other and start writing for the machine in the middle — and it hands each of you back only the half you needed.

We’d started on WhatsApp. Each of us would get our assistant to do something, then send the other the output as a markdown attachment. Here’s what mine did to the nav. Here’s the updated about page. Then we’d each paste the other’s changes into our own copy by hand, working from a file that was already out of date by the time it arrived.

It sort of worked, with lag. I’d change the infrastructure and she wouldn’t know until I messaged her; she’d rewrite a page and I wouldn’t know until it arrived as an attachment. Two people with capable assistants, coordinating through a group chat.

The message I never had to read

I typed one line to my assistant: check the repo and see what she’s written. The repo — short for repository — is the shared copy of the project, along with a record of every change either of us has ever made to it. My assistant came back with the two things that affected me, in my terms, out of a page and a half she’d written in hers.

She hadn’t written any of it for me. She’d written it for the project, at whatever length suited her and in her own vocabulary. My assistant did the filtering on my side. When I replied, hers did the same in reverse. It took the technical half of what I’d sent and put it in the terms she works in, saving her the same tax it had just saved me.

It was almost like sending letters back and forth — except the letters carried the full chain of communication with them, so neither of us had to reconstruct the context before answering.

What an “instruction file” actually is

Assistants that run on your own computer — Claude Code, Codex, Cursor — each look for a particular file when they start, and treat whatever is in it as standing orders. There’s no settings screen. It’s a plain document, written in ordinary words, saying how you work and what you want done by default. Each tool has its own filename for it, so check which one yours reads.

This is the prerequisite for everything below, so it’s worth being blunt about it. An assistant in a browser tab won’t do this — it can’t see your files and it starts each conversation empty. Some have a “custom instructions” box that gets part of the way there. If that’s your setup, the shared file still works; you’ll just be pasting it in rather than having it read automatically.

When I say “make it standing” below, I mean write it into that file once so it happens every session afterwards without being asked.

Why a status update never works

Underneath the website rebuild sits a problem you’ll recognise from work that has nothing to do with code. Two people working apart, each holding something the other needs to know, and neither with the time to package it up for them.

It shows up as the weekly summary nobody reads, written for a reader who doesn’t exist. Or the handover document that manages to be both too vague to act on and too long to finish. Or the thread where you read all of it to find the third of it that concerned you.

The reason those never come right is that one document cannot be written for two different readers at the same time. So write it once, in full, for the machine, and let each side’s assistant produce the version its own person needs. Doing that translation by hand used to cost more than it was worth, which is why nobody kept it up.

That holds whether the shared thing is a website, a research project, a house move or a set of accounts.

How to run this yourself

1. Start with one shared document — nothing installed. A single file both of you write into, wherever you already keep things. Put instructions to each other at the top in plain language, and the messy detail underneath.

2. Write more than you would if a person had to read it. Put down what you did, why you did it, and what you were about to do next. The other side’s assistant will cut it to size, so the length costs them nothing and saves you the work of judging what they need.

3. Ask your assistant to read their entries, rather than reading the entries yourself. Tell it what you’re working on and ask which parts affect you. This is the step people skip, and it is the one that turns a shared file into a translation layer.

4. Move it next to the work. Once it’s earning its place, put the file wherever the work itself lives so the history sits underneath it. If that’s a code repository and the other person has never used one, write the setup instructions for their assistant to follow, not for them.

5. Make it standing. Five lines in each side’s instruction file, so neither of you has to remember any of this again.

The file itself

I’ve now run this on four separate projects, and the same five sections survived every time. Everything else I added to one or another turned out to be decoration. Copy this:

# COLLAB.md — [project name]

*Coordination file for [you] + [them].
Both humans and both assistants read this.*

**How to use it:** add to Flags when you need the other
person to do or decide something. Add to Log at the end
of every session. Clear a flag by moving it into the log
with what happened.

---

## Current focus

**[Your name]'s lane:**
- [ ] what you're on now

**[Their name]'s lane:**
- [ ] what they're on now

**Shared decisions needed:**
- [ ] the ones neither of you can make alone

---

## Flags

*Needing the other person. Clear by moving into the log.*

- **[YOU 2026-08-04]** the thing you need from them

---

## Log

*Newest first. One entry per session.*

### 2026-08-04 — [you]

What changed, why, and what you were about to do next.

Two details carry more than their weight. Flags are addressed to a person and dated, so neither assistant has to guess whether one is still live. And you clear a flag by moving it into the log with what happened, so the log writes itself out of the flags instead of being a second thing to remember.

If you keep one line, keep the one at the top: both humans and both assistants read this. Everyone who opens the file reads it first and writes for the right audience without being told again.

Sample prompts

Ask for the other side’s work, filtered for you:

Read [shared file] and tell me only the parts that affect
what I'm working on right now, which is [your current task].
Skip anything I don't need to act on.

Write your half so their assistant can use it:

Add an entry to [shared file] covering what I changed today,
why, and what I'm doing next. Keep the technical detail in —
their assistant needs it. Put anything [name] personally
needs to decide at the top, in plain language.

Make it standing, once:

Working in a shared file:
- Read it before touching anything.
- After a batch of work, add what changed and why, with the date.
- Anything the other person needs to know goes under Flags,
  addressed to them.
- If they've listed something as in progress, don't touch it.
  Flag it instead.
- Never rewrite their section. Add to yours.

The rung that will cost you time is the third one. Early on the translation comes back thin — technically accurate and useless — because your assistant doesn’t yet know enough about the person on the other side to know what matters to them. The cause is boring rather than hard: you told it about the project and not about the other human. Write two or three lines into your instruction file about who they are and what they care about. Do that once and the summaries stop being generic.

I’d assumed this needed software built for the purpose — something to pass messages between the two assistants, with rules about who says what. It didn’t. The record of changes already showed who did what and when, and a plain document is readable by people and machines alike.

Where to stop

Keep this to translation. It’s very good at telling you what the other person did and roughly what they meant. It is not where you agree scope, money or a deadline — those stayed in the one face-to-face session we had, and should have.

And prune the log. My oldest of these has reached forty-six thousand words, with the five sections that make it useful buried under a year of session entries. No assistant reads all of that carefully, so the file quietly stops being the thing both sides trust. The newest is three hundred words and works better. Once the log outgrows the rest of the file, archive the old entries and keep the last month.

The attachments stopped. She writes her half, I write mine, and each of us has something that has read the whole exchange and knows which part of it was ours.

Every new session starts with no memory of the last one. That’s the thing people find hardest to believe and quickest to be annoyed by. You explain your setup on Monday, and on Tuesday you explain it again. Like hiring someone new every morning and handing them an empty desk.

There’s a fix, and it’s one file.

Claude Code looks for a file called CLAUDE.md in the folder you start it in, which here is your Obsidian vault. It reads that file before anything else: before it looks at your notes, before it answers your first message. Whatever is in there, it knows. So you write down in plain English what the vault is for, how it’s arranged, what you’re working on, and how you like to be dealt with.

Without it, you get a generic assistant. Helpful, and you’ll spend half your time supplying context that should already be there. With it, the thing arrives already knowing that captures go in Inbox and that “today” means today’s daily note.

What goes in it

Make CLAUDE.md at the top level of your vault, next to the folders. Mine started at about this size:

# CLAUDE.md

## What this vault is
My personal notes and project system, in Obsidian. Plain
markdown files.

## Structure
- Inbox/ — quick capture, sorted later
- Projects/ — active work with an end state
- Areas/ — ongoing responsibilities
- Resources/ — reference material
- Archive/ — finished, kept not deleted
- Daily/ — one note per day, YYYY-MM-DD.md

## How I work
- When I capture something in passing, put it in Inbox.
- New project means a folder in Projects, not a loose note.
- When I say "today", read today's daily note first.

## What I'm working on
- [two or three real things, kept current]

## Preferences
- Short answers. Plain words, no corporate register.
- If you don't know where something goes, ask.
- If you can't find something, say so rather than guessing.

What makes this work is that it says what the folders are for. “Inbox — quick capture, sorted later” tells an assistant how to behave. A bare list of folder names tells it nothing it couldn’t have guessed by looking.

The part where mine went wrong

I’d been running this file for months and it had grown. At some point I’d copied a block of “the most important rules” into it by hand from another file, so that both places had them.

That copy rotted. For over two months it named a helper that had been retired and no longer existed, while leaving out seven that did. It also credited a rule to a file that had never contained it. None of it announced itself. The file was accurate the day I wrote it and went wrong quietly when the setup moved on. A stale instruction reads exactly like a live one. Nothing on the page distinguishes a rule that is true from a rule that was true in May.

The fix wasn’t more diligence. It was to stop keeping two copies. The file now points at the detail rather than repeating it, so there’s one place to change when something moves.

Which gives you two rules I’d hand anyone starting theirs today. Write instructions that describe how you want the thing to behave, because those age slowly. Be very careful with instructions that list what exists — names of folders, tools, files, people — because those age fast and rot silently.

Making it repeatable

Once the file is doing real work, it needs a habit attached, and this is the whole maintenance routine:

About this instruction file:
- When we agree a new convention, add it here before we move on.
- When I retire or rename something, search this file for it
  and fix or remove the line.
- Never copy a rule from another file into this one. Link to
  where it lives instead.
- Every month, read this file back to me and flag anything that
  no longer matches what you can actually see in the vault.

That last line would have caught my two-month-old error, and it costs nothing. The assistant can see the real folders and the real tools, which puts it in a better position than me to notice that the file describes something now gone. Ask it to check its own instructions against reality, on a schedule.

Mine is a few hundred lines now, and every line arrived because something went wrong once. That’s the honest way these grow — not designed up front, but accumulated one correction at a time.

That’s Start Here. Tools installed, folders shaped, instructions written. From here on, everything in this publication is a layer on top of those three things.

An empty Obsidian vault is a folder on your computer. There’s nothing wrong with that, and there’s nothing special about it either — it’s the Documents folder you’ve been ignoring for years, with a nicer app pointed at it.

Here’s how it goes wrong, and I’ve done this more times than I’d like to admit. You make a few notes. Then a few more. They pile up loose where you can’t find anything, so you add a folder called Work, then one called Ideas, then one called Misc, which is the graveyard. A month later you’re searching your email instead of your notes.

Evernote, Notion, Apple Notes. Each one started with enthusiasm and ended with a thousand unsorted notes I never opened again. Every notes system dies the same way: the pile gets more expensive to maintain than it is to use, and one Tuesday you stop opening the app.

So before any AI goes near it, the folder needs a shape. Not a clever one. Just enough to answer “where does this go?” without thinking.

Five folders

Make these inside your vault:

Your Vault/
├── Inbox/       <- Quick capture. Everything lands here first.
├── Projects/    <- Active work with an end state.
├── Areas/       <- Ongoing responsibilities, no end date.
├── Resources/   <- Reference material you want to keep.
├── Archive/     <- Finished or inactive.
└── Daily/       <- One note per day.

Inbox is the one that matters most, and it’s the one people leave out. When you don’t know where something goes, it goes in Inbox and you sort it later. Without it you spend thirty seconds deciding where a note belongs — which doesn’t sound like much until you notice it’s enough friction to stop you taking the note at all.

Projects end and move to Archive. Areas don’t end. Resources are things you’ll want to look up but aren’t acting on. Archive is where finished work goes to stop cluttering the live folders, without being deleted.

If that looks familiar, it’s a simplified PARA — Tiago Forte’s method. You don’t need the book; the folder names explain themselves. Mine diverged from it within a few weeks and yours will too, because the specific folders aren’t the point. The point is that there are folders. Structure is what makes things findable, and findable is what makes any of this worth maintaining.

A note for today

In Daily/, make a file named for today’s date: 2026-08-04.md.

Use YYYY-MM-DD and nothing else. It sorts chronologically for free, forever, with no effort — January always files before June. Any other format and you’ll be fixing it in a year.

Three sections inside, and no more:

# 2026-08-04

## What I'm working on
-

## Notes
-

## End of day
-

Mine has grown since — it now carries session logs, energy, and a “decisions made” section I didn’t know I needed until I kept forgetting why I’d chosen things. But it grew because I was using it. I’ve watched people design a seven-section daily template with mood tracking and gratitude prompts and abandon it inside a fortnight, because filling in the template became the work.

Obsidian will make today’s note for you. Turn on the Daily notes core plugin, then open Settings → Plugin options → Daily notes, where you’ll find New file location (point it at Daily), Date format (YYYY-MM-DD), and Template file location if you want the three sections filled in automatically.

Making it repeatable

The folders only work if the assistant files things the way you would. Which means telling it the rules once, in the CLAUDE.md file from the first post, rather than every session:

Filing rules:
- Anything I capture in passing goes in Inbox. Don't try to
  file it properly.
- A new project gets a folder in Projects, not a loose note.
- Daily notes live in Daily/YYYY-MM-DD.md. When I say "today",
  read today's note before answering.
- Finished projects move to Archive. Never delete them.
- If you can't tell where something belongs, put it in Inbox
  and tell me.

Five lines and your folders are now enforced by something other than your own discipline at 11pm. The last one is the important one: given a choice between guessing at a location and asking, you want it to ask — and it won’t unless you say so.

Next: that instruction file properly. What goes in it, how it grows, and the way mine quietly went wrong for two months without me noticing.

Five folders, one dated note, five lines of filing rules. That’s the whole shape.

You’ve seen the demos. Someone shows an AI reading their notes, drafting in their voice, remembering a decision from three months ago. It looks like magic, and the demo always starts at the result. Nobody films the beginning.

This is the beginning.

What a second brain actually is

An external place where your thinking accumulates instead of evaporating. Notes, documents, project files, a daily journal — anything you might need again, in one place, with enough structure that you can find it.

That idea is decades old. Zettelkasten, Getting Things Done, PARA: all systems for keeping knowledge outside your head. They all run into the same wall, which is that maintaining the system is work. Filing, linking, remembering what you called things. Most people set up a notes app, use it keenly for a month, then quietly stop, because the upkeep costs more than the recall is worth.

What changed is that the upkeep is now something you can hand over — not to a chatbot you paste things into, but to an assistant that lives in the folder your notes are already in, reads every file and writes new ones. The filing and the searching move off your plate.

I started mine in late 2025 with an empty folder and an assistant that could see it. Everything since has been layers on that.

The two pieces

You need a place for the knowledge and an assistant that can reach it.

Obsidian is the place. It’s free, and it keeps everything as plain text files in a normal folder on your computer. No proprietary format, no database. If Obsidian vanished tomorrow your notes would still be sitting there, readable in any text editor. That matters more than it sounds, because the whole arrangement depends on an assistant being able to open your files directly — which it cannot do if they’re locked inside someone else’s app.

Claude Code is the assistant. It runs where your files are, so it reads them, edits them, creates new ones and searches across the lot. It does need a paid Claude plan; the free tier doesn’t include it.

Two things worth knowing, because most write-ups you’ll find are out of date on both:

You don’t need Node.js any more. Older guides — including one I wrote — tell you to install that first and then use npm, a tool for installing developer packages. The current install is one line that brings everything with it:

curl -fsSL https://claude.ai/install.sh | bash

And you don’t have to use the terminal at all. There’s a desktop app that runs the same thing in a normal window with buttons. If a black screen and a blinking cursor is why you’ve put this off, that reason is gone.

Your first session

Open your new Obsidian folder, start Claude Code in it, and ask it three things:

What files are in this vault?

Create a note called “First Note” with today’s date and one line saying this is where it started.

Read First Note.md back to me.

That’s the whole first session. It sees your files, it creates one, it reads it back. Unimpressive, and also the entire foundation — everything else is capability stacked on top of an assistant that can already reach your notes.

Making it repeatable

The one thing I’d do differently, knowing what I know now, is write the instructions down on day one instead of month three.

Every new session starts with no memory of the last one. So you tell it the same things about your setup, over and over, until you get bored and stop bothering — at which point it starts guessing. The fix is a file in the folder that it reads every time. A skill, in this context, is nothing more exotic than that: a text file of instructions, in plain English, not code.

Mine started as five lines. Yours can start as three:

About this vault:
- This is my personal notes folder. Everything is markdown.
- Daily notes go in a folder called Daily, named YYYY-MM-DD.
- Ask before creating folders. Never delete a file without
  telling me.
- If you can't find something, say so. Don't guess at a
  filename.

Save that as CLAUDE.md in the folder. From then on, every session begins already knowing where things go — and the last two lines will save you more grief than the first two, because an assistant that guesses confidently is the one failure mode you’ll actually notice.

Next in this series: what to put in that folder, and how those three lines grow into the file that teaches an assistant your whole system.

Twenty minutes, two installs, one file of instructions. Everything else here is built on that.

macos-automator runs AppleScript on your Mac on request. AppleScript is the old, creaky language Apple built in the nineties so applications could drive each other, and because it’s been around that long, a great deal of Mac software can be controlled with it even when it offers developers nothing else at all.

So this is the tool that turns “here’s how you’d do that on a Mac” into “done”. Most assistants can tell you which menu to click. This one clicks it. It also ships a library of ready-made scripts, which matters more than it sounds.

What I use it for are the jobs nobody will ever build an integration for. Pulling today’s calendar into my morning briefing as plain text. Reading unread mail in an app that speaks only AppleScript. Exporting from software old enough that its export button doesn’t do what you want. These tasks stay manual forever precisely because no vendor has any reason to automate them.

Then there was the day that taught me how this actually fails.

Every attempt to read mail through AppleScript hung. No error, no refusal — nothing, until it timed out with a number meaning “the event took too long”. My first instinct was that the mail app had wedged, so I killed it and restarted it, killed stray script processes, cleared a system dialog that had been sitting open since the previous Sunday, and turned off a sandbox. None of it made any difference.

What settled it was checking whether other applications behaved the same way. Asking Finder for something hung identically. So did the system’s own scripting component. Two unrelated parent processes, same hang. That isn’t a wedged app; that’s macOS silently refusing automation because the permission was never granted. Reading the mail folder directly came back “operation not permitted”, which is the same story told from the other end.

The clincher came later. The identical script ran perfectly in a normal desktop session. Same code, same machine, different kind of session. When the same instructions succeed in one context and hang in another, stop debugging the instructions.

Making it repeatable

The one-off ask is usually mundane, which is the point:

Pull today’s calendar events into plain text for the morning brief.

The standing version lives in a skill — a text file of instructions the assistant reads when the job comes up, written in plain English:

When running local scripts on this Mac:
- If a script hangs with no error, suspect permissions before the
  app. Try a second application; if that hangs too, macOS is
  refusing automation.
- Never assume the frontmost window. Target the app and the
  document by name.
- Assign a date to a variable before formatting it. Formatting
  inside a longer expression returns something that won't
  convert.
- If it works in my desktop session but not unattended, say so
  rather than retrying.
- Check the script library before telling me something isn't
  possible.

Every line there is a mistake already made, and the last one is mine at its most embarrassing. I’d assumed there was no browser automation available in my setup and said so out loud. Four runnable scripts were sitting inside this tool the whole time. They happened to be blocked by the permission problem above — but “blocked” and “doesn’t exist” are very different sentences, and I said the wrong one without looking.

The third rule looks like trivia and isn’t. AppleScript dates are genuinely awkward: format one inside a longer expression and you get back a wrapped value that refuses to become a string, with an error number that explains nothing. Assign it first, build the string from year, month and day, move on with your life.

The project is open source and installs in a line. Grant Accessibility, Automation and Full Disk Access to whatever’s running the scripts before you rely on it, and test one small script deliberately.

My calendar now arrives as text every morning, from an app that has no API and never will.

Not sure what an MCP server is or how it’s used? Check out my explainer here.

Resend is the plumbing that sends email from software — password resets, receipts, invoice reminders, the weekly report your system generates on its own. Not newsletters to a list; the individual messages your tools send without you. Its MCP server puts sending, contacts, domains, webhooks and, crucially, the delivery log where an assistant can reach them.

The reason it made this list is one specific afternoon. A client’s automated weekly report was set to go out at six in the morning, and I needed to know whether it actually had. The automation that triggered it said it had done its part. The invoicing side of things said its bit had run. Neither of them had the faintest idea whether an email reached a human. Resend’s log did: delivered, at the right minute, to the right person, with the right figures in the subject line. A question that had been open for a week closed in about thirty seconds.

That distinction is the whole value. Every component in a chain will happily confirm it did its job. A “sent” flag belongs to the thing that queued the message, and queuing is not delivering. There is exactly one component that knows whether mail arrived, and having its log available in the same conversation where I’m working means I actually check it, rather than assuming.

The failures it catches are the invisible kind. Automated reminders are precisely the thing that quietly stops working, because nobody notices a message that doesn’t arrive. A newsletter going missing generates complaints; a reminder going missing generates silence, then an awkward conversation about an unpaid invoice six weeks later.

Making it repeatable

The one-off ask:

Did this morning’s report send? Check the delivery log and tell me who it reached and at what time.

The standing version lives in a skill — a text file of instructions the assistant reads when the job comes up, written in English rather than code:

For anything email-related:
- "Sent" in the app that queued it is not delivery. Check the
  sending log at the provider.
- Report the timestamp and recipient from the log, never from
  a status flag.
- If a scheduled send has no log entry, treat it as failed and
  tell me straight away.
- Client-facing mail: draft it and stop. I send it.
- Never report a send as confirmed without quoting the log line.

The fourth rule is the one I’d insist on hardest, and it’s the least technical. Having the send available as a tool call makes it easier to skip human review, which is exactly why the rule has to be written down rather than assumed. Anything going to somebody who pays me gets generated automatically and then read by me. No raw machine output leaves the building.

The last rule exists because I’ve watched an assistant tell me an email went out when what it had actually seen was a queue confirmation. Requiring the quoted log line makes that impossible to fudge — either there’s a line to quote or there isn’t.

Domain setup gets easier too, incidentally. The records that decide whether your mail is trusted at all are readable and checkable as tools, rather than a support article you follow once and never verify again.

Resend’s free plan covers 3,000 emails a month, capped at 100 a day on one domain, which is plenty for anything personal, and their MCP server is documented and officially supported.

The report went out at 06:00 UTC, to one recipient, with that week’s figures in the subject line. I know because I read the log line myself, rather than being told it had gone fine.

Not sure what an MCP server is or how it’s used? Check out my explainer here.

n8n is workflow automation you host yourself. If you’ve used Zapier or Make, it’s that shape — when this happens, do that — except it runs on your own server, there’s no per-task meter, and your data stays in your account. Mine lives in a container on a small rented machine.

Its MCP server changes how you build with it, and that’s the reason it’s on this list. I describe what I want the automation to do and it gets built for me: the actual workflow, in my instance, ready to run.

Here’s the difference that makes. Building in a drag-and-drop editor is pleasant for five boxes and grim for thirty, but the slow part was never the dragging. It was having twelve documentation tabs open to work out what each box wants in each field. n8n ships hundreds of integrations, each with its own settings and its own opinions about which field is required when. The MCP server can look those up, so what gets built is wired against the real configuration rather than a plausible guess at it. Then it validates the whole thing before anything goes live.

Yesterday I said, roughly: when that scrape finishes, check the request is genuinely mine, pull the results, format them as a short summary and send it to Telegram. Five steps, one of them real code. I got a working workflow inside the conversation, and every automation since has been a ten-minute variation on it. The formatting step is the bit I’d flag if you’re weighing this up — dictating what you want a code step to output, and having it written correctly in place, is a different activity from typing JavaScript into a small box in a browser.

One thing to watch, because it cost me an afternoon. I created a credential — an API key for another service — by posting it to n8n’s own API. Clean success, valid ID returned. When I opened that credential in the interface, the key field was empty. You can’t catch that by asking the API either, because n8n deliberately won’t return credential contents when you read one back. Good security, unverifiable write. The only proof is a test execution: run one step that uses the credential and watch it authenticate or fail.

Making it repeatable

The one-off ask is the whole point of this one:

Build me a workflow: when that scrape finishes, verify the request is mine, fetch the results, format them as a short summary and send it to Telegram. Validate it before you activate it.

The standing version lives in a skill — a text file of instructions the assistant reads when the job comes up, in plain English rather than code:

When building or changing a workflow:
- Look up the real node configuration before wiring anything.
  Never guess field names.
- Validate the whole workflow before activating it.
- After creating a credential, run a test execution. The API
  returns success even when the key didn't save.
- Attach the global error handler to everything, so failures
  reach me instead of going quiet.
- Tell me what you changed and which executions have passed
  since.

The third line is the expensive one, written down so it never bills me again. The fourth is the one people leave out and regret: an automation that fails silently is worse than no automation, because you carry on believing it’s working.

Since I self-host, I’m also the operations department, which produced one more lesson worth passing on. My automation server was backing itself up faithfully every night — onto itself. A backup that lives on the machine it protects dies with the machine. It now pushes to a box in a different building, and I proved that by breaking it deliberately three ways before trusting it, then pulling a backup down and confirming the database dump was complete.

n8n is free to self-host, or they’ll host it for you. Either way, add the MCP server before you build anything complicated.

The pipe that runs my morning scrapes was described out loud, validated before it went live, and has fired every three hours since. I opened the editor once after that, to read a value back out of it.

Not sure what an MCP server is or how it’s used? Check out my explainer here.

A Google Docs MCP server connects an assistant to Docs, Sheets and Drive. It can read a document’s full text, restructure sections, write rows into a spreadsheet, search the drive, file something into a specific folder and set who can see it. That last part turns out to matter more than the editing.

My own second brain is thousands of markdown files, which is ideal for me and useless to everybody else. Anything with a second human at the other end lives in Google instead, and there are three things I use it for constantly.

The first is checking what a collaborator and I have actually written together. On a joint piece of work spread over several documents, I can ask what we’ve covered and who wrote which part, rather than opening five tabs and reassembling the picture in my head each time.

The second is reading the notes under someone else’s slides. Speaker notes are where the real content of a deck lives, and they’re miserable to read in the presentation view. Pulling them out as plain text and asking questions of them beats clicking through eighty slides.

The third is filing receipts for my accountant. Every invoice that arrives gets recognised, named and dropped into the right per-quarter, per-supplier folder in a shared drive while my mail is being processed, rather than in a panic each quarter. My accountant opens the folder and it’s all there.

That last one comes with a mistake attached, and it’s the useful part of this post. I once wanted to know which business expenses were missing their receipts, so I counted the documents attached to each expense in my invoicing system and reported back that eighty-seven had none. The number was accurate. The conclusion was wrong. Every one of those receipts existed, already collated and already sent, sitting in the shared Drive folders where my accountant needs them. The invoicing system holds the amounts; the folder holds the paperwork. I’d counted the wrong thing and made my past self redo finished work.

The lesson generalised better than the specifics: for anything shared with another human, the shared folder is the system of record, whatever your internal tooling thinks. If the accountant can see it, it exists.

Making it repeatable

The one-off ask:

File this invoice into the shared drive under this quarter and the supplier’s name, then tell me the folder path you used.

The standing version lives in a skill — which is just a text file of instructions the assistant reads when the job comes up, written in English rather than code:

When filing or editing anything shared:
- The shared folder is the system of record. Never conclude
  something is missing from a count in another system.
- File by quarter and supplier. Name files so a human can find
  them without me.
- Edit the real document in place. Don't hand me text to paste.
- Read speaker notes as text rather than describing slides.
- Mail stays in my mail client. Don't route inbox work through
  this server.
- Tell me the path and who can see it after any write.

The last line is there because a shared drive is the one place where getting permissions wrong is worse than getting the filing wrong. And the mail rule is there because I have accounts this connector genuinely cannot see, so letting it near my inbox produces confident, partial answers.

The quieter benefit is that Drive is a decent bridge between systems that don’t otherwise talk. My e-ink tablet exports handwritten notes as PDFs into a Drive folder; something picks them up from there, transcribes them and appends the text to that day’s note. Two devices that share no protocol, connected by a folder they both understand.

Setting one up needs a Google Cloud project and an authorisation step, which is fiddlier than an API key. There are several implementations to choose from.

Last quarter’s receipts filed themselves, one at a time, as the emails arrived. I didn’t open a file manager once.

Not sure what an MCP server is or how it’s used? Check out my explainer here.

Kit is the email platform my list lives on. In November 2025 it had no MCP server, so I wrote one — mcp-kit, open source, connecting Claude to subscribers, tags, sequences and broadcasts. I used it for six months. In June I deprecated it, because Kit shipped first-party servers of their own with wider coverage and managed sign-in, so there’s no API key sitting in a config file on my machine any more. My repo’s README now points at theirs. That’s the right ending for a tool like this; I was ever only after the capability.

What it gives you is the account as tools rather than as screens. Look up a subscriber, tag a segment, schedule a broadcast, read open and click figures, tidy up sequences left over from a project you retired two years ago. The chores that used to be a dashboard crawl I postponed indefinitely are now sentences, and the ones worth repeating can run to a schedule.

Auditing engagement one afternoon, I found four separate tools returning wrong or truncated answers while reporting complete success. A request for statistics on a specific list of sends ignored my list entirely and returned the ten most recent — I only caught it because three different requests came back byte-for-byte identical. A link-click report silently stopped at ten links, so an eighteen-link issue looked like a ten-link issue. A filter for active subscribers cheerfully included people who had unsubscribed, confirmed cancelled on their own records. And a tag’s member list came back empty seconds after ten people had been tagged successfully.

Every one of those returned a clean status code. The pattern underneath all four is that reads of a single record were always right, and reads of a whole collection were repeatedly wrong. Which is less a complaint about one platform than a description of what working with any API through an assistant is like. The failure mode is rarely an error message; it’s a confident wrong number.

There’s a second layer of unreliability that has nothing to do with the API. Litmus finds that over half of all email opens now happen on a device with Apple’s Mail Privacy Protection switched on, which loads the tracking pixel whether or not a human ever looks. Corporate link scanners do the same to clicks. So an open rate is a number about machines.

Making it repeatable

The one-off ask, when the answer matters:

Tell me which subscribers have opened nothing in the last ten sends, and read each record individually rather than trusting a filter.

The standing version lives in a skill — a text file of instructions the assistant reads when the job comes up, in plain English:

When reading anything out of Kit:
- Trust per-record reads. Distrust collection reads.
- Read the individual record back before reporting any state
  change. A filter re-run is not proof.
- Treat every count as a floor, not a census.
- Ask for 100 results on link clicks. It truncates at 10 in
  silence.
- Never quote an open rate as engagement. Over half of opens are
  machines. Use clicks on links in the body.
- Confirm the exact change list with me before any write. Writes
  go to real people.

Six lines, and five of them are that afternoon’s mistakes written down. The sixth I put there on purpose. Tagging somebody or removing them changes what lands in a real person’s inbox, so an assistant should stop and show me the list before it does anything.

If you already pay for Kit, you already have this — one line to add the account server, another for their developer docs if you’re building against the API. The version I wrote is still up as a reference, with a deprecation notice pointing at the official ones.

Six months of maintaining my own server, retired in an afternoon. Best possible outcome for a tool I only built because nobody else had.

Not sure what an MCP server is or how it’s used? Check out my explainer here.

Buffer is a social media scheduler. You connect your accounts, fill a queue, and it posts to a timetable so you don’t have to be at a desk at 8am on a Tuesday. It also has an MCP server, which puts that queue inside the conversation where I’m already writing the posts.

I set up a company page a fortnight ago and needed content on it from a standing start. Eight posts, one per weekday. Ordinarily that’s an evening: write one, copy it, open the scheduler, paste, pick the channel, set the time, attach an image, go back, write the next one, lose your place, make coffee. I did all eight in one sitting without leaving the conversation.

The part I didn’t expect was what it did to revising. Rearranging a queue by hand is tedious enough that I’d let a mediocre post go out rather than reshuffle seven others around it. Moving one to Thursday is now a sentence, so I move it.

Two things nearly went out wrong, and both are the kind of thing nobody warns you about.

The first was link previews — the box with a picture and a headline that appears under a post when you share a link. Mine weren’t appearing. The posts published as bare URLs, which look cheap and get fewer clicks. I assumed the problem was on the website’s end, in the preview information a page publishes about itself for exactly this purpose, so I went and checked. It was correct. The actual cause is that Buffer wants the link attached to the post as a thing in its own right, and typing the address into the body of the post doesn’t count. There’s no warning. The post looks finished sitting in the queue and only reveals itself when it publishes.

The second was about who gets to press send. The page is co-owned with a collaborator, so I wanted posts to queue up and then wait for a human to release them. For that channel Buffer offers two settings: save as a draft, or publish automatically. There is no approval step in between. So the shared page runs draft-then-publish by hand, deliberately, and the automation stops one step short of the thing that matters. When somebody else’s name is on the page, “it went out automatically” isn’t a sentence I want to have to say to them.

Making it repeatable

The one-off version of this is just asking. I say something like:

Take these three posts, queue them on the company page for the next three weekday mornings, attach the link to each one as a proper link asset, and leave them as drafts rather than publishing.

That works. But I don’t want to remember those two gotchas every time, and in six weeks I won’t. So they live in a skill instead — and a skill here is nothing more exotic than a text file of instructions the assistant reads when the job comes up. You write it in plain English, not code. Mine says roughly this:

When queueing social posts to Buffer:
- Attach every link as a link asset. A URL typed into the post
  body publishes with no preview card.
- The co-owned page is draft-only. Never schedule it to publish
  automatically.
- One post per weekday, mornings, unless I say otherwise.
- Read the finished queue back to me with dates before you stop.

Four lines of English, and every one of them is a mistake I already made. Written down once, they stop being things I have to catch. Anything that reads that file queues posts the way I would on a good day.

Every tool in this series works the same way: the MCP server lets an assistant act, and a short file of instructions tells it how you want that done.

The rest of what I use it for is smaller. There’s a place to put an idea that isn’t a post yet, which is where half-thoughts go instead of into a note I’ll never open again. And the performance figures come back through the same interface, so asking what actually landed last month is a question rather than an afternoon. I’ve scoped a searchable archive of my own old posts on top of that — the history and the numbers are both reachable — though I haven’t built it.

Buffer’s free plan connects three channels, which is enough to find out whether the habit survives contact with a real week. Mine now has eight posts going out, one per weekday, and I haven’t opened the Buffer website since the day I loaded them.

Apify is a marketplace of ready-made scrapers. Someone else has already built and maintained the thing that pulls listings off a property site or profiles off a professional network, and you rent it by the run. They call them Actors; think of an Actor as a small robot you hire for thirty seconds. The MCP server turns any of them into a tool an assistant can call mid-conversation.

The reason it earns a place alongside plain web search is that some data can’t be fetched politely. Sites behind logins, pages that only load as you scroll, anti-robot checks, anything that needs a session. A normal fetch reads one page. Apify collects a hundred and hands back records with the same fields in every row, which is a spreadsheet rather than a wall of text.

I spent about a day on it this week and got four things out of it, in ascending order of usefulness.

The first was a reusable delivery path. A scrape finishes, it fires a webhook, my self-hosted n8n checks the request is really mine, fetches the results, formats them and sends them to Telegram. Built once. Every use since has been a new task, a schedule and a webhook — about ten minutes of clicking and no new code. Six scrapes now run every three hours for under five cents a day.

The second was proving the security gate could fail before I trusted it. Each webhook carries a shared secret and the pipe drops anything whose secret doesn’t match. So I fired one with the wrong secret and watched it get rejected. Then I fired one with the right secret and a deliberately fake results ID, which was admitted and then failed at the fetch with “not found” rather than “not authorised” — proving the credential underneath worked too. A check you have only ever seen pass tells you nothing.

The third stung. Five weeks ago I deleted a scheduled scan that watched for a particular kind of freelance listing, because the free plan’s result allowance was spent and it could no longer return anything. The paid plan removed exactly that blocker on day one, and nothing in my system ever went back to look at something switched off for a reason that had since expired. Five weeks dark. It runs again now, and I write the un-pause condition down next to anything I turn off.

The fourth is the check that saves the most time, because it stops work rather than starting it. Look at the user counts on the Actors in your niche before you commit. I nearly built a lane around Spanish government data: ten relevant Actors existed, median about three and a half users each. The Actor for one big Spanish property portal had 1,859. That gap is the market telling you nobody scrapes open government data, because it’s already published cleanly. The lane closed before it cost me a week.

Making it repeatable

The one-off ask is direct:

Run the profile scraper on this URL and give me the career history as a table, with dates.

The standing version lives in a skill — a text file of instructions the assistant reads when the job comes up, in plain English rather than code:

Before scraping anything:
- Check the Actor's user count in the store first. Low usage
  usually means the data is already published cleanly. Say so
  and stop.
- Prefer a maintained Actor over writing a scraper.
- Schedule it and deliver the result to me. Don't leave a job
  that depends on me remembering to run it.
- Every webhook carries the shared secret, and I want the decoy
  test run before we trust the gate.
- Tell me what the run cost.

The first rule is doing the most work there. It’s the only one that regularly ends with the assistant telling me not to bother, which is the outcome I most need and am least likely to reach on my own enthusiasm.

Apify’s free plan comes with $5 of credit and no card required, and compute bills at twenty cents a unit. Run one Actor by hand in their console first; if it gives you what you want, then wire up the MCP server.

The scrapes ran at six this morning while I was asleep. That’s the whole change.

Brave Search MCP connects an assistant to Brave’s search API, so instead of answering from whatever it absorbed during training, it runs a real search and reads what’s on the web right now. Brave runs its own index rather than reselling someone else’s results, which is why I have it as the default rather than the fallback.

Here’s what that’s actually worth. I got charged for a year’s subscription on a games console account I’d meant to cancel, and the support reply was a flat no — the receipt says purchases are final. I asked Claude to look into it. Brave surfaced the company’s own help page, which said, in their words: “there is also a statutory 14-day right to cancel.” Their documentation contradicting their support desk. That went into my reply, quoted, with the link. I would never have found that page myself, because it wouldn’t have occurred to me to go looking for it.

That’s the shape of it. A language model is trained on a snapshot and then frozen. It doesn’t know what today is, it can’t distinguish a fact it learned from a fact that has since changed, and it will tell you either in exactly the same confident tone. Prices, documentation, policies, release notes — all of it drifts, and none of the drift is visible from inside the model.

There’s also a practical reason it’s the default and not the impressive option. I used to route research to a paid research API. One day an agent invoked it by accident and ran a few hundred queries in the background; I found out when the invoice arrived. Automated searching has to be free, or something you never think about will eventually cost you money while you sleep. So the agents get Brave, and I still use a paid AI search product in my own browser, where every query is one I chose to run.

Making it repeatable

The one-off ask, when I care about being right:

Before you advise me on this, search for the current documentation and tell me what you found and where you found it.

The standing version lives in a skill — a text file of instructions the assistant reads when the work comes up, written in plain English:

Whenever anything time-sensitive comes up:
- Search before answering. Prices, docs, policies and release
  notes are all stale in your training data.
- Give me the link alongside the claim. A claim with no source
  doesn't ship.
- Stitch several cheap searches from different angles rather than
  one expensive deep-research call.
- If a page needs a browser to render, fetch the page properly
  instead of reasoning from the search snippet.
- Say which of your claims came from search and which came from
  memory.

That last rule is the one I’d fight for. The failure I keep seeing is a confident paragraph where two sentences came from a live page and the third came from 2024, with nothing at all marking the join.

It’s also what makes anything unattended worth reading. My daily news round-up genuinely checks this morning’s web rather than reciting last year’s internet. A background check on a company or a person who’s approached me starts from real results. Neither is something I’d let run without me if the tool underneath were working from memory.

The API gives you $5 of credit every month, free and applied automatically, against $5 per thousand requests — so a thousand free searches a month before you owe anything. I have never come close to spending it. The MCP server is open source and setup is an API key and one line of config.

The reply I sent quoted the company’s own page back at them. However that ticket ends, I wouldn’t have had that sentence to write without a search that happened while I was talking.

local-llm gives Claude six specific jobs it can hand to a model running on my own computer: summarise, draft, classify, extract, transform, complete. Claude stays in charge and decides what to delegate. A small local model does the repetitive part. I built this one, because I kept watching an expensive model do work that needed no intelligence at all.

The model runs under Ollama, which is the easiest way to run a language model on your own machine — one command to install one, and it serves locally like any other bit of software.

What changed for me is which jobs are worth automating at all. Sorting every subject line in my inbox by type. Summarising every article I clipped this week. Pulling the dates and amounts out of a stack of letters. None of those need frontier reasoning, and all of them are per-item work, so the cost of doing them with a cloud model made automating them faintly ridiculous. I did them by hand or I didn’t do them. Now they run over every item, every day, and the marginal cost is electricity.

The part where people give themselves a bad time is hardware, so here are the real numbers. Mine runs on a headless Mac with 16 GB of memory that is also hosting a stack of containers, so there is nowhere near 16 GB free. One seven-billion-parameter model at Q4 — Q4 meaning the weights are compressed to roughly an eighth of full precision, barely perceptible on mechanical work and enormously smaller — comes to 4.7 GB and sits there comfortably. A 9.6 GB model plus the containers is 14.7 of 16 before a single question gets asked. Do that arithmetic before you download, not after.

And I say that having got it wrong myself. I had eight models on that machine for months, and my own documentation confidently stated the default was a Gemma model. It wasn’t. The config file pinned Qwen’s coder model and always had. The docs and the config had disagreed for months and I’d have sworn blind the docs were right. I deleted the six nothing was using, freed 32 GB, and nothing broke — because the model I believed was doing the work had never been doing the work. Then I checked the free space with df rather than trusting my own subtraction, which turned out to matter too.

Making it repeatable

The one-off ask is plain:

Classify these two hundred subject lines by type using the local model, then show me only the ones it couldn’t place.

The standing version lives in a skill — which is just a text file of instructions the assistant reads when the work comes up, written in English rather than code:

Routing rules for text work:
- Classify, summarise, extract, transform, translate → local model.
- Judgement, voice, security, anything client-facing → keep it
  with Claude.
- Check the config for which model is actually loaded. My own
  docs were wrong about this for months.
- One 7B model at a time. The machine has 16GB shared with
  everything else on it.
- Review what comes back. Local output is a first pass, not a
  finished one.

Five lines, and each one is a mistake I’ve already made — including the last, which is the one people skip. A small model will hand you a confident, tidy, wrong classification, and the whole arrangement only works because something reads it afterwards.

Setup is Ollama, one model pulled from their library, and a line of config to point the MCP server at it. The project is open source and MIT licensed.

The cloud model still does all the thinking here. It just stopped doing the sorting.