The part of AI I couldn’t design from the outside

Last week the assistant on my Mac Mini stopped answering. The error said HTTP 429, too many requests, and then reported the limit as zero requests per minute, which is a strange thing for a rate limit to say. Zero isn’t a ceiling you hit. It’s a door that closed. Working out the difference took an hour, and the hour was worth it, because the wrong reading would have had me buying a second subscription to fix what turned out to be an expired card.

For thirteen years I designed enterprise software, the last five of them leading design across Webex Calling at Cisco. Latterly that meant AI features: a receptionist that answers a business’s calls, a contact center layer an admin can switch on for any call queue with one toggle. My job was the surface where someone decides what the AI is allowed to do, and then finds out what it did.

I was good at that job. But it has a gap I couldn’t close from inside it, and the 0/0 error is the shape of the gap. Designing the admin experience for an AI system doesn’t make you responsible for one. You can spend years building the settings page for a thing you’ve never had to keep alive, and the work will still be good, and you’ll still be missing something. I knew that before this year. I just didn’t have a way to fix it while the calendar belonged to somebody else.

the notice period/

On May 13th I was told my role was ending, part of a global restructuring that took about four thousand people with it. My last day was July 13th.

So I had two months, a salary, and a decision. Spend it looking for the next job, or spend it becoming someone with a different toolkit and take the search later.

The first few weeks went to a break I’d been postponing and a backlog of personal things I’d been postponing longer. After that the question got sharper rather than easier, and I sat in it for a while. Looking immediately was the responsible-sounding answer. It was also the one where I’d walk into interviews describing AI work I’d designed but never run, which is exactly the gap I’d just been given time to close.

I picked the toolkit.

There was a Mac Mini on a shelf in the house, bought months earlier, still boxed, never switched on. Not switching it on had started to feel like a small ongoing verdict on my summer.

what I built instead of a job search/

I spent about a month planning before I plugged it in. That sounds like procrastination and partly was, but the plan went through four versions in the two days before first boot, and most of that arguing was about what not to build. It booted on July 3rd. It’s been running since, and I’ve spent nearly a month getting it to a state I’d actually vouch for, deciding each piece rather than accumulating it.

It’s called Kai. It’s headless, it sits in a corner with a plastic plug in the HDMI port pretending to be a display, and I talk to it from my phone. There’s a small team on it rather than one assistant: one that plans and routes work, one that takes in whatever I throw at it and files it, one that looks after the machine, one that builds. They share a brain made of markdown files under git, readable by me in a text editor and by them at boot. That readability is most of the argument, and a later post in this series makes it properly.

A little over three weeks in, the honest state is that it works and it isn’t finished. It files notes I drop into a Discord channel. It runs scheduled jobs without me. It also went down twice in five days, once because a card expired and once because a token got revoked upstream, both times taking the assistant and every scheduled job with it, and both times for reasons that had nothing to do with the code and everything to do with a call I’d made weeks earlier and written down at the time as an accepted risk. This weekend it went dark a fourth time, for the dullest reason yet: it ran out of tokens. The next post takes the full set apart.

That’s the sort of thing I wanted to learn. It’s not the sort of thing that shows up in a demo.

what this is/

This is the first of these, and I’m not going to put a number on how many follow. The build keeps producing things I hadn’t planned to write about, which is most of the reason it’s worth writing about at all.

What’s queued: the shape of the system. The documentation method that turned out to be load-bearing, and why the first readers of those documents are the agents. What changed when I went from directing one AI to running a staff of them with different memory and different permissions. The security posture for a machine whose newest resident is an autonomous agent. And what the whole thing costs to run, with the real numbers, including the three days that outspent a monthly subscription doing far more work.

It isn’t a tutorial and I’m not suggesting you build one. Almost none of the interesting parts were technical. The interesting parts were decisions: what to refuse, what had to exist before what, when to hand something over and when to keep one hand on it, and which of my own earlier calls fell apart once real money and real uptime were involved.

I’ve spent my career designing systems meant to make AI accountable to the people using it. It seemed worth finding out what that costs when the person on the hook is me.