Learn / Agentic on-ramp
SOPs are not agent-ready: a checklist for what agents actually need
A static markdown SOP is not agent-ready, no matter how well it is written. Agent-ready means four specific things: explicit decision points, scenario branches, named owners, and a currency guarantee. Here is the checklist, and why most SOPs fail every line of it.
There is a comfortable assumption behind a lot of the current advice on "agent operating procedures" and "AI-ready SOPs": that if you have a clean, well-formatted SOP, you are most of the way there, and the agent just reads it and follows along. That assumption is wrong in three specific ways, and each one is a place where an agent quietly goes off the rails.
The three assumptions that break
That an SOP decomposes into a clean deterministic tree. Most SOP-to-agent advice imagines the procedure as a tidy sequence of if-then steps that a machine can walk top to bottom. Real operational SOPs are not that. They carry implicit branches the author never wrote down because a human reader would infer them, and they collapse whole judgment calls into a single line like "assess the shipment and proceed accordingly." A tree with unstated branches is not a tree the agent can walk. It is a tree with holes, and the agent falls through them.
That the judgment-heavy work can be skipped or hard-coded. The interesting part of most procedures is exactly the part that resists a fixed rule: the acceptance decision, the exception disposition, the call about whether this case is standard or not. Advice that treats these as edge cases to defer is deferring the operation itself. In regulated work the exceptions are the norm, and an agent that only handles the happy path is an agent that handles almost nothing that matters.
That the SOP, once written, stays put. Almost nothing in the "make your SOP AI-ready" genre says a word about drift. But a document starts going stale the day after it is approved, and an agent has no way to know. It reads the copy it was handed and trusts it completely, with none of the instinct a veteran has that a step "does not sound right anymore." A procedure with no currency guarantee is a procedure the agent will follow off a cliff because it cannot tell the map is out of date.
The agent-ready checklist
Run any SOP you plan to hand an agent against these four requirements. Most will fail on the first line.
- Explicit decision points. Every place the work forks is stated, with the condition that decides it. No "proceed accordingly," no branch left to inference. If a human currently fills the gap from experience, that gap is a decision point the agent needs written down.
- Scenario branches as data. The things that change the route (mode, commodity, risk flag, customer, lane) are structured conditions the agent can evaluate, not prose it has to interpret. The agent describes the case and the process resolves to the route. This is the difference between one scenario-aware process and a folder of near-duplicate documents the agent has to choose between.
- Named owners. Every step and every sign-off has a real accountable owner attached, so the agent knows where to escalate, whose approval a step requires, and who stands behind the version it is running. Accountability that lives only in a RACI chart in another file is accountability the agent cannot act on.
- A currency guarantee. The agent can trust that the version it read is the version in force today, because the process is versioned, under sign-off, and served live rather than copied. No stale fork, no "we think that is the latest." The guarantee is structural, not a promise.
Notice that a markdown SOP in a repo or a wiki fails all four. It has implicit branches, prose scenarios, owners in a separate document if anywhere, and no way to prove it is current. It is a perfectly good artifact for a human who brings judgment and context to fill the gaps. It is not agent-ready, and rewording it more clearly does not change that, because the missing pieces are not wording.
What passing the checklist actually requires
Meeting all four at once is not a documentation exercise. It is a shift from storing a document to holding a process record: a designed model of the work, with decisions and scenarios as data, owners on every step, versioning and sign-off for currency, and an interface an agent can query. That is the layer a process system of record provides, and it is specifically what makes a process record readable by an AI agent over an API, CLI, or MCP. The agent asks the process what to do for this case and gets the same governed answer a person would, current as of today.
This is also the honest answer to why so many agent pilots stall the moment they leave the demo. The demo runs the happy path against a clean example. Production runs the exceptions against a stale document, and the agent has no decision points, no resolved scenario, no owner to escalate to, and no way to know the map changed. For the fuller version of that argument, see why AI agents fail on the process layer. And if your plan is to keep deterministic rules around the agent, the next question is where those rules should live, which is its own decision worth getting right.
Common questions
What makes an SOP agent-ready?
Four things a document almost never has. Explicit decision points, so every branch in the work is stated rather than assumed. Scenario branches described as data, so the agent can resolve the right route for the case instead of guessing which paragraph applies. Named owners on each step, so accountability is attached and escalation has a target. And a currency guarantee, so the agent can trust that the version it read is the version in force today. Miss any one and the agent is acting on faith.
Is not a well-written markdown SOP already machine-readable?
Machine-readable and agent-ready are not the same thing. An agent can parse the text of a markdown SOP the same way it can parse any prose. That is not the problem. The problem is that the text does not tell the agent which of its branches applies to the case in front of it, whether the decisions it implies are the decisions still in force, or who owns the step it is about to skip. Readable characters are not a readable process. The judgment and the currency are missing, and those are the parts the agent cannot supply for itself.
What is wrong with agent operating procedures and similar framings?
They tend to assume an SOP decomposes into a clean deterministic tree, that the judgment-heavy work can be skipped or hard-coded, and that once written the procedure stays put. Real operations break all three assumptions. The exceptions are the operation, much of the work is judgment inside guardrails rather than a fixed branch, and the procedure drifts the day after it is approved. A framing that ignores decision points, scenarios, and drift produces an agent that is confident on the happy path and dangerous everywhere else.
How do I make an existing SOP agent-ready?
Stop treating it as a document to reword and start treating it as a process to model. Pull out the decision points and state each branch. Describe the scenarios as structured conditions rather than prose, so the route resolves from the case. Attach a named owner to every step. Then put it somewhere governed, with versioning and sign-off, and expose it over an API, CLI, or MCP so the agent reads the current version, not a copy that quietly went stale. At that point the SOP is a process record, and the agent has something it can actually run.
Turn one SOP into something an agent can run.
Bring a real SOP to a 30-minute pilot session. Leave with it living in FLOW: decision points explicit, scenarios as data, owners on every step, and a version an agent can trust.
Book a pilot →