Writing about enterprise AI, multi-agent systems, and the craft of building software that lasts.
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.
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.
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.