Writing
What we're building, what we're testing, and what we learned doing it.
- A harness with 122 guidance documents produced 703 tickets in ten weeks. Seven hooks replaced it
We built two harnesses for the same job: keeping a coding agent on course while it builds a product over months. The first was a marketplace of seven plugins, parallel by design, with 122 documents telling the agent how to think. It produced 703 tickets in ten weeks on one project, a third of them still open, and a rulebook that grew to 442 lines before we cut it to 90. The second is one plugin, serial by design, with six commands and seven hooks. It replaces most of the rules with checks that refuse to let bad things happen. The first harness optimised for how much the agent could do at once. The second optimises for how much a person can still understand.
- Every failed project we have seen was missing one of the same three things
Software projects inside operating companies fail in three recognisable ways, and each way is missing one of the same three things: a plan that never gets built, a build aimed at the wrong problem, or a working system nobody uses. We think that is one problem with three faces, and that the fix is structural: strategy, operations, and engineering done as one piece of work by the same few people.
- Our MCP server had 32 files of documentation. A headless agent could read none of them
We built a tool that measures whether an agent with no context can use an MCP server correctly, by running one against it and reading what it did. We ran it on two of our own servers on the same day, with the same model and the same harness. On the first, the agent needed 11 turns and got the right answer by a method it admitted was luck. On the second, it needed 5 turns and told us exactly how far to trust it. The only difference was what crossed the wire. Everything the first server "documented" was sitting in files no remote caller can open.
- Our agent rulebook grew to 442 lines in six weeks. Cutting it to 90 is what made it a harness
The serial harness did not start as a plugin. It started as a 32-line instruction file in one project and grew, over six weeks, into a 442-line rulebook that the agent could not follow and the team could not maintain. Cutting it to 90 lines and moving the rules into hooks is what made it a harness. This post walks the strain points in the order they hit, what each change fixed, what it cost, and the point where adding more stopped paying.