A runbook for agents

An agent you run for yourself alone lives in your head. You know what it may do and where you switch it off. As soon as it works for a team – or you are on holiday for three weeks – that is no longer enough. Then it needs a runbook.

That sounds like bureaucracy and is one page.

The one page

AGENT: returns pre-check

Purpose        Pre-sorts incoming returns and writes reply
               drafts. Decides nothing.
Owner          Jana M. · deputy: Malik S.
Trigger        Event: new ticket in the “Return” category

Alone          read tickets and orders, create drafts
With approval  send reply (by a human in the ticket system)
Never          trigger a refund, change customer data

Reads          ticket system, order export
Writes         drafts in the ticket system only
Model          cloud model; customer data goes to the provider
               (data processing agreement in place)

Budget         at most 200 runs/day, 150 euros/month
Log            ticket history + run log in the “Agent logs” folder
Checks         test set with 24 cases; after every change and
               monthly

Kill switch    ticket system › automations › deactivate
               “returns pre-check”
Next review    15 Jan 2027

Every line answers a question somebody asks in an emergency. If you cannot fill in a line, you have found something that needs settling before operation.

The lines most often missing

Owner – by name. “The team” is nobody. One person and one deputy.

The data paths. What does the agent read, and where does it go? With a cloud model the data read goes to the provider. With customer data that is a data protection question that must be answered before the first run.

The log. Where is it recorded what the agent did and when? Without a log, neither the damage nor the cause can be determined after an incident.

The kill switch. Not “deactivate the agent” but the exact path.

Rehearsing the kill switch

Give the page to someone who did not build the agent and have them stop it. Time it. If it takes longer than a minute, the description is too imprecise – or the access is missing. You do not want to find out either on the day it matters.

When something goes wrong

Five steps, in this order:

1. Stop. The kill switch first, everything else after.
2. Secure. Record log and results before anything is changed or deleted.
3. Limit the damage. What went out, who needs to know, what can be pulled back?
4. Find the cause. Was it the brief, a source, a tool, manipulation from outside, a model switch?
5. Safeguard, then restart. The incident becomes a case in the test set. Only when the agent passes it does it run again.

The fifth step is the one that tends to be skipped. Without it you have fixed a problem and prevented none.

Who may change what

A sentence in the prompt, a new tool, a different model – each of these changes can tip the behaviour. Define:

• Who may change things.
• That the test set runs before and after every change.
• Where the change is recorded – most simply in version control, where prompt, rules file and skills live anyway.

And watch the changes you do not make yourself: providers swap models behind unchanged names. After every such announcement the test set runs.

The register above it

From the individual pages the register of all agents arises by itself – the same list you know from Monitoring automations. Once a quarter you go through it: what is still running, what does anyone use, what may do more than it needs?

This documentation is not only for you. The next two stations show where law and management ask for exactly this.