How to write an SOP for AI agents that they can actually follow

If you want to write an SOP for AI agents, write it the way you would brief a sharp new hire on their first day who has never seen your company. Say what triggers the job, what to read, what each step produces, which rules are fixed, where judgment is allowed and when to stop and ask a person. An agent that gets all of that can follow the procedure. An agent that gets a vague paragraph will guess.

The test is simple. Anthropic's guidance says to show your instructions to a colleague with minimal context on the task and ask them to follow them. If that person would be confused, the model will be too ^[6]. This guide shows you how to pass that test: a six-step method, a way to split locked rules from judgment calls, a short template and a checklist. It is general information about writing procedures, not legal or security advice.

What is an SOP for an AI agent?

A standard operating procedure for an agent is a written procedure that tells it how to do one job. AWS describes agent SOPs as natural-language documents that tell the agent how to operate, what decisions it can make and where to escalate ^[1]. That is close to what a good human SOP does. The difference is how much you can leave unsaid.

A person fills gaps with experience. They know that "the usual customers" means the ten accounts you always check, and that "send it round" means the team channel, not email. An agent does not know any of that unless the document says so. OpenAI's guide makes the same point from the engineering side: every step in a routine should correspond to a specific action or output, because being explicit leaves less room for errors in interpretation ^[3].

Is an SOP the same as a prompt?

They overlap, but they are not the same thing. A prompt is whatever you type to start a task. An SOP is the standing procedure behind many tasks. You write it once, a person owns it and you change it when the work changes. The prompt for a given day can be as short as "run the Friday pipeline report", because the SOP holds the detail.

Do you need an SOP for every task?

No. Anthropic advises finding the simplest solution possible and only adding complexity when it is needed ^[4]. A one-off request does not need a document. Write an SOP for work that repeats, touches several tools or carries some risk if it goes wrong. If you are not sure which jobs fit, start with the tasks worth delegating to an AI first.

How do you write an SOP an AI agent can follow?

Here is a six-step method. It borrows from the sources listed at the end and from plain common sense about how work gets handed over.

1. Pick one job and map the real process. Slite's method starts with choosing a process worth standardizing and mapping what actually happens with the people who do the work ^[2]. Do not write the process you wish you had. Write the one your best person follows today. Sit with them for an hour, or ask them to narrate the job while they do it.
2. Start from what you already have. OpenAI recommends using existing operating procedures, support scripts or policy documents to create instructions the model can use ^[3]. Paste in the old checklist, then fix it.
3. Write numbered steps, each with one action. Anthropic's guidance says to give instructions as sequential steps, using numbered lists, when order or completeness matters ^[6]. Each step should name the action, the tool or data it uses and what it produces.
4. Turn judgment into rules. Replace "use your discretion" with a decision rule. Slite gives a good example of the shape: approve the request only if the customer is on an Enterprise plan and the discount is below 15% ^[2]. Numbers, names and conditions belong in the text.
5. Add the edge cases and the stop points. OpenAI says a robust routine anticipates common variations, such as incomplete information, and gives conditional steps for them ^[3]. Add what the agent should do when data is missing, and when it must stop and hand over to a person.
6. Test it with someone who did not write it, then name an owner. Slite suggests handing the draft to someone who understands the work, having them complete it without help, and treating every point where they stall as context that still lives outside the document ^[2]. It also advises one named owner, set before go-live ^[2].

Why explain the reason behind a rule?

Anthropic notes that giving context or motivation behind instructions, such as why a behavior matters, helps the model understand your goals and respond in a more targeted way ^[6]. So do not just write "never send the report before 9 a.m." Write "never send the report before 9 a.m., because the finance numbers refresh at 8:30 and early copies show last week's totals." A rule with a reason helps in the cases you did not foresee.

What should the SOP spell out?

Most weak SOPs fail in the same places. They skip an input, hide a threshold or never say when to stop. Use this list as a minimum.

The figures in the example column are made up to show the format. Use your own.

How specific do the inputs and outputs need to be?

More specific than feels natural. Anthropic's advice on tools is to describe expected inputs and outputs clearly, and to name parameters unambiguously, for example a user ID rather than just "user" ^[5]. The same habit helps in an SOP. Say "the invoice number from the finance system" rather than "the invoice". Say "post in the sales channel" rather than "share it".

What should the agent do when something goes wrong?

Write the failure path as carefully as the happy path. Anthropic suggests error messages that give specific, actionable guidance, including examples of correctly formatted inputs ^[5]. In an SOP, that means a plain instruction such as "If the CRM export is empty, do not guess. Post a message saying the export failed and stop."

How do you split locked steps from judgment calls?

This is the idea that makes SOPs safer. AWS recommends two zones in an agent SOP. The locked zone holds deterministic steps the agent follows exactly, such as formulas, approval thresholds, write sequences, halt conditions and a list of prohibited actions ^[1]. The open zone is where the agent reasons like a skilled professional, and AWS says its autonomous actions must be read-only, use only available data and not contradict any locked rule ^[1]. AWS sums it up this way: the locked sections are the boundaries, and the open sections are where the agent thinks ^[1].

In practice, put anything that spends money, changes a record, contacts a customer or follows a formula in the locked zone. Put reading, summarizing, drafting and spotting patterns in the open zone. AWS also uses the capitalized words MUST, MUST NOT, SHOULD and MAY to give precise control without rigid scripting ^[1]. You can borrow that habit. "MUST post for approval before sending" is harder to misread than "please check first."

When should a person step in?

OpenAI names two triggers that usually call for human intervention. The first is exceeding failure thresholds, such as the agent failing to understand a request after several attempts. The second is high-risk actions: anything sensitive, irreversible or high stakes, such as canceling orders, authorizing large refunds or making payments ^[3]. Anthropic describes agents that can pause for human feedback at checkpoints or when they hit blockers, and recommends stopping conditions such as a maximum number of iterations ^[4]. Put both into the SOP as explicit lines.

For anything that leaves your company or changes the books, build the pause into the procedure itself. That is how approval gates and an audit trail work in a tool like Wopie, which pauses sensitive actions until a person approves them. Your SOP should say which actions those are.

What does a good agent SOP look like?

Here is a short example for a weekly pipeline summary. It is a sample to adapt, not a finished policy.

Job: Weekly pipeline summary for the sales channel.

Trigger: Every Friday at 8 a.m., or when the head of sales asks.

Steps:

1. Read the open deals from the CRM.
2. Flag any deal with no activity for 14 days.
3. Compare totals with last Friday's saved summary.
4. Draft a one-page summary: totals, changes, flagged deals.
5. Post the draft in the sales channel for the head of sales to approve.

Rules (locked): MUST NOT edit any CRM record. MUST NOT send the summary outside the sales channel. If the CRM export is empty or totals differ by more than 20% from last week, stop and ask.

Judgment (open): Choose which three changes to lead with and write the headline in plain language.

Owner: Head of sales operations. Review after any change to the sales stages.

Notice what is missing: no hedging, no "as appropriate", no jargon. Each line tells the agent what to do or when to stop.

How do you test and maintain an agent SOP?

Treat the first version as a draft. Run the job on a recent week where you already know the right answer and compare. Anthropic's tooling advice applies here too: pair each test task with a verifiable outcome, and avoid checks so strict they reject correct work over wording or format differences ^[5].

AWS recommends starting in advisory mode and expanding autonomy as trust grows ^[1]. In practice, that means the agent drafts and a person approves every output for the first few weeks. Then you loosen only the steps that have proven reliable. For more on that ramp, read how to onboard an AI agent like a new hire.

How often should you update it?

When the work changes, not just on a calendar date. Slite says a change in the work should trigger another review, such as a new policy, a tool change or a new type of ticket ^[2]. This matters because the usual alternative is luck. In a June 2026 survey of 143 founders, operators and engineers, one in four said they relied on someone noticing that documentation was outdated, rather than on a system that flagged stale content ^[2].

AWS gives a useful signal to watch. In its example, a vendor category that escalates 80% of the time suggests the SOP needs revising ^[1]. If the agent keeps stopping at the same step, the rule is probably unclear. It also suggests treating SOP changes like code deployments, with versions such as v1.0, v1.1 and v2.0 ^[1]. Keep one approved version and retire the rest ^[2].

What about risk and governance?

An SOP is also the simplest governance document you can write. It records what the agent may do, what it may not do and who answers for it. NIST's AI Risk Management Framework is voluntary guidance for managing AI risks, and it is a good place to look if you want a wider structure around this ^[7]. For a small company, a clear SOP with approval points and a named owner is a sensible first layer.

What to do next

Use this short checklist before you hand any job to an agent.

• Pick one job that repeats and is worth the effort.
• Map the real process with the person who does it today.
• Write numbered steps with one action each, and name every tool and data source.
• Turn each judgment call into a rule with a number, name or condition.
• Add what to do when data is missing or something looks wrong.
• Mark the locked rules: anything that spends money, edits records or contacts customers.
• Add stop points that need a person's approval.
• Give the draft to someone who did not write it and fix every place they stall.
• Name one owner and set review triggers.
• Start in advisory mode, with a person approving the output.

If you work in Slack or Microsoft Teams, you can give the finished SOP to an AI employee as a job in a channel and keep approval on anything sensitive. You can see how that works on the Slack page and check what it costs on the pricing page. Start with one SOP, one owner and one week of reviewed output, and you will know quickly whether the job is ready for more autonomy.