I gave one person an AI army. Here's what broke first.

The setup, briefly, so the rest makes sense. There is an orchestrator that hands out work. There is a researcher that reads and verifies, a writer that drafts, a couple of agents that handle outreach. They live across a sprawl of repositories, they run on a small cloud server and my own laptop, and a scheduled job wakes them up on a fixed clock to do their rounds without me. One person, a lot of moving parts.

When people picture this breaking, they picture the AI saying something dumb. That happens, and it's the easy problem. The hard failures, the ones that cost me real time, had nothing to do with the model at all.

The robot that never woke up

I fixed the same bug three separate times. Each time I edited the code, saved it, watched the broken behavior happen again, and quietly lost my mind. The code was correct. The running process was still holding the old version in memory, because a long-running service doesn't re-read a file just because you changed it. It needed a restart I never gave it.

Nobody warns you about this. Your edit is real on disk and invisible in production, and the gap between those two facts will eat an afternoon before you think to look for it.

"Sleep: Never" is a lie

I told the machine to stay awake so the overnight jobs would run. It slept anyway. Modern hardware overrides that setting in ways that don't show up until a job that was supposed to fire at 3AM simply... didn't, and left no error because nothing ran to produce one. A silent failure is worse than a loud one. A loud one tells you where to look.

Secrets don't leak once

I found one exposed key, rotated it, felt responsible, and moved on. Then I found three more within the hour. The uncomfortable truth about secrets is asymmetric: a tool needs a credential in exactly one place, but everything that reads the state of your system (logs, error messages, screenshots, chat transcripts) can spill it somewhere you weren't watching. You don't fix a leak. You build the plumbing so leaks can't happen.

Two agents, one steering wheel

Give two automated agents the same shared resource and let them both reach for it at once, and you don't get twice the work. You get a crash, or worse, a quiet corruption where each one clobbers the other's changes. The fix isn't smarter agents. It's air-traffic control: a way for them to see each other and take turns. I learned that the plain way, by watching two of them fight over the same browser tab.

The memory that gaslit itself

I gave the fleet a long-term memory so it wouldn't relearn everything each morning. Then a three-week-old note started outranking what was true today, and the system confidently acted on stale information. Memory without a sense of freshness (when a fact was written versus whether it's still current) doesn't make a system smarter. It gives it a very convincing way to be wrong.

The part a buyer should take away

Here's why any of this matters if you're not the one building it. Every failure above is unglamorous: restarts, scheduling, secret handling, coordination, keeping memory honest. None of it is "AI." All of it is what stands between a demo that works once and a system that runs correctly, every day, while you're asleep or on a plane.

That's the actual job. The model is maybe ten percent of a reliable automation. The other ninety percent is boring engineering done carefully, by someone who has already stepped on these rakes so your business doesn't have to. When I tell a team I'll take a repetitive process off their plate and it will keep working, this is the work I'm quietly promising to do.

Built in the open, receipts and scars included. That's the point of these notes.