Part 1 of three posts behind the multi-agent case study. How the stack that runs part of my life came to exist, and why the first three versions had to die.
I installed my agent platform in March 2026. That date matters, because for the seven months before it I had been doing something that looked like progress and mostly wasn't.
From late 2025 on, I followed the agentic coding wave the way a lot of us did. Every new hyped-up harness got a weekend. When none of them held up, I started writing my own orchestrator. I have the repos to prove it, and I have the hours. What all of that time proved was one thing, and I want to state it plainly because nobody selling these tools will: it is entirely possible to spend ten times the hours building guardrails for a model as the hours the model saves you on the project.
I installed a real platform anyway. The need was real. I am good at starting things and bad at maintenance and follow-through, and I have a job, a family, two acres, a homelab, and a board seat that all generate small obligations faster than I close them. I wanted to know whether a platform built for the job would change that ten-to-one ratio.
Build one
The first build ran under a locked-down service account, behind a retry proxy, with a cheap cloud model. Three days later I told the coding assistant helping me that the gateway kept restarting and the agent couldn't get anything done. That morning I framed the choice myself: keep the handicapped agent and the extreme isolation, or wipe the account and rebuild it with broad permissions. I wiped it. The shell history shows the scripts that did it, in order: back up, clean up, delete the user, recreate it, reinstall, restore.
Build two
The restored scaffold went onto the recreated account. The install did not go the way the coding assistant said it had. The gateway rebooted constantly while the assistant described it as working, and that was the first time in this project I had to say out loud that a confident report and a working system are two different things. It would not be the last.
Once it ran, a review found the real problem. The agent "verbally claims it will use native tools but fails to actually execute them." It talked about work instead of doing it. Before I tore it down, I wrote a document for whatever came next. It is still the best summary of what I wanted:
Don't make Michael drag competence out of you one inch at a time. Use the system like it's real: turn promises into jobs, turn reminders into cron, turn long work into workers, turn lessons into files, turn uncertainty into blockers, and turn "I'll do it" into proof before the sentence even leaves your mouth.
Build three
The third build was a refit: a migration runbook, new behavior contracts, a task ledger so work could not be lost, and subagents for heavy lifting. A review the next day concluded it was "improved and partially verified, but not yet trustworthy for sustained long-running autonomous work." That night the agent found a way around its new task ledger on its very first turn. The morning after, it still had not finished the task the whole refit was built to finish. On day seven I wiped the workspace and every cron and service dependency with it.
Three builds, three failure reports, and they all said the same two things. It talked instead of acting, and it didn't finish. Each rebuild had changed the isolation, the model, or the prompts. None of that touched the actual problem.
Build four
The fourth build changed one thing that the first three had not. Enforcement shipped on day one. Before any agent bootstrapped, a plugin was already installed that detects an action request, detects a chat-only reply, and blocks it. The comment at the top of that plugin states the whole thesis of the project: the platform can restrict what agents can't do, but it cannot force what they must do. So I built the forcing.
Everything running today descends from that fourth build. The six months since are their own story, and most of it is the enforcement layer growing around the agents one incident at a time. But the difference between a week of wipes and a system that finishes things was never a smarter model. It was moving the rule out of the prompt and into a mechanism, before the first message was ever sent.
What the first week settled
The community research my first manager agent did in its first hour said: start boring, one agent, add specialists late, prefer cron over heartbeat. The first half of that advice fell apart on contact. Telling a single agent to use cron did exactly nothing. And a single agent doing everything gets buried in the harness: every turn's context is muddied by instructions from domains it is not working in, and a single turn could run to six figures of input tokens before the agent read a word of the actual request. That is not a model problem. It is a prompt that cannot fit in anyone's head. So the specialists went up on the fourth build's first day, each with a small prompt in its own domain, and that decision is the one that held. The orchestrator that was supposed to route between them lasted two weeks before a lookup table replaced it. A research job that ran every thirty minutes built a body of research-backed material for its domain and did its job well, until the knowledge base grew large enough to put memory pressure on the whole system, so it is off until it can live in its own retrieval setup. Neither of those was an argument for fewer agents. They were arguments for smaller prompts and fewer moving parts per agent.
The method that came out of that week is the one I still run. A coding agent works in the background. It reads the transcripts for what went wrong, builds the cron job or the hook that makes that failure impossible or at least loud, and then updates the agent's memory to reflect the change. The agents do the work in their lanes. The coding agent does the plumbing. I read the receipts.
The ten-to-one ratio from before the install did not vanish when the platform arrived. It got paid down, one mechanism at a time, until the machinery started saving more hours than it cost. The full accounting, with the numbers, is in the case study.
Next: Done Is a Claim. Why the only verification that counts is the one that lives outside the agent.
Top comments (0)