Most Standard Operating Procedures are written for humans who already know the job. They read like compliance wallpaper: long narrative, implicit assumptions, and a photo of a screen from 2019. That is unusable for AI assistants and agents, which do not share your tacit context -- they only execute what is explicit, ordered, and testable.
An agent-ready SOP is a process document with a clear trigger, required inputs, numbered steps, explicit edge-case branches, and a verification check at the end. When those elements are present, an AI agent or assistant can follow the procedure without improvising your finance rules or your brand voice.
This guide shows how to rewrite (or write) an SOP so a model can follow it reliably. It pairs with how to build a company knowledge base for AI for where SOPs live, AI operations assistant for who runs them day to day, and how to automate sales with AI when playbooks span CRM and email. For "rules vs. judgment," see AI agents vs. automation and AI agents vs. chatbots.
Why "more detail" is not the same as "agent-ready"
Teams confuse length with clarity. A forty-page PDF can still omit:
-
What triggers the process (event vs schedule vs threshold)
-
What "done" looks like (artifacts, states, approvals)
-
What to do when data is missing (pause, escalate, default -- which default?)
-
What must never happen (double pay, public reply, delete production)
Agents need decision boundaries, not office memoirs.
The anatomy of an agent-ready SOP
| Section | Purpose | Bad example | Better example |
|---|---|---|---|
| Trigger | When to start | "As needed" | "When invoice_status = pending_approval AND amount is under 10k" |
| Owner + RACI | Who approves exceptions | "Finance team" | "Analyst executes; Controller approves above 10k" |
| Inputs | Required data fields | "Invoice info" | List: vendor ID, PO, amount, GL code, attachment URL |
| Steps | Ordered actions | Paragraph story | Numbered steps, one action each |
| Edge cases | Known branches | Ignored | "If vendor is new, route to vendor onboarding SOP-07" |
| Verification | How to check success | "Looks good" | "Payment batch ID created; email receipt logged" |
| Audit | What to log | Nothing | "User ID, timestamp, before and after status" |
If you cannot fill Verification, you do not have an SOP -- you have a vibe.
Step 1: Start from one real run, not from imagination
Pick the last time someone did this process correctly. Reconstruct:
-
Trigger -- what exact signal started work?
-
Artifacts -- PDF, row in sheet, ticket ID, email thread?
-
Decisions -- where did they branch (amount thresholds, geography, plan tier)?
-
Handoffs -- who received output and did they accept it?
Now write the SOP backward from that run. Fiction SOPs are the number-one cause of "the agent did something crazy." If you are new to Agently's model of work, core concepts explains how tasks, context, and tools fit together.
Step 2: Write steps as imperative, testable commands
Humans tolerate "handle appropriately." Models will guess.
| Weak step | Strong step |
|---|---|
| "Review invoice for accuracy." | "Confirm PO number on invoice matches PO in ERP; if mismatch, stop and label EXCEPTION_PO_MISMATCH." |
| "Email vendor." | "Send template VENDOR_AP_V1 from [email protected]; attach PDF; CC procurement if vendor is new." |
Each step should answer: What do I click, write, or query? If the answer is "it depends," that is an edge case subsection, not a shrug in step 4.
Step 3: Encode edge cases as explicit branches
Use a simple pattern models parse well:
IF [condition] THEN [action]
ELSE IF [condition] THEN [action]
ELSE [default action + who to notify]
Defaults must be safe. Example: "If tax jurisdiction unknown, do not post; assign to tax queue." Unsafe defaults (assume US, assume standard VAT) create silent wrongness.
Step 4: Separate "policy" from "procedure"
| Type | Content | Update frequency |
|---|---|---|
| Policy | What is allowed or not allowed | Quarterly or on regulatory change |
| Procedure | Click-path and systems | When tools change |
Mixing them causes stale procedures: people skip the doc because half is obvious law and half is wrong screenshots. Cross-link instead: "Follow payment policy POL-FIN-02; this SOP is execution only."
Step 5: Add verification and rollback
For anything that touches money, access, or customers:
-
Verification: "Balance matches bank feed within threshold X; exceptions listed in report R-AP-01."
-
Rollback: "If batch fails after step 7, run reverse_batch job per RUNBOOK-14; never delete rows manually."
Agents (and junior humans) need panic behavior defined. Customer-facing SOPs often sit next to AI customer support agent workflows; internal finance SOPs may never touch a customer channel -- say so explicitly.
What to cut from legacy SOPs before giving them to AI
| Cut | Why |
|---|---|
| Org history and philosophy | Moves to onboarding doc, not execution |
| Screenshots without alt text | Models rely on adjacent text ; pure images are weak |
| Duplicate versions | Pick one canonical URL; archive the rest |
| "Contact IT" without ticket type | Replace with "Open ticket category Access -- Finance" |
How Jarvis uses this in Agently
Jarvis is Agently's AI agent, drawing on an operations specialist behind the scenes: it can execute recurring workflows across tools when your SOPs are clear enough to map to actions -- and when your Brain holds the policies and templates humans already trust. Integrations show which systems you can connect; Getting started walks through first setup. Try Agently free.
