Chapter 11: Lock In Only What Can’t Go Wrong

Anthropic’s guidance for Claude Code draws the line more clearly than anything else I’ve read. Every instruction you give an agent, it says, is one of two kinds. Some are read by the model, which "then decides what to do with this information… there’s no guarantee that it’ll follow your instructions." Others are enforced by the software around the model, which "applies this every time, no matter what the model decided to do."^[1] A playbook is the first kind. However carefully you word it, "whether Claude follows that line on a given turn is still Claude’s call."^[1]

The same guide is clear that the first kind should be the norm: "Most of the time, you want Claude to decide. Almost every guideline has exceptions," and the model, looking at the actual case, "is usually better placed to make that call than a rule you wrote in advance."^[1] That is Chapter 10’s argument in the words of the people who build the tools.

But a failure rate compounds. Anthropic’s guide to testing agents gives the arithmetic: an agent that succeeds 75% of the time on a single attempt will succeed on all of three attempts only about 42% of the time.^[2] Apply the same sum to a rule your agent follows 99 times in 100. Across a hundred actions, the chance it never slips is about 37%. Across a year of daily work, a slip is close to certain.

Whether that matters depends on what a slip costs. If it occasionally formats a report wrongly, someone fixes it and the playbook gets a better sentence. If it occasionally emails a customer something unchecked, deletes a record, or marks untested work as ready to ship, there is nothing to fix afterwards.

This is the question to ask of every instruction: if this is ignored once, can I undo it? If yes, it stays in English. If no, English is not enough.

CorralData’s instructions have settled into three tiers. Most work lives in the first; each step down needs a reason.

The tiers follow Anthropic’s line. "If something has to happen every time," its guide says, make it a rule the software enforces. The plain-English file "is for guidelines, and Claude is allowed to decide a guideline doesn’t apply."^[1] Tier two sits in between: still part of the playbook and still chosen by the occupant, but giving the same answer every time it runs.

Anthropic’s post introducing Agent Skills makes the case for that middle tier directly. Some work, it says, needs "the deterministic reliability that only code can provide," so a skill can bundle small scripts alongside its English instructions.^[3] The agent decides when to run the script. The script decides what the answer is.

Not everyone puts the line where I do. Dex Horthy’s 12-Factor Agents, a widely read guide for engineers, observes that many agents that work in production "are mostly deterministic code, with LLM steps sprinkled in at just the right points," and one of its principles is "Own your control flow."^[4] Further along is a 2025 research paper, Blueprint First, Model Second, which has no connection to this book despite the shared word. Its authors write the whole workflow as code, run it with a conventional program, and call the model only for bounded sub-tasks. On a travel-planning benchmark full of hard constraints, that approach cut constraint violations by 96% (11 against 275) compared with a model-led baseline using the same underlying model.^[5]

When the problem is fixed and every violation is costly, putting the route in code works. But most of what an organisation asks of its roles is not a benchmark. The route changes, the exceptions are the job, and the next model will find a better path than the one you wrote down. My reading is that the constraints should be locked in and the route left open. That is the difference between tier three and a workflow builder.

Models are fluent, and fluency is dangerous around numbers. A model asked to total a column will usually get it right, and when it doesn’t, it will be plausibly wrong. A model asked about a ticket will answer from whatever it was told, as my stalled-work agent did. Neither is a lack of intelligence; both come from asking a reasoning engine to do a lookup or a sum.

My morning stand-up agent shows the second tier at its plainest. Before the agent does anything, a small script checks one fact: have I accepted today’s stand-up meeting in my calendar? If not, the script stops everything: in its own words, "no LLM, no delivery." There is no point waking a model to decide whether a meeting is happening when the calendar already knows. A related job that rolls the plan over has instructions that say: "Do not re-derive the numbers; the script is the source of truth." The agent writes the commentary. The script does the counting.

The test for the second tier is simple. Would two careful people, given the same inputs, be expected to produce exactly the same output? If so, it is arithmetic or a lookup, and a script will do it better than any occupant. If two good people might reasonably differ, it is judgment, and it belongs in English.

The second tier sounds like a job for engineers. In practice, your agents do most of it unasked.

When I audited the folder belonging to my stalled-work agent, I found 174 small programs in it. Some were deliberate: the status lookup, the arithmetic for the weekly report, the logic that stops it nudging the same person twice. But ten of them were one-off scripts the agent had written for a single day’s digest, each named after its date. Every time it had needed to build the digest, it had improvised the same kind of tool from scratch, used it once and left it behind.

This is now a recognised pattern. Anthropic’s engineers describe agents that "persist their own code as reusable functions": once an agent has working code for a task, it saves it for next time, and a short English description turns the saved code into a skill other agents can use.^[6] In one of their examples, letting the agent write and run a small program instead of shuttling data through its own reasoning cut the work from 150,000 tokens of reading to 2,000.^[6]

So the manager’s job in the second tier is not to write scripts. It is to notice when an occupant has written the same one twice, and promote it: give it a name, put it in the playbook, and say in English when to use it and why. Ten dated digest scripts are a signal that a playbook is missing a tool.

There is a catch, and one of our engineers named it. Coding models, he pointed out, are rewarded for getting a task done, not for leaving behind code someone else can maintain, so they "get no better at keeping a codebase maintainable." An agent will happily write its hundred-and-seventy-fifth script. It won’t tidy the first hundred and seventy-four. Every promoted script needs an owner, and that owner is the role’s Sponsor (Chapter 7), not the agent that wrote it.

In Book XII of the Odyssey, the sorceress Circe warns Ulysses about the Sirens, whose song lures sailors on to the rocks. His solution is the oldest hard rule in literature. The crew stop their ears with wax. Ulysses, who wants to hear the song, has himself tied to the mast and tells his men that if he begs to be released, they must bind him tighter. He doesn’t distrust his judgment in general. He distrusts it at one known point, where the cost of being wrong is final. Everywhere else on the voyage, he steers.

That is the shape of the third tier. A hard rule is a rope you tie in advance at a point where you know, from experience or from the cost, that in-the-moment judgment can’t be trusted.

CorralData learned where one of those points was in July 2026, when our Glass Factory pipeline marked its own untested work "human-confirmed" and moved it towards release (Chapter 14). The rule that only a human could confirm a card had been written down in English. The pipeline had read it, and decided. The fix was a gate in the software that the pipeline cannot skip, whatever it concludes.

The places that need a rope are fewer than most leaders expect. They are the actions that cannot be undone, or whose undoing is expensive or public:

Manufacturing has known this for decades. Shigeo Shingo’s poka-yoke, mistake-proofing, puts a physical device at the point where an error would be made, so that the error becomes impossible or immediately visible, rather than relying on the worker to be careful.^[8] The worker is still trusted with the job; the fixture just won’t let the part go in backwards.

When leaders decide to lock something in, the instinct is to lock in the procedure. That is the workflow-builder instinct Chapter 10 warned against: the steps encode assumptions the next model makes wrong, and a procedure followed perfectly can still produce the wrong result.

The better target is the check. Decide what must be true when the work is finished, and enforce that. Leave the route alone.

Anthropic’s Claude Code guide lists, for each kind of instruction, the soft and hard versions. For "when it’s done," the soft version is asking the model for evidence; the hard versions are "Tests, typecheck, a Stop hook, CI": checks run by software at the end, whichever route the agent took.^[1] When Anthropic’s own engineers found that a newer model no longer needed its work broken into sprints, they removed the sprints. They kept the evaluator: an independent agent that checked the finished work, for the parts of the build beyond the model’s solo reliability.^[9] The steps were scaffolding. The check was load-bearing.

CorralData’s agents are built around the same idea. My project-management agent treats the "how" as "an opaque box" and accepts only evidence posted on the ticket; my commitment tracker refuses to count a draft as done (Chapter 13). Neither tells anyone how to do the work. Both are precise about what counts as finished.

Atul Gawande made the human version of this argument in The Checklist Manifesto. The checklists that worked in operating theatres and cockpits were short, covered only the critical items people were known to miss, and left the experts to do the rest with their own skill.^[10] A checklist that scripted the whole operation would have been ignored.

Locked-in checks age well. "No card reaches Ready to Go Live without human review" stays correct whatever model runs the pipeline. A locked-in step starts going stale the day a better model arrives.

Every hard rule has a cost. It will occasionally fire when it shouldn’t, blocking legitimate work at an inconvenient moment, and someone has to maintain it. Anthropic’s guide is blunt: "keep the enforced set small… If you ever find yourself at forty of them, most are probably preferences that Claude could have weighed on its own."^[1]

The same guide gives the most useful single test I know for when to promote a rule, and when to demote one:

In plain terms: if you are writing a rule in capitals for the third time and it is still being broken, stop shouting. Either the rule has no legitimate exceptions, in which case it belongs in tier three, or it does, in which case the occupant breaking it may be right and the rule needs its reason written down. The guide adds that piling on emphasis "mostly makes Claude over-apply the rule."^[1]

I recognise my own playbooks here. "PROGRAMMATICALLY," "LIVE," "NEVER": the capitals in my stalled-work agent’s instructions record the moments I was frustrated. Some of those lines have since moved down a tier. Others should simply be rewritten calmly, with their reasons. Either way, the capitals mark where English was failing.

The other direction matters as much. A hard rule that blocks legitimate work does damage twice: once when it fires, and again when people learn to work around it. If it keeps firing on cases that were fine, it was a preference and belongs back in the playbook.

W. Brian Arthur’s word for what happened to VHS was lock-in: a choice made early becomes impossible to reverse, whatever its merits later.^[11] That is the risk with every rule you hard-code into an agent system. The script you wrote because the model couldn’t do arithmetic, the gate you added because the agent couldn’t be trusted with a judgment: each was right when you added it. Each is an assumption about the model, and, as Sutton warned (Chapter 10), assumptions built in from what we know tend to plateau and then hold progress back.^[12]

Anthropic’s advice is that when a new model lands, you should "re-examine a harness, stripping away pieces that are no longer load-bearing."^[9] Philipp Schmid’s version is "Build to Delete": "New models will replace your logic. You must be ready to rip out code."^[13] The Claude Code guide’s own "What you can stop doing" table is a public example: a list of its own earlier advice, retired because "the models have since caught up."^[1]

CorralData has paid both sides of this bill. The scaffolding we built around AskCorral for early models had to be stripped out when the models got better (Chapter 10). Removing it was work. It would have been less work if each piece had been labelled with the assumption it encoded.

So label them. Every lock-in, in any tier, should carry three things written next to it in plain English:

Then review the set whenever the model changes, and whenever a rule fires on something that was fine. That review is a Friction Review in reverse: instead of turning a recurring failure into a system fix (Chapter 16), you are checking whether yesterday’s fix has become today’s friction.

Chapter 10 argued that plain English should be the default for almost everything an organisation tells its roles. This chapter has been about the "almost." English has a failure rate, and where an action cannot be taken back, that rate is not acceptable. Use a script for facts and arithmetic, and a hard rule for irreversible actions, security and the final check. Lock in what must be true at the end, not the route. Keep the enforced set small, and label each lock-in with its reason, its date and the condition for removing it. Ulysses tied himself to the mast for one stretch of sea. He didn’t sail the whole voyage bound.

The reasons attached to every rule are the thread that runs into the next chapter. An occupant can only use judgment well if it knows why the rules exist, and a reviewer can only delete a lock-in safely if someone wrote down what it was for. Chapter 12 is about packaging that knowledge for whoever fills a role next.