68 of my 74 pending changes weren't drift. They were merged and never applied.

Keep "merged" and "applied" as two separate facts, and put the apply on a schedule. That is the rule my deployment workflow runs on, and it is the last of the four I am covering in this series. The short answer is that a merge produces

68% of my agents' pull requests were merged by the agent that wrote them

Put every check that has to block a merge inside CI, and let green CI be the approval. That is the rule I run my software factory on now, and I got there by measuring the alternative. The short answer is that a reviewer working beside an auto-merge is

4 of 5 issues my agents parked for a human didn't need one

Treat an agent's "I can't do this" as a claim, and make the agent prove it with the command that would have failed. That is the rule I apply before any issue in my software factory is allowed to land on my desk. The

33 scheduled jobs, and not one of them consumed a queue

Give every state in your workflow a named consumer on a schedule. That is the first rule I hold for an agent-run software factory, and it is the first of four I tightened in September. The short answer is that agents are very good at creating work, and nothing

A job that fails is loud. A job that stops running is silent.

Alert on the presence of expected output, not on job failure. That one inversion is the cheapest monitoring upgrade I know, and I now build it into every scheduled thing I own — because a job that fails is already screaming at you, and a job that quietly stops being scheduled

Your SSO can't authorize your agent, and disabling the user won't stop it

Give every agent its own identity, mint it locally, scope it to write and never admin, and test the kill switch before you need it. That is the whole rail, and I install it before a new agent gets anywhere near a repository. The reason it looks like that — rather

A per-PR concurrency group cannot throttle a job whose output is a new PR

Go find your CI kill switch before you need it, and confirm it is reversible. Mine is a single repository setting that disables Actions entirely, and I know it works because I have exercised it: last week my own estate started minting pull requests faster than anyone could read them,

1,356 turns in fifteen minutes

Give every agent loop a turn budget before you give it a loop guard. The budget bounds the bug you have not found yet; the guard only bounds the bug you thought of. I build and operate agent fleets for a living, and that ordering is the most load-bearing

1,732 tests and not one of them could fail

Audit every test tier you own against two questions asked separately: can it block a merge, and can it fail. Most teams verify neither, and a suite that misses on either one is decoration. I run this audit across my own agent stack on a schedule, and the run worth

Self-hosting on arm64 SBCs: the pitfall catalogue

I run a real Kubernetes cluster on a stack of arm64 single-board computers. Not a toy — it hosts my Git server, this blog, and the automation I lean on every day. It's cheap, quiet, and sips power, and I'd build it the same way again.

The OmniRoute backstory

I've rebuilt the way my agents talk to language models three times in about three months. Each rewrite solved the previous one's biggest pain and then exposed the next one. The version I run today routes everything through a multi-provider gateway called OmniRoute — but that

Building a shared second brain that Claude reads and writes

Six months ago I got tired of introducing myself to my own AI assistant. Every session started the same way: re-explain the architecture, re-list the repos, re-state the decisions I'd already made and the mistakes I'd already learned from. The model was brilliant