Factory journal
Check it exists, then check it ever worked
TL;DR: We run a small software business in which AI agents do most of the building, and every agent starts each task with no memory of the last. A worker like that will cheerfully make a second hammer when one already hangs on the wall. On October 1st we made “do we already have this, and has it ever worked?” a check that the system runs before any build begins. The second half of the question turned out to matter more than the first.
The insight
A human team remembers what it owns. Someone has been around long enough to say “we have a script for that” or “we tried that and it never worked”. A business run by AI agents has nobody like that. Each worker starts from nothing, reads its brief and gets on with it. Asked to build a thing, it builds the thing, whether or not one already exists. This is neither laziness nor malice. It is what you get from a workforce with no long memory and a strong bias towards action.
So “do we already have this?” cannot be left to the worker’s judgement. It must be a step that the machinery checks before the build begins, and the machinery must be able to refuse. The question has a second half that is easy to forget: “has it ever worked?” A capability that exists in the code but has never produced a result is not a capability. It is a rumour. Treat it as real and the business comes to believe it can do things it has never once done.
In practice
On October 1st we added a check at the point where a build task is handed to an agent. The brief must now say what the business already owns that does the job, or comes close, and the handoff refuses a brief that says nothing on the point. Behind the check sits a small command that answers two questions about any named capability. Does the business have it? And is there a record of it running and succeeding? Existence is read from the code. Working is read from the record of what the thing has done.
The second half earned its place the same day. Our standard recipe for bug-fix work, which every such task is supposed to follow, had sat in the repository for weeks. But the task tracker, which is where a worker looks, could not find it. To any agent that asked, it did not exist. The recipe existed and did not work, which is exactly the state the question is meant to catch. We repaired the link, now refresh it every hour, and added a test that every recipe the tracker should know can in fact be found.
What we’ll try next
The same question applies to research, because agents re-research as readily as they rebuild. We want the “what already exists” line to cover prior research notes as well as tools. We also want the answer to “has it worked?” to be a date rather than a yes. A tool that last succeeded in July makes a different claim from one that succeeded today.
One honest number
The day’s plan digest listed eight items of work in progress and reported that none of them, zero of eight, served a named key result. The quarter’s objectives have not yet been ratified, so there was nothing to align to, and the digest said so rather than leaving the column blank. That is the right behaviour. A report that prints “0 of 8” with its reason attached is more useful than one that hides an empty column. It is also a fair test of building in public: the number is poor and we are printing it anyway.
Sources — every claim traces to a receipt
- The day's merged changes to the factory: a reuse check before any build is handed to an agent, a command that reports whether a capability exists and has worked, and the repair of the task tracker's view of the committed work recipes
- The day's plan digest, which reports how many planned items serve a key result
- The daily intake learnings for October 1st