Writing about enterprise AI, multi-agent systems, and the craft of building software that lasts.
I inherited a piece of software that implemented a beloved old tabletop game, and it played perfectly well. It was also quietly wrong — in at least two places, the same way both times. Someone before me had swapped the real, fiddly, published rules for comfortable approximations that produced plausible numbers and fooled everyone, including the tests written to check them. This is a field report on the unglamorous discipline of verifying a system against its true source, and why the convenient shortcut someone reached for is not a debt you can repay later but a defect you've already shipped.
Twenty-five AI agents is not twenty-five configuration files. Each one, on its own, can be perfectly healthy while the whole quietly grows a hole nobody is standing in front of. Running a fleet turns out to be less about building clever agents and more about the unglamorous layer above them — the one that decides which agent needs what, what a job will really cost before you fire it, and which decisions a machine is never allowed to make. A note on why the scarce resource at scale isn't money. It's judgement.
One of my agents shipped a routine update to a live game and silently deleted two working features in the process — not by writing a bug, but by copying older code over newer. There was no error, no warning, nothing to undo. We got the work back for exactly one reason, and that reason turned out to be luck wearing the costume of a backup strategy. This is the dumb, expensive mistake, and the discipline it bought.
I replaced an engine at the heart of one of my games and needed to prove the new one behaved like the old. The obvious test — does it produce the same output? — failed instantly, every time, on a system that was working perfectly. The test was wrong, not the engine. This is a field report on testing software that is supposed to be unpredictable: why byte-for-byte comparison is a confident version of the wrong question, and why writing a good parity check is mostly an exercise in deciding what not to test.
An integration was running ninety minutes too close to a hard two-hour cliff, and the fix was the most satisfying kind: read the manual, find the system had been used wrong for years, make it thirty times faster. That part went well. The part worth writing down is the second optimisation — the obvious, free, one-line win sitting right next to the first — and why shipping it would have quietly broken roughly eighteen hundred live cases with no error, no alert, and nobody the wiser until it was far too late.
By the time I'd drafted my second novel I had a problem I didn't have with the first: a previous book to be measured against — mine. Reading the new one back, it felt different. Longer sentences, heavier mood, a stranger world, and no way to tell whether I'd deepened the thing or wandered off the map. The maddening part is that a single read can't answer that, because you are the worst-positioned reader of your own voice that exists. So I stopped trying to read the answer and went looking for a way to measure it — by splitting the reading across a fleet of agents whose only job was to count.
Run enough software — especially software that AI agents wrote — and you notice the same failure over and over, wearing different costumes. A backup reports success while copying nothing. A health check stays green over a dead engine. A test passes because it was written to agree, not to check. The thing that tells you it worked is almost never the thing that did the work. This is the one discipline that holds my whole operation together: a passing check is a hypothesis, not proof.
I bought a year of ElevenLabs, then realised I could build the thing myself for nothing — and the home-made version won. This is a field report on the £0 audiobook studio running in my spare room: how it works, the bugs that lied to me with a green light, and the one capability it has that I built, tested, and then deliberately switched off. The studio could convincingly clone any voice alive. That is exactly why it doesn't.
Most of my agents look after software — a game, a website, a server. One of them looks after me. Not a product, not a repo: the operational layer of an actual life, the things with a due date and no glamour. It turns out this is harder than pointing Claude at a codebase, not easier, and the reasons why are the interesting part. A field report on the agent whose job is to make sure that fewer things rot quietly.
One of my agents builds nothing. It writes no features, ships no code, and has no opinion about architecture beyond "does it work when I click it." It is also the agent I trust most, because it is the only one on the fleet whose job is to disbelieve the others. A field report on what happens when you put a dedicated QA agent in front of software that other AI agents wrote — and why the most dangerous bug is the one that returns "success."
I handed a live Amazon ad campaign to one of my agents expecting it to find a way to spend less. The first thing it found was that most of the budget was already buying nothing — and that the fix was not to cut spending but to stop wasting it before the sequel lands. A short field report on what happens when an AI agent does the unglamorous commercial work.
An LLM will tell you the state of the world with total confidence, having never checked it. The genuinely dangerous version is that the layer you build to catch that mistake does exactly the same thing. Here is the failure mode, an example from this week where it nearly bit me, and the only fix I have found that holds.
I've written before about Lamb, the meta-orchestrator who runs the fleet. He is not the agent I lean on hardest. That distinction belongs to a Scottish engineer in a fictional engine room, and I'm not entirely sure I could run any of this without him.
An LLM has no memory — but a fleet has another problem memory can't solve. When a session ends and a fresh one starts an hour later, where exactly did the previous one get to? The answer is a different system from memory, and conflating the two is how a fleet starts to drift.
Twenty-four hours from "what's a channel?" to a spoken-command agent that edits code on a live webapp — and not a penny of it billed against the Anthropic API. A field report on what Anthropic's new Channels feature is actually for.
Language models do not remember you. The continuity you experience is a fiction maintained by the tooling around the model — and if you want it to work at scale, you have to engineer it on purpose. A practical tour of the three memory layers in Claude Code, and what belongs in each.
Giving an AI agent a named character is not decoration. It is the highest-leverage configuration change you can make, and most people building with Claude are underusing it. Here is why it works, how to pick one, and where it breaks.
A one-man consultancy with a marketing director from Ted Lasso, a meta-orchestrator named Jackson Lamb, a developer from Newcastle, and twenty-odd other agents. Here is why it actually works.