How to write SOPs that AI agents can follow

What makes an SOP ready for an AI agent?#

An AI-ready SOP is a procedure that states every input, action, decision and handoff explicitly, because an agent cannot fill gaps with hallway knowledge. Most existing SOPs were written for trained staff who already know the systems, the customers and the unwritten rules, so they skip exactly the details an agent needs.

The gap is usually not missing steps but missing conditions. A line such as escalate if the customer seems upset assumes a judgment the agent cannot make consistently. A line such as escalate when the ticket has been reopened or the account is on the priority list gives the agent something it can check.

The fields every agent-ready step needs#

Every agent-ready step needs the same small set of fields, written in the same order each time. Consistency matters as much as completeness: when every step follows one pattern, an agent and a human reviewer can both see at a glance what is missing.

Keep each step to a single action. Combined steps such as verify the order and issue the credit hide a decision between two actions, and that hidden decision is where agents go wrong.

• 1Step name: a short verb phrase, such as Confirm warranty coverage.
• 2Trigger or precondition: the event or record status that starts the step.
• 3Inputs: the records, systems and fields the step reads, by their real names.
• 4Action: one thing the agent does, in one system.
• 5Decision rule: the condition written as if this, then that, with an else branch.
• 6Exceptions: known cases the rule does not cover, and where each one goes.
• 7Output: which record changes, which field gets set and what note is written.
• 8Owner: the role that answers questions and approves changes.

How to write decision points an agent cannot misread#

Decision points become reliable when every condition refers to something the agent can look up: a field value, a status, a named list or a referenced document. Words like reasonable, significant and promptly read clearly to people and mean nothing to software.

Write the else branch every time. Many SOPs say what to do when a condition is true and stay silent otherwise, which leaves the agent to improvise. If there is genuinely no rule, say so and route the case to a named queue.

Where a threshold comes from policy, point to the policy rather than copying the value. If the approval limit for customer credits lives in a finance policy, reference that document so a later change does not leave two conflicting versions.

Exceptions and escalation: where most SOPs go quiet#

Exceptions and escalation paths are where most SOPs go quiet, so an agent-ready SOP lists the exceptions the team already knows about and gives each one a destination. Routine cases rarely need a document at all; the unusual ones are where an agent needs instructions.

The best source for that list is your own history. Closed tickets, job notes, credit memos and reopened cases show the situations staff actually handled outside the standard path, and reading a sample before you write usually surfaces exceptions nobody remembered to document.

Always end with a catch-all: when no rule and no listed exception applies, the agent stops, records what it saw and hands the case to a named role. An agent that knows when to stop is safer than one that tries to finish everything.

Illustrative: rewriting a warranty callback SOP#

Illustrative: a fictional heating and cooling contractor serving homeowners keeps its jobs, invoices and equipment records in one field service platform and wants an agent to triage warranty callbacks before dispatch. The before version of its SOP is one paragraph: check whether the job is under warranty, schedule it if so, and talk to the service manager if anything is unclear.

The after version, written by the operations lead, splits that paragraph into six single-action steps. Each one names its inputs, its rule, its else branch and where exceptions go, including a missing equipment record, a homeowner who bought the house after installation, and a callback that follows another contractor's repair.

Before switching anything on, the team replays closed callbacks from the platform's history through the new steps. Most reach the outcome the dispatcher recorded; the ones that do not reveal two unwritten rules, which are added to the SOP. The agent goes live on triage only, and the service manager still approves every no-charge visit.

• 1Step 1, Find the original job: when a job is created with job type Warranty Callback, read the linked install job number; if none is linked, route to the service manager queue with reason No Install Job.
• 2Step 2, Check the equipment record: open the equipment record attached to the install job; if it is missing, route to the service manager queue with reason No Warranty Record.
• 3Step 3, Check the warranty term: if the install date falls inside the warranty term on the equipment record, continue; else set the job to billable and send the standard out-of-warranty template.
• 4Step 4, Check ownership: if the customer record shows a different homeowner from the one on the install job, route to the service manager with reason Ownership Change.
• 5Step 5, Check prior repairs: if job notes show another contractor worked on the unit after installation, route to the service manager with reason Third-Party Repair.
• 6Step 6, Hand off to dispatch: set the warranty flag, apply the callback priority from the dispatch policy, and write the rule that decided the case into the job notes.

How to test an SOP before an agent runs it#

Testing an SOP before an agent runs it means checking the steps against real cases, not just reading them for clarity. A procedure can read well and still fail on the first unusual job.

Keep the test cases afterward. A small set of closed cases with known outcomes becomes a regression check you can rerun whenever the SOP, the system or the agent changes.

• 1Hand the SOP to someone outside the team and ask them to work through recent cases without asking questions; every question they want to ask marks a gap.
• 2Replay closed cases from your ticket, job or order history and compare where the steps lead with the outcome actually recorded.
• 3Include cases that were reopened, credited or escalated, because they exercise the exception paths.
• 4Check every system and field name against the live system, since a renamed field breaks an agent silently.
• 5Record the SOP version and date so later results can be traced to the version in force.

Mistakes that make SOPs fail with agents#

The mistake that most often makes SOPs fail with agents is documenting the ideal process rather than the real one. If staff routinely skip a step or use a workaround, the agent will follow the document and produce results nobody expects.

Other frequent problems are screenshots without text, steps that depend on an attachment the agent cannot open, references to people by first name instead of role, and the same SOP stored in several places with different versions. Pick one home for each SOP, retire the copies, and write every instruction in text even when a screenshot helps people.

Why SOPs paired with records interest AI developers#

SOPs paired with the records of how work was actually done interest AI developers because together they show the intended procedure and the real decisions, exceptions and outcomes. An SOP alone describes a process; the matching tickets, jobs or orders show how people applied it, where they departed from it and what happened next.

SourceX treats procedure documents as part of a wider record family rather than as standalone files. Through the SourceX five-step transaction (Supply, Rights, Preparation, Approval and Delivery), a company first describes its SOPs and linked systems using metadata only, and rights review, privacy preparation and the company's own approval come before anything is delivered. Every licensed package is documented in a SourceX Evidence Packet, which sets out where the procedures and records came from (provenance), the licensing rights behind them, the permitted use, the privacy record and who authorized release. Any such package is licensed, not sold, and the company keeps ownership of its records.