Your company already wrote down how things should be done. It’s in the onboarding doc, the Notion wiki, the Google Doc titled "Refunds — READ FIRST." Then you connected an AI agent to your inbox, and none of that writing mattered. The agent never read it. And even if it had, reading a rule and being bound by it are different things.
Why SOPs written for humans fail as agent instructions
A good SOP leans on judgment the reader brings with them. "Use your best judgment." "Loop in Sarah if something looks off." A person fills those gaps with context. An agent fills them with plausible improvisation, which is a polite way of saying it makes things up.
Four problems show up every time someone hands an agent a document meant for people:
- It’s prose, not decision logic. The agent has to guess which sentence is a step, which is a warning, and which is a stale aside from two years ago.
- The limits aren’t checkable. "Be careful with large refunds" gives an agent nothing to compare a number against.
- There’s no stop condition. The document says what to do, never when to stop doing it.
- It goes stale silently. Someone changes the policy in a meeting, and the doc keeps saying the old thing with total confidence.
The most common workaround is pasting the SOP into the agent’s system prompt. That breaks down in its own ways, which we covered in why system prompts are the wrong place for company rules. Short version: prompts are advice. Agents need rules.
What an agent-ready SOP looks like
We call an executable SOP a skill. A skill is a small structured object, not a document. Ours have seven parts:
- Trigger. When this applies: "a customer asks for a refund."
- Procedure. Numbered steps, in order.
- Hard rules. Lines that never move, whoever is asking. Refund cap $200. Window 90 days.
- Guardrails. Conditions that mean stop and hand off to a human instead of improvising.
- Escalation target. The named person or channel that handles what the agent won’t.
- Worked examples. A few real cases with the right answers.
- Owner and version. Who is responsible for it being true, and a history of every change.
Here’s the refund skill from our own demo. An order inside 90 days and under $200: the agent processes it and logs the run. An order at $350: the agent stops, tells the customer a teammate will follow up, and pings the support lead. Same agent, same model, same prompt. The only thing deciding those two outcomes is the skill.
Converting your first process
- Pick one process that’s reversible. Drafting replies to customer inquiries is a good first one: a human still hits send, so the worst case is a bad draft.
- Interview the process owner, and ask for the last five real cases, not the ideal flow. The ideal flow is fiction. The five real cases contain the exceptions that matter.
- Write the trigger first. If you can’t say when the skill applies, an agent can’t either.
- Sort every instruction into hard rule or preference. "Never promise a feature we haven’t shipped" is a hard rule. "Keep it friendly" is a preference. Mixing them teaches the agent that all rules are soft.
- Write the stop conditions before you widen the capability. What amount, what order age, what kind of anger in a customer’s message means a human takes over?
- Give it an owner. A skill nobody owns is a document again.
On the worked examples: two real cases do more than ten abstract rules. Agents, like new hires, generalize from cases. Give them the weird ones.
The part everyone skips: keeping it true
An SOP that drifted from reality is worse than no SOP, because the agent follows it with full confidence. This is the actual hard problem. Wikis rot because updating them is homework nobody assigned.
The fix we landed on: corrections revise the skill instead of piling up next to it. When someone overrides the agent or captures a decision ("max discount is 15% now"), the skill gets a new version and the old one stays in history. Skills that get overridden a lot, or that haven’t been touched while the company changed around them, get flagged to their owner.
One number from our own testing, for scale. We built 120 skills out of GitLab’s public handbook, 2,876 pages of real operating procedures, and benchmarked whether an agent could find the right skill for a given task. First try: 85% of the time. Within the top three: 91.7%. Retrieval at that scale works. The bottleneck is whether what it retrieves is still true, which is why ownership and revision matter more than storage.