I Built a Personal Assistant. I Use a Search Box.

So I built myself a Personal Assistant. Capital P, capital A. A few months of work. Autonomous routines, email triage, receipt collection, a whole suggestion engine with human-in-the-loop approval. I was pretty proud of it.

Last week I ran an audit on my own tool usage. Four weeks of logs, about 35,000 tool calls. Wanted to see what I actually use day-to-day.

The Personal Assistant showed up in 0.3% of the data. A hundred calls, mostly from the automated diary thing I'd forgotten was running.

So that's fun.

How This Happened

The PA wasn't my first project. The first project was the personal knowledge base, and that one I'd been wanting for years. Semantic search over my documents, emails, calendar, conversations. A way to ask "what did we talk about with the client last month?" and get an answer instead of digging through Slack history, GitHub tickets, and emails for twenty minutes. I thought about it for a long time before building it. Considered the architecture. Worked through the edge cases. It's a big system with a lot of depth, and I gave it the deliberation it deserved.

The knowledge base worked. I use it constantly. That wasn't an accident; it was the result of years of wanting it and months of building it carefully.

The PA seemed like a natural next step. The knowledge base was reactive (I search, it answers), so why not make something proactive? It would process my email overnight, draft responses, surface things I'd missed. Cool project, right? The kind of thing you'd put in a conference talk.

Maybe I didn't give it the same thought. I just started building, wanting to automate the leg work for tasks I was already doing. A few months later I had a sophisticated system that I barely use.

The Warning Signs I Ignored

The PA had problems from pretty early on, and I just... kept building anyway.

The overnight email drafts were stale by morning. I'd already handled the urgent stuff from my phone before getting to my desk. The drafts the PA prepared? Outdated before I saw them. But I figured I just needed to tune the timing. More engineering would fix it.

The workflow was wrong too. The PA wanted me to work in its interface. Check the suggestion queue every morning. Review what it found. Approve or reject. But I don't work that way. I live in Slack and my terminal and Emacs. Switching to a separate approval UI felt like homework. I'd skip it for a day, then two days, then I'd stopped opening it entirely. But I figured I just needed better notifications, maybe a CLI interface. More engineering.

And then there was the deeper problem, the one I kept not admitting to myself: the AI was doing work I'd just redo anyway.

The PA had human-in-the-loop from the start. I designed that carefully. It suggests, I decide. But the processing, the synthesis, the draft generation... it pushed too far into my side of that boundary. The summaries weren't wrong exactly, but they weren't good enough. The drafts needed rewriting. I'd read what the PA produced, think "that's not quite right," and end up doing the work myself.

When a Slack message came in that needed a real response, I'd write it myself. Or I'd pull up Claude Code, use the knowledge base to dig up context, and work through the reply in conversation. Back and forth. "What did we decide about this last month?" Here's what I found. "Okay, draft a Slack message, let them know we're looking into it." Send it, then back to Claude Code: "Also, let's create a task so I remember to follow up."

That's the loop that works for me. The PA's suggestion queue didn't have that. It was one-way: here's a draft, approve or reject. No conversation. No "make it shorter" or "wait, add the context about the deadline." Just a finished product that was never quite right.

By the time the PA had batched and processed and drafted something, the conversation had moved on anyway. The async model that looked elegant on the whiteboard was just latency in practice.

I kept tweaking. Better prompts. Faster processing. Different schedules. The friction never went away because the friction wasn't a bug. The friction was the design.

What the Numbers Said

The audit logs for the last four weeks were kind of embarrassing in hindsight.

Knowledge base tools: 884 searches. 293 document reads. 206 document updates. Notes, tasks, context lookups, all day long.

Personal Assistant: the automated diary, basically. Everything else I'd built? Gathering dust.

The knowledge base loop is simple to describe: find context, do work, save what you learned. But there's depth behind that simplicity. Years of thinking about what I actually needed. Months of building it carefully. Routines that keep the data current. A system that fits how I think because I spent the time figuring out how I think.

I use it hourly. Sometimes more. It's become invisible the way a good tool becomes invisible (you stop noticing it because it's just part of how you work).

The PA, which got less of that deliberation? I think about it when I'm looking at the systemd service list and wondering why it's still running.

The ettool lesson I already knew

Here's the thing: I've done this before. And that time I was quicker about it.

I have an exploratory testing tool called ettool. Voice capture, browser automation, structured findings. At one point I built a real-time voice detection feature for it. The idea was the AI would listen while I tested and automatically classify my observations as bugs, issues, or comments. Cool tech. Worked.

I tested it for an afternoon, hated it, and then discarded it.

The problem was that it second-guessed me. With hotkeys, I decide in the moment: this is a bug, this is just an observation. With voice detection, the AI made that decision based on whatever it heard. It would mark clear bugs as "observations" or detect the same issue repeatedly with different classifications. I'd lost control of my own findings.

That took me an afternoon to figure out. Build it, test it, learn from it, discard it. No drama. The lesson was clear: AI should assist, not decide.

The PA? Same pattern. Same problem even (the AI making crossing over the suggestions/decisions line, where that should be mine). But this time it took me months to reach the same conclusion. The only difference was that the PA was more impressive, more conference-talk-worthy, and I'd invested more time. So I kept tweaking instead of stepping back.

Why I Kept Going

I kind of knew something was off months ago. The logs showed declining usage. The overnight summaries felt less relevant. I was finding excuses not to check the suggestion queue.

But I'd put months into it. The architecture was sound. I'd designed the human-in-the-loop stuff carefully, thought through the trust model, built proper guardrails. Subconsciously I felt that abandoning it would be like admitting the architecture was wrong. Sunk cost fallacy.

The architecture wasn't wrong, though. I still think the design is solid. It's just a solid design for something I don't need. The PA is a well-built system for a workflow I don't have.

I kept building because it was interesting. Because "I built a personal AI assistant" sounds better at parties than "I built a search index over my documents." Because I'd already invested the time.

The ettool taught me that you can build something, learn from it, and let it go. The PA taught me that I can also ignore that lesson when the project is shiny enough.

What I Actually Learned

A while back I wrote a post about the PA's suggestion system, about why I chose human-in-the-loop over autonomous action. I still think that design was right. The problem was that I applied it to the wrong thing. The PA's suggestions were thoughtful and well-formatted and completely beside the point.

The knowledge base works because it meets me where I already am. I'm in the terminal. I need context. I search. I get it. The PA failed because it wanted me to come to it. Check this queue. Review these drafts. Adopt this new workflow. And I just... didn't want to.

I have every advantage here. I'm building tools for myself, bespoke for my workflows, with immediate feedback when something doesn't fit. I've spent a career testing software and understanding how users actually work versus how designers think they work. If anyone should be able to build the right thing, it's me building for me. And it still took me months to see the mismatch. Imagine being stuck with a tool designed by someone who's never done your job.

The friction wasn't a bug. The friction was the design. That's the lesson.