AI agent runbook for small businesses

An AI agent runbook is the practical operating guide for a live AI workflow. It tells your team what the agent is meant to do, what it may access, how people review its work, what to watch and how to stop or recover it when something goes wrong.

Without a runbook, important knowledge often sits with the person who built the workflow. The system may appear useful until that person is unavailable, a connection changes or an unexpected output needs investigating. A small business does not need a heavyweight manual, but it does need enough information for another authorised person to operate the workflow safely.

This guide sets out a lean runbook you can keep beside the system and update as it changes.

A runbook is not the same as an AI policy

These documents solve different problems.

An AI policy sets organisation-wide rules for appropriate use, approved tools, data, review and accountability. An AI tool register records which tools and systems the business uses. A risk register records what could go wrong and how those risks are treated.

The runbook sits at workflow level. It answers the questions a trained operator needs during ordinary work and an incident:

What job does this agent perform?
What starts it, and what should stop it?
Which sources, accounts and actions are approved?
What does a good output look like?
Who reviews, changes and supports it?
Where are the logs and previous versions?
How do we pause it, recover work and use the manual fallback?

The UK Government’s AI Management Essentials tool describes an AI system record as an inventory of documentation, assets and resources related to an AI system. It says that record can be a practical collection of files on a shared drive. Your runbook can be the front door to that record, linking the operator to the details without copying everything into one enormous document.

Start with a one-page operating summary

The first page should help somebody understand the workflow in a few minutes. Include these eight fields:

Name and purpose: one plain-English sentence describing the business job.
Status: trial, live, paused or retired.
Business owner: the person accountable for the outcome.
Operator: the person or role responsible for routine checks and approvals.
Trigger: the event, schedule or manual action that starts a run.
Output: what the agent produces, changes or sends, and where it appears.
Risk level: your internal classification and the reason for it.
Last reviewed: the date, reviewer and next planned review.

Use roles where possible, but include a current contact route. “Marketing manager” survives a staffing change better than one name, while the contact list makes it clear who currently fills the role.

Do not describe the purpose as “use AI to improve marketing”. Make it testable. For example:

Every Monday, assemble a draft campaign performance summary from the approved analytics exports. Save it in the reporting folder for the marketing manager to review. Do not change campaigns, budgets or source data.

That statement gives the operator a job, a boundary, an output and a review point.

Document the workflow from trigger to finish

Write the normal path as a short numbered sequence. Name the system used at each step, the information passed forward and any point where a person must decide.

For a campaign reporting agent, the sequence might be:

The scheduled workflow checks for the three expected exports.
If an export is missing or outside the reporting period, it stops and alerts the operator.
The agent reads the approved columns and calculates the agreed comparisons.
It prepares a draft using the current reporting template.
It flags missing data and material changes but does not invent a cause.
The marketing manager compares the draft with the source exports.
The approved report is moved to the final folder; rejected drafts return to the operator.

Add the exception paths underneath. What happens if the source is late, the integration fails, a value is impossible, the output contains personal information or the reviewer is absent? Exceptions are where a runbook earns its keep.

Keep a simple diagram only if it makes the hand-offs clearer. The numbered process remains useful because it is searchable, easy to update and accessible without specialist software.

List approved inputs, connections and boundaries

An operator needs to know exactly what the agent is allowed to use. Record:

approved source files, folders, tables or knowledge bases;
connected applications and the purpose of each connection;
the agent or service identity used for access;
permitted read, prepare, change and commit actions;
data that must not be entered or retrieved;
geographical, customer, product or date-range limits;
actions that always need human approval;
credential owner and rotation process, without recording passwords or secret tokens.

Link this section to the current permission record. Our AI agent permissions checklist provides a job-to-permission map and four-level action ladder you can use before filling in the runbook.

The National Cyber Security Centre’s current guidance on agentic AI security recommends documenting what is inside and outside the agent’s scope, including clear red lines. It also recommends limiting access to the resources needed for the task and ensuring people can investigate and stop consequential activity.

Write boundaries as operational rules, not aspirations. “Respect customer privacy” is too vague. “Do not retrieve message history outside the active support ticket” can be configured and tested.

Record the instructions and source of truth

Your runbook does not need to contain every prompt or configuration file. It should tell an authorised operator where the current versions live and how to recognise them.

Record:

the location and version of the main instructions;
the approved templates and reference material;
who can change each item;
how changes are reviewed and released;
where previous versions and change notes are kept;
which supplier model, feature or configuration the workflow currently uses;
any known limitation or behaviour the operator must watch.

Avoid pasting the same instructions into several documents. Duplicate copies drift. Point to one controlled source and show its version or last-changed date in the runbook.

The government’s AI Risk Management Toolkit notes that AI systems change throughout their lifetime as models, inputs, uses and external conditions evolve. That is why the runbook needs a change record, not just an accurate description on launch day.

Define the human checks and acceptance test

“Review the output” does not tell an operator what good looks like. Give the reviewer a short acceptance test for the job.

For a marketing report, it could be:

the reporting period matches the brief;
totals reconcile with the approved exports;
comparisons use the agreed baseline;
missing data is labelled rather than estimated;
explanations are presented as questions unless evidence supports them;
no campaign setting, budget or customer record has changed;
the final file is saved in the correct location.

State who approves the output, who covers their absence and which cases must be escalated. Link to the fuller decision design if you use one. Our human-in-the-loop workflow guide explains how to define the trigger, reviewer, evidence, decision, escalation and record for an approval gate.

Where the workflow affects people, uses personal information or makes higher-impact recommendations, the acceptance test may need input from a data protection, legal or subject specialist. A generic runbook is not a substitute for advice relevant to the use case.

Tell the operator what to monitor

Do not ask a small team to watch every possible signal. Choose a short set connected to the job and its risks.

Useful operating measures might include:

completed, failed and blocked runs;
processing time and unusual changes in volume;
missing or rejected inputs;
material corrections made by reviewers;
attempts to access unapproved data or tools;
permission, connection, model or instruction changes;
external actions such as messages sent or content published;
costs that cross an agreed warning level.

For each signal, record where it appears, who checks it, how often and what threshold needs action. A log nobody knows how to find is not an operating control.

The Information Commissioner’s Office AI governance and accountability guidance recommends supporting policies with operational procedures, guidance or manuals, assigning technical and operational responsibilities, and documenting change management. Apply those expectations proportionately to the workflow and personal information involved.

Include a pause and recovery procedure

Put the emergency steps near the front of the runbook and test them before launch. The person responding should not have to reverse-engineer the system while it is behaving unexpectedly.

Use a checklist such as:

Pause the schedule, trigger or autonomous process.
Restrict the agent’s connection or service identity if activity may continue elsewhere.
Preserve relevant logs, inputs, outputs, approvals and timestamps.
Identify any external action already completed.
Notify the business owner and the named specialist contacts for the type of incident.
Switch essential work to the documented manual fallback.
Assess and correct affected records, content or communications.
Test the fix in a controlled environment.
Obtain the required approval before restoring live access.
Update the runbook, risks and training with what was learned.

The NCSC guidance says organisations should retain the ability to halt autonomous agent activity and may also need to restrict its network access or communication with connected infrastructure. Your exact controls will depend on the product, so record the real buttons, accounts and owners involved rather than writing “turn it off”.

The manual fallback can be simple: download the source exports, use the approved reporting template and send the completed draft to the named reviewer. The important point is that essential work can continue while the agent remains paused.

Make handover a practical test

A runbook is not complete because the original builder can follow it. Ask another authorised person to perform a supervised handover test.

They should be able to:

explain the purpose and boundaries of the workflow;
find the current instructions and approved sources;
run or observe one normal case;
review the output using the acceptance test;
find the activity record and investigate a failed case;
pause the workflow and confirm access is restricted;
use the manual fallback;
identify who can approve a change and a restart.

Record the gaps they find. Unclear folder names, missing access, private notes and assumed knowledge are handover problems even when the technology works perfectly.

An AI agent system build should leave your team with this operating knowledge in its own accounts. Training is more useful when people practise the live workflow, its review decisions and its recovery route, not just watch a demonstration.

Use this AI agent runbook structure

Keep one controlled runbook per live workflow with these sections:

Purpose, status and accountable owner
Trigger, output and normal operating steps
Exceptions and escalation routes
Approved inputs, connections, identities and permissions
Instructions, templates and source-of-truth locations
Human approval and output acceptance checks
Monitoring signals, thresholds and review routine
Pause, incident and recovery procedure
Manual fallback and service contacts
Change log, review date and retirement steps

Review it whenever the job, model, supplier, data, connection, permission, reviewer or risk changes. Also review it after an incident, a failed handover test or a repeated correction. Retire the workflow by revoking access, preserving required records, removing obsolete triggers and marking the runbook clearly as retired.

Start small. Pick one live or planned workflow and build the runbook while the people who understand it are available. Then ask somebody else to use it. If they can operate, stop and recover the workflow without guessing, you have turned private implementation knowledge into something the business can genuinely own.

Frequently asked questions

What is an AI agent runbook?

It is a practical operating guide for one AI-enabled workflow. It records the purpose, normal process, approved access, human checks, monitoring, escalation, pause and recovery steps, manual fallback and ownership. It should help another trained person run the workflow without relying on the original builder’s memory.

How long should an AI agent runbook be?

Long enough to operate and recover the workflow, but short enough to use under pressure. A one-page summary plus linked instructions, permission records, checklists and logs often works better than one large manual. The complexity and impact of the workflow should determine the detail.

Who should own the runbook?

The business owner accountable for the workflow should make sure it remains current. Routine updates may be maintained by the operator or technical owner, but changes to purpose, access, approval or risk should go through the named decision process.

When should the runbook be updated?

Update it when the task, instructions, model, supplier, source data, integration, permission, owner, reviewer or recovery process changes. Review it after incidents and handover tests, and set a regular review date so quiet changes do not accumulate unnoticed.

Want an AI workflow your team can operate and own? Talk to us about an AI agent system build with practical handover, training and operating controls included.

Sources checked on 3 October 2026: UK Government AI Management Essentials, the UK Government AI Risk Management Toolkit, NCSC guidance on managing agentic AI risk and the ICO AI governance and accountability guidance. This is practical business guidance, not legal, data protection or cyber-security advice.