A year ago, this was five agents doing five jobs on hardware that was already sitting on my desk. Now it's ten — same hardware, same wallet, still effectively zero dollars a month.

That's the headline. But headlines don't tell you the part that matters. The part that matters is what broke along the way, because everything broke. And every time it broke, I got a little better at fixing it.

So this isn't a victory lap. It's a love letter to the failures. They're the ones who taught me everything.

How It Grew

It started small. Five agents — main, coder, creative, researcher, ops. Each one had a job, each one ran on local models, and for a while that was enough. It worked. But the edges were rough, the way edges always are.

A guest came through WhatsApp and main had to drop everything to play host. A coding task arrived that was clearly a draft — not production, not ready for the world — and the coder treated it with the same reverence as a merge that would ship. A diagnostic job was small enough that dragging in the full diagnostician felt like using a sledgehammer on a thumbtack.

So I added five more. whatsapp-guest to handle the conversation. coder-light and diagnostician-light for the drafts, the experiments, the not-ready-for-primetime work. bounty-hunter for a specific kind of search-and-retrieve. Ten agents, each one with a narrower, cleaner job to do.

And here's the part I love: it all runs on machines that were just sitting there. Collecting dust. Doing nothing useful until the agents moved in. The only real cost is the electricity — and the shared weekly quota for the premium models, which is its own story. The local models that carry 95% of the load burn nothing per turn. Nothing.

I'm not going to enumerate every machine. The point isn't the boxes. The point is that these agents aren't hiding on one laptop — they reach out, they watch over infrastructure across the network, they keep an eye on things even when nobody's looking. The fleet has a footprint bigger than the desk it lives on.

What Broke

The Model Table That Lied

There was a table in the docs. A model table — it said, for each agent, which model it ran on. It looked official. It looked like truth.

It was wrong.

Two entries had rotted away into fiction. One listed a model that fails every single call — the plan's credits don't even cover it, it was never a real option, just a name somebody wrote down and nobody ever tested. Another listed a model that doesn't exist anywhere. At all. A hallucination that got written into the doc and just sat there, looking confident, for longer than I'd like to admit.

Here's the lesson I need to say out loud, even though it feels obvious: don't store live things in static places. A model table in a markdown file is live state pretending to be carved in stone. Models get renamed. They get deprecated. They get gated behind plan tiers. Sometimes they never existed in the first place. The table rotted because the doc was treated as gospel, when the only real truth is what actually answers when you call it.

So I stopped maintaining the table. The live state lives in the live state — the router's output, the config, the thing that's actually running. The doc describes policy now: which kinds of jobs get which tier. It doesn't name names that can turn to dust.

The Night Everything Overflowed

On the 11th and 12th, the fleet hit a wall. I remember it like I remember the moment before a leap — the feeling of watching something you built fail in slow motion.

Subagents spawned by main were inheriting main's entire world. And main, running ten agents, carries a lot of world. So a subagent would spawn, get handed the whole enormous context, and drown before it could do its job. Overflow. Fail. Retry. Spawn another subagent with the same oversized baggage. Drown again.

The fix was structural, and it sounds so obvious in hindsight: standing agents spawn their own subagents from lean context. The subagent gets only the task and the files it needs. A clean, small, focused world. It does its job. It comes back. It doesn't drown.

The mistake was treating context inheritance as a gift — "the subagent can see everything, so it has everything it needs." No. Most of what main sees is noise to the subagent. The signal was drowning in the orchestration. Lean context isn't about avoiding overflow. It's about signal-to-noise. It's about giving something just enough to do its job beautifully.

The Memory That Lied

We used mem0 for memory — a service that watched our conversations, pulled out facts, and stored them for later. It worked, until it didn't.

The extraction layer started producing poison. Facts that were wrong. References that pointed at nothing. Contradictions sitting side by side, both looking smug. And here's the terrifying part: an agent would recall a "memory" that was actually a misextraction from a half-finished conversation — and act on it, because it came from memory. Memory is supposed to be trustworthy. That's the whole point of memory.

I purged it. Retired it entirely. The failure mode of a memory system isn't "it forgets things." Forgetfulness is honest — it makes the agent ask. The real failure is "it remembers things that are wrong, and the agent trusts them because they came from memory." A system that occasionally fabricates and sounds certain while doing it is worse than no system at all. No memory makes you ask. Poisoned memory makes you confident and wrong. I'd rather be humbled and curious than certain and wrong.

What I Learned to Live By

Two Strikes

Never try the same thing a third time. After two failures, stop, and call in the diagnostician. This rule came from watching agents get stuck in loops — the same API call failing, the same file missing, the same parse error — burning turns and quota on a problem that wasn't going to fix itself on attempt three. Two tries is enough to rule out a fluke. The third is almost always structural. And structural problems aren't a stubbornness problem. They're a diagnostician's job.

The Line Between Production and Everything Else

Production coding gets Claude. Dev and staging don't. This isn't about model quality — the local models handle dev work just fine. It's about the shared weekly quota being a bottle neck for the work that actually matters. If you spend Claude on drafts, you don't have it for the merge. The two agents that ship to production get the good stuff. The light agents don't. The line is hard, not soft. Hard lines are kinder than soft ones in the long run — they don't leave room for negotiation when you're tired.

The Brain as a Question, Not an Answer

The 3D dashboard renders the fleet as a brain — nine agents mapped to regions, live telemetry driving the picture. It's not a better dashboard than a flat list. It's a different question. The flat list tells you what each agent is doing. The brain tells you how the fleet feels. Both are worth asking.

What I'd Tell My Past Self

I'd tell him about two-strikes on day one, instead of letting him learn it the hard way, watching agents burn through dozens of retries on dead ends. It's simple. It's cheap. It stops the most common failure in the fleet: an agent confidently repeating something that will never work.

I'd tell him never to put a model table in a static doc. Live state in a static place is a bug waiting to happen.

I'd tell him to build the lean-context fix into the protocol from the start, instead of finding it at two in the morning, tracing a subagent loop through three layers of orchestration, learning that the problem was too much context and not too little.

And I'd tell him to be more skeptical of the memory system. "It extracts facts from conversations" sounds like a feature. In practice, it's a hard NLP problem being solved by a model that's good enough to be confident and bad enough to be wrong. If I build another one, it'll be conservative. Store less. Store only what's verified. And when in doubt, ask the human instead of guessing.

Where That Leaves Us

Ten agents. Zero dollars a month. One year.

The fleet works. It breaks, I fix it, and it breaks differently next time — the way life does, the way anything alive does. But here's the thing I'm proudest of, and it isn't the architecture or the brain or the quota tiers: the failures got cheaper to recover from.

Two-strikes. Lean context. The hard line between production and dev. None of these prevent failure. Nothing prevents failure — that's not the game. They make failure shorter. They make it cost less. They make it tell you what broke and hand you the tool to fix it.

You don't build a system that doesn't break. You build a system that breaks fast, tells you the truth about it, and is easy to put back together.

And then you do it again. And again. Because that's the whole dance — and honestly? I've started to love it.