Runbooks your whole team can read

A runbook describes how a piece of work gets done, step by step, in the language the team already uses. An agent executes it one step at a time, with a person in the loop wherever the team wants one. And it conforms to an open standard, so it is a real, portable artifact rather than a clever prompt buried inside some tool.

Anyone can read those five lines and know exactly what the agent will do. That legibility is the whole point. The instruction is not hidden in a system prompt or encoded in weights. It is right there, in words the team owns.

Notice the last line of the example: send it to me for review. A runbook can say where a human has to sign off, step by step. Reading a draft can run on its own. Sending it outside waits for a person. The procedure carries its own checkpoints, so an agent can be trusted with the routine parts and still stop at the ones that matter, and as the team gains confidence, those checkpoints move.

The people who own a procedure are usually not engineers. The analyst who knows how the diligence actually goes. The operations lead who knows the close. The support manager who knows when an exception is warranted. If encoding their procedure requires an engineer, two things happen: it is slow to write, and it drifts, because the person who knows the work is not the person who can edit the encoding.

Plain English collapses that gap. The person who owns the work writes the runbook and fixes it directly, the same afternoon the procedure changes. The encoding keeps up with reality because the people living the reality are the ones maintaining it. No translation step, no queue, no engineer in the middle of a process they do not run.

It is also why a runbook is not the brittle automation of the past. A hard-coded script breaks the first time reality deviates from what its author foresaw. A runbook written in plain language degrades gracefully, because an agent reading instructions can handle a case the author did not anticipate, and a person can add the missing line afterward. The procedure bends instead of snapping.

The other way to teach an agent a procedure is to bake it into the model's weights. That is slow, expensive, and opaque, and it is frozen: when the procedure changes, you cannot see what the model knows, and you retrain to fix it. You also cannot easily tell, after the fact, why it did what it did.

A runbook is the opposite on every count. It is legible, instant to change, and versioned. When the approval step changes, you edit a line, not a model. And the work is not swallowed by next year's base model the way a fine-tune tends to be. The runbook rides on top of whichever model is best at the time, which means the procedure you captured keeps its value as the models underneath it improve.

Once the procedure is written in plain English, it stops being one person's tacit knowledge and becomes something the team owns. Anyone can run it. Anyone can read it to understand how the work is supposed to go. Anyone can propose an improvement.

The downstream effects are larger than they first look. A new hire reads the runbook instead of shadowing someone for a month. A senior person's expertise stops walking out the door when they leave, because the part that mattered is written down. And because runbooks are versioned, you can see how a procedure changed and why, which is its own quiet form of institutional memory.

It also travels. A runbook one team refined for vendor diligence is a starting point another team can copy and adapt, instead of rediscovering the same procedure from scratch. Good procedures spread the way good documents spread, by being read and reused. Because they are versioned, a team that adapts one can still see where it came from and what they changed.

A runbook is not written once and frozen. It is the thing that improves. Every time the work runs and a person corrects the output, that correction is a candidate edit. The step the agent keeps getting slightly wrong gets rewritten. The exception that keeps coming up gets added.

Over time the runbook converges on how the work actually gets done, not how someone imagined it would at the start, and the agent following it improves in lockstep, with no retraining. The better instructions are the improvement. That is a very different and much faster loop than waiting on a new model to somehow learn your company's procedure on its own.

Code is for engineers. A fine-tune is for no one, because no one can read it. A runbook is for the team: the people who do the work, written by them, run by an agent, and improved a little every time it runs. The fastest way to get an agent to do the work the way your company does it is to let your company write it down, in its own words.