AI operations: runbooks agents can follow

AI operations work best when people define the procedure and agents handle its repeatable steps. Most operational tasks follow a familiar pattern: something arrives, someone checks it, a decision follows, and a record or response needs updating. The details change, but the procedure often stays the same. That makes operations a practical place to introduce AI agents.

The sensible starting point is a written runbook. It tells an agent what starts a task, which information to inspect, what conditions must be met, and what to do when something falls outside the normal path. The agent handles the routine work. When an exception appears, it stops and asks a person a specific question. This gives an operations team a way to delegate execution without handing over responsibility for decisions that need judgement.

Why operations work suits an AI runbook

Consider a support team processing a request to change a customer's account details. The usual procedure might be straightforward: find the account, check the request, compare the supplied information with the records, prepare the change, and document what happened.

A person who performs this task regularly already knows its ordinary sequence. They also know the awkward cases. The account might not exist. Two records might match. The request might come from an address that does not belong to the account holder. A required document might be missing.

These exceptions are where an undocumented process becomes dangerous. An experienced employee knows when to stop. An agent needs that boundary written down. Without it, the agent has to infer what the business considers acceptable, and a plausible inference can still produce the wrong operational result.

A good runbook separates the ordinary procedure from the conditions that interrupt it. It does not attempt to describe every possible situation in advance. Instead, it gives the agent enough information to recognise when the task no longer fits the procedure.

Write the normal path before the exceptions

Start with a task that someone on the team could explain without opening a policy document. Ask that person to describe what they actually do, in order. Pay attention to the checks they perform automatically, because those habits often contain the rules that need to be written down.

A useful operations runbook should answer these questions:

• What starts the task? Name the event, incoming request, scheduled check, or assigned piece of work that gives the agent a reason to act.
• Where should the agent look? Identify the approved records, documents, inboxes, and connected systems that contain the information it needs.
• What must be checked? State the required fields, dates, identifiers, permissions, and supporting evidence.
• What does a normal result look like? Give the agent a clear description of the conditions that allow it to continue.
• Which actions are permitted? Separate reading and preparation from changes that affect other people or business records.
• When must the agent stop? Describe missing information, conflicting records, unusual requests, and any condition that requires human judgement.
• What should the agent deliver? Specify the completed record, report, draft, or other evidence that the person responsible will review.

Take invoice preparation as an example. The runbook might instruct an agent to retrieve an invoice, identify the supplier, compare the amount with the purchase order, check the due date, and prepare a payment record. It should also explain what to do when the supplier details do not match or the amount differs from the agreed purchase order.

The agent can prepare the ordinary case and present the evidence. It should not decide that a mismatch is harmless simply because the difference looks small. The person responsible for the payment needs to make that judgement.

Turn exceptions into questions a person can answer

A weak exception rule says, "Escalate unusual cases." That leaves the agent to decide what unusual means and gives the person receiving the escalation very little to work with.

A better runbook defines observable conditions and tells the agent what information to bring back. For example, an invoice procedure could contain three separate instructions:

• If the supplier identifier is missing, stop and ask which supplier record should be used.
• If the invoice amount differs from the purchase order, show both amounts and ask whether the discrepancy has been authorised.
• If the invoice appears to have already been processed, show the matching record and ask a person to confirm whether it is a duplicate.

Each question gives the reviewer something concrete to inspect. The person does not have to repeat the entire investigation or work out what the agent found. They can examine the evidence, provide missing information, or reject the proposed next step.

This approach also improves the runbook over time. If the same exception appears repeatedly, the operations lead can decide whether it needs a clearer rule, a new check, or a different procedure. The team can then update the instructions rather than relying on an agent to learn an informal business policy from repeated incidents.

There is an important distinction here: an exception question is not automatically an approval. A question might ask someone to identify the correct account or explain a missing document. An approval asks someone to authorise a proposed action. Keeping those two interactions separate makes it easier to see what the agent needs and what the business must permit.

Keep operational work separate from permission to act

An agent can finish much of a task without being allowed to carry out its final action. It might prepare a supplier payment, draft a customer response, or assemble a proposed change to an account. Completing that preparation does not give it permission to send money, contact someone, or alter a record.

For an operations team, this boundary needs to be explicit. The runbook describes the work. The permission rules determine which actions the agent can take. A reviewer should never have to guess whether a completed task has already changed something outside the workspace.

In Delagents, actions with effects outside the workspace wait in an approvals inbox. Each approval card shows the exact proposed action, the cost so far, and a deadline. A person can approve it, change it, or reject it.

Some actions always require a person's decision, regardless of how routine the procedure appears:

• Making first contact with anyone outside the workspace.
• Moving money or issuing a refund.
• Deleting or overwriting records the agent did not create.
• Changing roles or the agent's own policy.
• Connecting an integration or widening its access scopes.
• Accepting terms or signing an agreement.
• Publishing anything publicly.
• Taking action in another workspace.

These boundaries matter because an otherwise correct procedure can still lead to an action that needs authorisation. An agent might correctly identify a customer who qualifies for a refund. That does not mean it should transfer the money. It can prepare the case and leave the financial decision to a person.

Every delegation should also have a hard budget cap. An agent working through an unexpected complication should not be able to consume an unlimited amount of time or credits while trying to resolve it. An append-only activity log provides a record of tool calls, approvals, and policy changes, so the team can inspect how the task progressed.

Test the runbook against difficult cases

Before giving an agent responsibility for a recurring operational task, test its instructions against examples that represent both ordinary work and likely problems. Do not test only the cleanest example. That tells you whether the agent can follow the happy path, but little about whether it knows when to stop.

For an invoice runbook, a useful test set might include:

• A complete invoice with matching supplier and purchase order details.
• An invoice with a missing purchase order reference.
• A supplier name that matches two records.
• A payment request with an amount that differs from the approved amount.
• An invoice that appears to have been submitted twice.
• A request to pay an invoice before its supporting documents have been checked.

For each example, inspect what the agent reads, what it concludes, and what it tries to do next. Does it identify the correct records? Does it explain the discrepancy? Does it ask a useful question when information is missing? Does it stop before an action that needs approval?

Pay particular attention to questions that sound reasonable but contain an unsupported assumption. If an agent asks, "Can I use the supplier's previous bank details?", the runbook has not necessarily failed. The question may be appropriate. What matters is that the agent has not silently treated old details as permission to proceed.

Also test what happens when the task cannot be completed within its budget or available permissions. The correct response may be to stop and return a partial deliverable with a clear explanation. A runbook should not reward an agent for finishing at any cost.

Start with one operational procedure

The best first candidate is usually a task that happens regularly, follows a recognisable sequence, and produces an output someone can inspect. Support triage, invoice preparation, inbox classification, and meeting preparation are reasonable places to look. Avoid starting with a process whose rules are disputed or whose exceptions require several people to negotiate a decision.

Operations and support leads planning this kind of work can explore Delagents for operations and support teams. The workspace is built around written briefs, agent execution, checkpoints for human sign-off, and deliverables that a person can review.

Choose one task from your team's weekly workload. Sit with the person who performs it and write down the last five steps they followed, including one case that did not go to plan. Turn those steps into a runbook, mark every action that needs permission, and write the exact question the agent should ask when the exception appears.

Then test the instructions with a normal case and an exception before expanding the scope. If the agent can complete the ordinary preparation and return a useful question when the facts do not fit, you have the beginnings of an operational procedure that can be delegated safely.