Short answer
Write the decisions, not just the steps. A procedure for a new employee can rely on them asking. An agent cannot ask unless you tell it when to, so the document has to name the inputs, the decision rules, what finished looks like, the exceptions, and the point where it must stop and escalate.
Key takeaways
- Human SOPs leave out the judgement, which is the part software most needs written down.
- Six blocks make a procedure usable by an agent: who, inputs, steps, done, never, and when to stop.
- Write it with the person who actually does the work, not the person who thinks they know how it is done.
- Test it by handing it to someone who has never done the task. Every question they ask is a missing line.
Most businesses already have procedures. They were written for onboarding, and they work because a new hire fills the gaps by asking the person at the next desk. An agent has no next desk. Everything that person would have answered has to be in the document, or it gets invented.
The six blocks
Who this is for, what it receives, what steps it takes, what finished looks like, what it must never do, and when it must stop and ask a human. The last two are the ones missing from almost every existing SOP, and they are the two that decide whether the agent is safe to run unattended.
| Block | Answers | What it looks like when it is missing |
|---|---|---|
| Who | What role is this, and what is it responsible for | The agent adopts a tone or scope nobody intended |
| Inputs | What it receives, from where, in what shape | It works from whatever it can find, including stale data |
| Steps | The sequence, including the decisions inside it | Plausible improvisation where a rule should be |
| Done | What a finished, correct result looks like | Work that stops early or never stops |
| Never | The hard limits, in plain words | Discounts offered, clients contacted, records changed |
| Stop | The cases where it must escalate, and to whom | A confident guess instead of a question |
Write the decisions, not just the actions
Most steps in a real procedure contain a judgement the writer does not notice making. "Send the standard reply" hides a decision about which reply and when it is not appropriate. Sit with the person doing the work and ask, at each step, how they choose. Those answers are the actual procedure.
A useful prompt in that conversation: when was the last time you did this and it went differently? The exception they describe is worth more than three paragraphs about the normal case, because the normal case was never going to cause trouble.
Give it three to five worked examples
Rules alone produce literal-minded work. Attach real examples, different from each other, with the correct output for each. Include at least one that should have been escalated rather than completed. Examples teach the shape of good judgement in a way that another paragraph of rules does not.
Test it before anyone builds anything
- Hand the document to a colleague who has never done the task and watch them attempt it, without helping.
- Write down every question they ask. Each one is a line the document is missing, and each one would have been an invention by an agent.
- Add the answers, then repeat with a different person until the questions stop.
- Only then build. The document is now the specification, and the build is the easy part.
Keep it alive
Processes drift, and an agent built on last year’s procedure keeps running the old way with complete confidence. Give every procedure a named owner and a review date, and treat a change to the process as a change to the agent. This is the maintenance cost people forget when they budget the build.
Questions people ask
Can I just give the agent our existing SOPs?
You can start there, and expect gaps. Procedures written for onboarding assume the reader can ask a colleague. Add the decision rules, the exceptions, the definition of finished, and the escalation point before you rely on the result.
How long should a procedure be?
As long as the decisions require and no longer. One well-specified workflow with its exceptions is usually one to three pages. If it runs to ten, it is probably several procedures that should be separated and owned individually.
Who should write it?
The person who actually does the work, interviewed by someone who will ask why at every step. The manager’s version and the real version differ more often than anyone expects, and the real version is the one the agent has to follow.
Can AI write the SOP for us?
It can draft structure and questions from a transcript of the interview, which saves hours. It cannot know your exceptions or your limits. The person who does the work has to correct it line by line, or you have documented a plausible fiction.
What if the process changes every few months?
Then name an owner and a review cadence in the document itself, and treat process changes as agent changes. A frequently changing process is also a signal to keep more of the approval with a person until it settles.
Sources
- delegAIte deliverables, Business Architecture and Simplification, delegaite.co (read 20 September 2026): That documented institutional knowledge and AI-ready SOPs are treated as a prerequisite to deployment rather than a by-product.
Published . Last reviewed .
Want this in your business?
Book a call and we will scope exactly which part of your operation an agent should take first.
Book a call with the team