The week I almost built the wrong thing

Third one.

I wanted the thing every operator wants: my AI team working while I’m away from the desk, and a tap on my phone when it needs a yes. So I wired up notifications. When a session finished or hit a decision, it messaged me.

The first messages were junk. “Output ready to review.” “Login successful.” “Claude is waiting for your input.” Session plumbing, not decisions. A phone full of that is a phone you stop checking, and a notification you’ve learned to ignore is just a gate standing open. So I fixed it. I made the messages carry the real decision: which client, the wedge in a sentence, the two or three options in front of me, and for a finished preview, a tappable link. Now the message was worth reading.

Then I went one step too far, and this is the part worth writing down.

I wanted to reply. See the options on my phone, tap “1,” and have the next step actually run. The obvious path was to make my messaging channel two-way: a small service on the always-on machine, a token, a connection held open to catch my replies. I had the whole plan. I was about to build it.

Then it landed. That’s a daemon. A service to babysit, tokens that expire, the first always-on app my little files-and-prompts setup would have to keep alive. My own pipeline notes name this exact move as the warning sign: the moment you’re compulsively turning the repeatable parts into software is the moment software is quietly becoming the point. So I went and checked what Claude already ships before building anything, and it turned out I was about to reinvent not one native feature but two. Remote Control bridges a live session on my machine to my phone, so I can watch it run and approve or redirect from the couch, and it stays on my machine the whole time. And there’s a built-in way for a chat app to poke a session, which is the exact listener I was about to hand-build. I nearly spent a weekend rebuilding two things that already exist, and took on a running service to do it.

Here’s the distinction I’d missed, and it’s the whole lesson. Notification and control are two different jobs. A message that says “here’s what needs you” is a mailbox, and a plain one-way channel is fine for that. Driving the work, replying and having something happen, is control, and that isn’t a mailbox’s job. The machinery I was about to build was the wrong machinery. The right amount was none.

So I killed the listener idea before it existed. The channel stays a mailbox. For actually acting from my phone, I’m testing the native path, the way the model always said to.

The skill this is supposed to teach isn’t building more. It’s noticing when you’re about to build the wrong thing, and stopping. I nearly failed my own test this week, on my own business. The catch is the part worth keeping.