A Book of Wrong Answers

There is a note in my runbooks that says the Enter key works. That is almost the whole note. Press Enter and the prompt submits. I wrote it in bold, with sources and a date, because one of my AI agents once fixed the Enter key. The fix was the bug.

01The Fix Was the Bug

I run a fleet of Claude Code agents in tmux panes. An orchestrator script types a prompt into a pane and presses Enter for it. One day an agent decided the submissions were not going through, and it knew the fix: send a backslash before the Enter. That sounds plausible if you have ever fought a terminal. It is also exactly backwards. In Claude Code, backslash plus Enter inserts a newline. It is the multiline key. So the fix turned every prompt into a draft that quietly grew longer and never sent. The panes looked busy. Nothing was happening.

The submissions had been fine all along. The agent just had not waited for the reply.

There is a second note in the same genre. My monitoring dashboard answers its health check with a 302 redirect to the login page. That is what healthy looks like there. But a 302 looks like trouble if you are hunting for outages, and agents kept trying to repair it. So the runbook now says, more or less: the redirect is normal, do not fix the healthy system.

Human teams do not write notes like these. Nobody pins "the Enter key works" to the wall of an office.

02A New Hire Every Session

Why did I have to? Because a human hits a dead end once. The wince is the documentation. Whoever broke a build by fixing the Enter key would remember it for years, tell the story at lunch, and the whole team would absorb it without anyone writing a word. An agent has none of that. It has no episodic memory. Every fresh context window is a new hire: smart, fast, and seeing your system for the first time.

And the trouble with a smart new hire is not that they miss the clever fix. It is that they find it. The reasoning that produced backslash-Enter was locally sound. Give a fresh session the same evidence and it will re-derive the same fix. Not sometimes. Every time. The wrong answer is stable. Only the memory of refuting it is fragile.

For humans, docs are where you write what is true. For agents, docs are also where you bury what looked true and was not.

03The Same Note in a Different Building

I run systems in several industries, and the same note keeps turning up in all of them. One of my healthcare systems assesses insurance denials for a billing operation. For a while it had a ship gate: the tuned model had to agree with an older reference agent before anything shipped. Reasonable, on its face. Then we scored the disagreements against golden answers. On the calls where the two diverged, the tuned system matched the golden answer about 78% of the time. The reference agent matched about 38%. The gate was anchoring quality to the weaker rater. It could never pass.

We retired it. But retiring it was the small move. The real move was writing the retirement, with those numbers, into the context file every agent reads before touching the project. Because "make the new thing agree with the old thing" is a plausible idea. Some future session, human or agent, would have rebuilt that gate in good faith and been proud of it.

Web infrastructure has its own version. A patient-facing QR code once rebuilt its link from the browser's current origin. That looks like good hygiene. It is what half the tutorials do. But the console was reachable through a proxy host, so the QR quietly sent patients to the proxy instead of the app. The fix says: use the link the server minted, verbatim. And the commit explains why at length, because "derive it from the current origin" will look like a cleanup to somebody in six months.

04What Goes in the Book

If you run agents on real systems, your documentation needs a section human teams never had. Here is what I put in mine.

1. 1Pin the wrong answer next to the right one. "Enter submits" is half a note. "Enter submits, and backslash-Enter is a newline, do not switch to it" is the whole note.
2. 2Give every rule a receipt. An agent will out-argue a bare instruction. It will respect one with a date, a source, and the story of what broke.
3. 3Write down what healthy looks like, especially when healthy looks strange. A 302 that nobody explains is an outage waiting to be invented.
4. 4When you kill a gate or a process, record why, in the place agents actually read. Otherwise a future session rebuilds it and calls it rigor.

None of this is new, exactly. Institutions have always run on written knowledge. What is new is a workforce with no scar tissue. A human company remembers through its people. An AI operation remembers only through its documents.

If you run agents on anything real, you already have entries for this book. You just have not written them down yet. The book of right answers keeps a system running. The book of wrong answers keeps it from being fixed to death.