Six months of agents in my apartment
I've run a fleet of AI agents on a Mac Studio at home since spring. What held up, what didn't, and the failures that looked exactly like success.
· 2 min read · agents · lab
Since spring, a Mac Studio in my apartment has run a small team of AI agents around the clock. They pick up scheduled work, build small prototypes, review each other’s output and post results to a room on my own Matrix server. I can read that room from any device. (The setup is drawn out on the lab page.)
I expected six months of this to produce a self-improving system. It produced something more modest and more useful: a lot of hard-won knowledge about running software that nobody is watching.
What held up
One agent writes, another checks. Nothing lands on a single agent’s say-so. A separate reviewer reads the change, and pull requests to shared projects go to a human. It is the backbone of the whole setup.
Every loop has an off switch and a budget. Each scheduled job has a kill switch and a spending cap. Turning things off is a feature you design, not an emergency you improvise.
Isolated workspaces. Every task gets its own git worktree. Before that, two sessions editing the same folder raced each other and quietly overwrote work.
A control room I own. Matrix gives me one place to see what happened, from any device, on a server I run myself.
What didn’t
Output nobody needed. The fleet published content on a schedule. It went out reliably and almost nobody engaged with it. Reliability isn’t the same as value.
Prototypes that don’t compound. The agents built plenty of small prototypes. Few of them built on the last one. Without a person deciding what matters, the work spreads sideways instead of stacking up.
Self-healing is hard. Agents can restart a crashed service. They are much worse at noticing a service that is running and doing nothing useful.
Failures that look like success
The most expensive lesson was that broken systems usually report that they are fine.
- A job scheduler showing exit code 0 is reporting the last run, not current health.
- A message script can exit cleanly without delivering to the room it was meant for.
- A dry-run flag left in a production config produces perfect, fake success.
- An update can quietly reset local changes, so a fix you made last week disappears.
- A long-running agent with an overflowing context will happily continue from assumptions that stopped being true hours ago.
The fix is the same each time: check the actual output, not the signal that says there is output. I collected the full list, with mitigations, into a small Agent Ops Starter Kit, which is private for now.
Where it goes next
The fleet isn’t going anywhere. What changes is my role in it. Agents are very good at executing a well-defined job and very bad at deciding which jobs are worth doing. I am going to keep the second part.