The Tools Are the Brain

I got assessed for ADHD this year. Combined presentation, the report parked my inattentiveness at the absolute ceiling, openness near the top of the scale, and a cluster of traits the psychologist politely called “just right” tendencies, which is clinical for “open loops in this man’s head never close, ever.” I read the thirty page report expecting a gut punch. Instead I just kept nodding. Because I’d already spent years building around every single line of it, I just didn’t have the words yet.

Here’s the part nobody warns you about getting the label late. The tools you built to survive suddenly make a lot more sense. I thought I was just a guy who was really into tooling. Turns out I was building a prosthetic and calling it a hobby.

Remember evaporates

Let me describe how my executive function actually runs, because it’s the reason any of this exists.

There are four steps between an intention and a shipped thing. Remember it, choose to do it, finish it, ship it. For me remember evaporates on contact. Choose works, but only halfway. Finish holds exactly as long as the problem is still novel, and the instant the interesting part is solved, finish drops off a cliff. Ship basically never happens. Wizard is the one clean exception and I’ll get to why.

Most productivity advice aims at the wrong step. It assumes the failure is discipline, that you knew the thing and chose the couch. My failure is one step earlier than that. The intention was real and then it was just gone, no residue, like it was never issued. You cannot be disciplined about a task you can’t recall having.

So the real design question for me was never “how do I make myself do the thing.” It’s “how do I make the thing come back to me at the exact moment it matters, without me having to remember to go get it.” That sounds like a minor distinction. It is the entire line between every system that’s worked for me and every one that hasn’t.

Capture was never the problem

I have Apple Notes. I throw everything into it. Capture is fine, I am elite at chucking state into a sink. The part that’s been broken for years is that I never open it. A capture system with no resurfacing is just a graveyard with good search. Every note perfectly filed, perfectly organized, stone dead, because nothing ever shoved them back in my face.

The fix, once I finally saw it, was almost insultingly small. Keep the same inbox, bolt on one time-triggered thing that pushes the contents back at me every morning as a notification. That’s the whole fix. The insight wasn’t a fancier app, it was that the system has to come to me. Anything that needs me to go to it is dead on arrival, because “remember to check your notes” is precisely the class of intention that evaporates.

That’s my one design law now, and I’d hand it to any engineer wired like me. Build systems that arrive. Never build systems you have to visit.

Wizard, or why I built a memory layer for machines

Wizard is a persistent memory layer for AI coding agents. Twenty MCP tools over FastMCP, seventeen agent skills, SQLite with FTS5 search for storage, LiteLLM to synthesize transcripts into durable memory, session continuity so an agent resumes instead of starting from zero, work triage scoring, PII scrubbing, a Streamlit dashboard, optional writeback to Notion and Obsidian. I once built a compact serialization format on top of it to shave tokens off every payload, then ripped it back out when it broke local-model parsing — the memory that survives the gap matters more than the bytes it costs.

On paper it’s an infra project. In practice it’s the most autobiographical thing I’ve ever written, because I built a machine in the exact shape of my own missing function.

Look at what it actually does. An AI agent is sharp inside one session and then forgets everything the moment the context window closes. No persistence across time. Every session it wakes up with no memory of what it decided, what it tried, what it already ruled out.

I built Wizard because I was watching a machine have my exact bug, remember evaporates, and I knew precisely what it needed because it’s what I need. External state that survives the gap, and that resurfaces on its own at the start of the next session so nobody has to remember to reload it.

Wizard ships when nothing else of mine does, and I finally get why. It’s the one project where the thing I’m building and the thing I’m missing are the same thing. The motivation never goes stale because the pain never goes away. Every other project dies the moment the hard part is solved and the novelty drains out. This one stays alive because I’m still living inside the problem it solves. You want an ADHD engineer to actually finish something, point them at the tool that fixes the reason they can’t finish things. The loop closes on itself.

Forge, Wand, Ritual, and the thing underneath all of it

Once I spotted it in Wizard I couldn’t stop seeing it across my whole GitHub.

Forge is a business ops platform I built to run my 3D printing studio. Orders, cost calc, inventory, production, one source of truth. I told myself it was for the business. It’s for me. It exists so the operational state of an entire company lives somewhere outside my skull, where it can’t evaporate and can’t mutate into a 2am spiral of “wait, did I forget to order filament.”

Wand is my Neovim distribution, several thousand lines of Lua, sub-100ms boot because I have standards, full LSP and formatter and linter chain through Mason, Pomodoro and DAP and test running baked in. Ritual is a one-command, Chezmoi-managed bootstrap for my CachyOS and Arch machines with a Tailscale bridge to the Mac and drift detection, so any box I touch becomes mine in a single command instead of a two hour yak-shave I’ll abandon halfway.

The pattern is externalized cognition, top to bottom. Every tool I’ve built takes some function my wiring won’t do reliably, memory, environment, operational state, and lifts it out of my head into something that persists and resurfaces by itself. I didn’t set out with a philosophy. I just kept solving the same shaped problem until the shape got embarrassingly obvious.

My last post was about being dhobi ka kutta, na ghar ka na ghat ka, belonging to neither place. Turns out I’ve been quietly solving the same problem in code the whole time. If I don’t reliably belong anywhere, at least my state does, and it follows me from machine to machine on one command.

For the engineers reading this who suspect they run the same hardware

Two things, and they’re the whole point.

First, if your tooling feels like it matters more to you than it seems to matter to your teammates, that isn’t necessarily over-engineering. For a neurotypical dev, tooling is optimization, nice to have, shave a couple seconds. For a brain like mine it’s load-bearing, the actual difference between functioning and not. So stop apologizing for caring about it. The care is completely rational given the hardware you’re running.

Second, the principle that changed everything. Build systems that come to you. Push, not pull. The notification you didn’t ask for, the session state that reloads itself, the environment that rebuilds on one command, the memory that resurfaces without a request. Every system I’ve ever abandoned needed me to remember to use it. Every system that stuck deleted that requirement entirely. If you have to remember to use the tool that helps you remember, you’ve already lost, and it isn’t a character flaw, it’s just bad architecture for the machine you’re actually deployed on.

I spent years thinking I was bad at being organized. I wasn’t. I was running the wrong architecture and blaming the silicon. The moment I started building for the real hardware, the tools got good, and the reason they got good is that I finally believed they were serious infrastructure instead of a personal failing I was papering over with side projects.

The tools aren’t a workaround for the brain. For some of us the tools are the brain, specifically the parts that didn’t come standard.