Your process document will not run an AI agent. How do you rewrite an SOP so an agent can follow it?
A method for turning a written procedure into an agent-ready SOP: inputs, decisions with thresholds, allowed actions, stop rules, owners and test cases.
The short answer
Rewrite the SOP as a decision record, not a narrative. List the inputs the AI agent reads, each decision with its rule and threshold, the actions it may take, the cases that stop it and go to a person, the owner, and one test case per rule. Most procedures keep those parts in people's heads, so write them down first.
Key takeaways
- A standard operating procedure written for people relies on judgement, memory and colleagues, and an AI agent has none of the three, so the gaps have to be written down before the build starts.
- An agent-ready procedure has six parts: inputs, decisions with explicit rules, allowed actions, stop conditions, an owner and a test case for every rule.
- Every phrase such as "use judgement" or "if it looks unusual" hides a threshold that an experienced employee applies without saying it; interview that person and turn it into a number or a named list.
- Rules that must always hold belong in code at the tool call, rules that need reading belong in the agent's instructions, and rules that need accountability belong with a person.
- In KPMG's survey of 314 US leaders at firms with $1 billion or more in revenue, run from 24 July to 25 August 2026, 49% had defined high-risk uses where agents may not decide on their own.
- The rewritten procedure is a living document with a named owner: every exception the agent hands over is either a new rule, a changed threshold or a confirmed stop.
In this article
Why a written procedure is not enough for an AI agent
A written procedure is not enough for an AI agent because it was written for a person who fills the gaps. The person knows which supplier always sends credit notes late, which customer gets a call before an order is held, and who to ask when a case looks odd. The agent knows only what it is given.
Most standard operating procedures (SOPs) are narratives. "Check the invoice against the purchase order and resolve any differences" reads as complete to the team that wrote it. To an agent it leaves every decision open: which differences matter, how large a difference is acceptable, and what "resolve" allows it to change.
This gap shows up after launch, not in the demo. A demo runs on clean cases, where the narrative is enough. Production brings the cases the SOP never described, and the agent either guesses or stops. Both are costly when nobody decided in advance which one it should do.
A disclosure: Sigzen AI builds AI agents for clients at published fixed prices, and the procedure rewrite is the first stage of every build we run.6 We have an interest in agents going live. We also see the rewrite catch more problems than any later test, which is why this method comes first.
AI agents in 2026
Agents are moving into real processes faster than the rules around them
What does a typical SOP leave out that an agent needs?
A typical SOP leaves out the thresholds, the exceptions and the authority behind each step. Those three live in the heads of the people who run the process, and they are exactly what an agent needs written down.
Read your own procedure with a pen and mark four kinds of gap. First, vague verbs: "check", "review", "resolve", "handle", "follow up". Each one hides a decision. Second, soft qualifiers: "large", "unusual", "urgent", "where appropriate". Each one hides a threshold. Third, missing inputs: the procedure says "confirm the delivery" but not which system holds the delivery record.
Fourth, missing authority. Narrative SOPs rarely say who may approve what, because everyone on the team already knows. An agent needs to know whether a step is something it may do, something it may propose, or something only a named role may do.
| What the SOP says | What the agent needs instead |
|---|---|
| Check the invoice against the PO | Fields to compare, and the tolerance for each |
| Escalate unusual orders | A list of conditions that count as unusual |
| Follow up with the customer | Channel, template, timing and how many attempts |
| Resolve the difference | Which records it may change, and which it may not |
| Ask the team lead if unsure | A named queue, a service level and a fallback |
Illustrative. Typical phrases from back-office procedures and the gap each one hides.
Count the gaps before you commit to a build date. Our view: a procedure with more than a handful of unmarked decisions is a documentation project first and an agent project second, and the plan should say so.
The six parts of an agent-ready procedure
An agent-ready procedure has six parts: inputs, decisions, allowed actions, stop conditions, an owner and test cases. Write each part as a list or a table, never as prose, so a reviewer can see what is missing.
Six parts of an agent-ready SOP
- Inputs
Every document, field and system the agent reads, with where each one comes from.
- Decisions
Each choice the process makes, with its rule, its threshold and the data it uses.
- Allowed actions
What the agent may do, propose or never touch, per system and per field.
- Stop conditions
The cases that end the run and go to a person, with the queue they go to.
- Owner
The named person who answers for the procedure and approves every change to it.
- Test cases
One real example per rule and per stop condition, with the expected outcome.
Inputs come first because every rule depends on them. If the delivery record lives in a warehouse system the agent cannot read, no rule about deliveries will work. List each input with its source system and the field names, and note where people today read something that is not in any system, such as an email thread or a phone call.
Decisions come next, one row each. The row names the condition, the data that tests it, the threshold and the outcome. "Unit price above the agreed contract price by more than the set tolerance: hold and send to the buyer" is a decision row. "Check prices carefully" is not. The tolerance in a row like that comes from your own policy, not from a template.
The owner is the part teams skip. Without one, the procedure freezes on launch day while the business keeps changing. Our guide to choosing the first process for an agent covers which processes are worth this effort; this method assumes you have already picked one.
How do you turn "use judgement" into a rule?
Turn "use judgement" into a rule by asking the people who apply it to explain their last twenty decisions. Their reasons repeat, and each repeated reason becomes a condition with a threshold or a named list.
Pick the employee the team goes to with hard cases. Pull twenty recent cases from the system, including the ones they held, changed or escalated. For each one ask three questions: what made you look twice, what did you check, and what would have made you decide the other way. Record the answers word for word.
The answers are more concrete than the SOP. "It looked unusual" becomes "the ship-to address was new and the order was above our usual size for that customer". "I checked with sales" becomes "the customer is on the key-account list, so sales confirms before any hold". Each of those is a rule an agent can apply.
Some judgement does not reduce to a rule, and that is a finding, not a failure. If the expert cannot name what they look for, the case belongs in a stop condition. Our view: keep the cases nobody can explain with a person, and let the agent prepare them so the person decides faster.
Where should each rule live: in code, in the instructions or with a person?
Each rule should live where it is enforced most reliably. A rule that must always hold goes in code at the tool call, a rule that needs reading goes in the agent's instructions, and a rule that needs accountability stays with a person.
Others have written about this split first, and the credit belongs to them. Anthropic's engineering guide on building effective agents separates workflows, where code sets the path, from agents, where the model chooses its steps, and it advises the simplest design that does the job.5 What this method adds is the procedure side: how to sort the rows of your own SOP into those places.
| Where the rule lives | Use it for | Example |
|---|---|---|
| Code at the tool call | Limits that must never be broken | No payment to an unverified bank account |
| Code before the agent | Checks a lookup can settle | Customer is over its credit limit |
| Agent instructions | Rules that need reading a document | The email asks to change the delivery date |
| A person | Decisions someone must answer for | Write off a disputed balance |
Our default placement. Move a rule toward code whenever a lookup or a comparison can settle it.
The common mistake is to put everything in the instructions because that is fastest to write. A rule in the instructions is a request to the model, and the model can misread it. Our view: if breaking a rule would cost money or trust, it belongs in code, and the instructions only explain it. Our least-privilege checklist for agents in an ERP or CRM covers the user rights that make the code-level limits stick.
Write the stop conditions before the happy path
Write the stop conditions before the steps for clean cases, because they decide what the agent does when the procedure runs out. A clean case needs few rules; an exception needs a clear exit.
A stop condition names the trigger, what the agent does before it stops and where the case goes. "Missing purchase order: save a draft match, tag the buyer, place in the purchasing queue" is complete. "Missing purchase order: escalate" is not, because nobody knows who receives it or what they will see.
Group the triggers into four kinds. Missing data, such as a document the agent cannot read. Rule conflicts, where two decision rows point different ways. Limits, such as an amount above the agent's ceiling. And low confidence, where the agent cannot match the case to any rule. Every kind needs its own queue or at least its own tag.
Large firms already draw these lines for high-risk uses. In KPMG's survey of 314 US leaders at firms with $1 billion or more in revenue, run from 24 July to 25 August 2026, 49% had defined high-risk uses in which agents are not allowed to make decisions on their own.1 A stop list per procedure applies the same idea at the level of a single process. Our design for the exception queue covers who works the cases once they stop.
Turn every rule into a test case
Turn every decision row and every stop condition into at least one test case drawn from your own history. A rule without a test case is a guess about how the agent will read it.
Use the twenty cases from the expert interview as the start. Add one clean case per decision row, one case that sits just inside each threshold and one just outside it. Add one case per stop condition. Write the expected outcome next to each: the action, the field values and, for stops, the queue.
Score outcomes, not wording. A case passes when the agent took the expected action and changed only the expected fields. It fails on any wrong action, any extra change or a stop that went to the wrong queue, whatever the agent's explanation says.
The test set also checks the procedure itself. When two testers disagree on the expected outcome, the procedure is ambiguous, and the fix is a clearer row. Our view: an ambiguity found by testers costs an hour; the same ambiguity found by the agent in production costs a correction and a conversation with a customer.
Keep the set after launch. Our method for regression-testing an agent reruns it whenever the model, the instructions or the procedure changes.
Two versions of the same step
Narrative SOP
- Check the invoice against the PO
- Resolve small differences
- Escalate anything unusual
- Ask the team lead if unsure
Agent-ready SOP
- Compare supplier, quantity, unit price and tax
- Within the set tolerance: match and log
- Above it: hold, tag the buyer, purchasing queue
- Each row has a test case and an owner
What does the rewrite cost, and how do you know it paid off?
The rewrite costs the time of the people who know the process, and it pays off when the agent handles the cases it was given without guessing. Measure both, because the business case depends on them.
Budget the expert's time honestly. The interview, the review of the draft rows and the expected outcomes for the test set all need the person whose judgement you are writing down. That person is usually the busiest on the team, so book the time before the build starts.
In McKinsey's State of AI 2026, a survey of 1,719 respondents in 97 countries run from 4 May to 8 June 2026, 37% attributed any EBIT impact to AI.3 In the same survey, 40% of respondents at organisations with more than $1 billion in revenue said they were scaling AI agents, against 22% below that size.4 In Gartner's survey of 1,303 leaders, run from January to April 2026 with geography not stated, about 11% did not know what their own function had spent on AI in 2025.2
Track three numbers from day one: the share of cases the agent completes without a stop, the share of completed cases a reviewer changes, and the stop rate per condition. A rising change rate means a rule is wrong. A stop condition that never fires may be too loose, or the case may simply be rare.
Who owns the procedure after go-live?
A named process owner owns the procedure after go-live, not the team that built the agent. The owner approves every new rule, every changed threshold and every new stop condition, and signs the change log.
Give the owner a weekly review of the stopped cases. Each one ends in one of three ways: a new decision row, a changed threshold, or a confirmation that the stop was right. Over time the stop rate falls for the right reason, because the procedure learned, rather than because someone loosened a limit.
Keep the procedure in the same place as the agent's configuration, with a version number and a date. When the agent's behaviour changes, anyone should be able to see whether the procedure changed too. Our view: an SOP that lives in a shared drive while the agent's rules live in code will drift apart within a quarter.
Large firms are adding cost to the same review. In KPMG's third-quarter survey, 74% of organisations included cost reviews in their AI approval processes.1 Add the agent's running cost per case to the owner's weekly review, so a rule change that doubles the work per case shows up early.
A four-week rewrite before the build
Mark the gaps in the current SOP; list inputs and source systems; name the owner.
Interview the expert on twenty recent cases; draft decision rows and stop conditions.
Place each rule in code, instructions or with a person; set the allowed actions.
Write test cases with expected outcomes; resolve every tester disagreement in the rows.
What to do this month
Pick one procedure, mark its gaps this week, and have a decision table, a stop list and a test set ready before anyone writes agent code. None of it needs a new tool.
- Print the current SOP and mark every vague verb, soft qualifier, missing input and missing authority.
- Name the process owner and book time with the person the team asks about hard cases.
- Interview that person on twenty recent cases and turn repeated reasons into decision rows.
- Write the stop conditions, each with its trigger, its final action and its queue.
- Place every rule in code, in the instructions or with a person, and list the allowed actions.
- Write one test case per rule and per stop, with the expected outcome next to it.
- Store the procedure with the agent's configuration, versioned, and review stopped cases weekly.
The order matters. A team that writes the procedure first builds an agent that does what the business decided, and a team that skips it builds an agent that does what the model guessed. Our view: the rewritten SOP is worth having even if you never build the agent, because new employees learn from it too.
Sources
- KPMG, AI Quarterly Pulse Q3 2026: 314 US leaders at $1bn+ firms, 24 Jul–25 Aug 2026 (Sep 2026)
- Gartner, survey of 1,303 leaders at organisations with $50M+ revenue, Jan–Apr 2026; geography not stated (Sep 2026)
- McKinsey, The State of AI 2026: n=1,719, 97 countries, 4 May–8 Jun 2026 (Aug 2026)
- McKinsey, The State of AI 2026: organisations with more than $1 billion in revenue vs $1 billion or less (Aug 2026)
- Anthropic, Building effective agents (Dec 2024)
- Sigzen AI, published prices (Nov 2026)
