How to Rewrite an SOP So an AI Agent Can Follow It

Most standard operating procedures are not complete descriptions of work. They depend on habits, local vocabulary, access that an experienced employee already has, and judgments such as "check whether it looks right." An AI agent cannot reliably recover that missing context. It needs a bounded operating contract: named inputs, approved sources, clear decisions, narrow tools, verifiable outputs, and a safe route to stop. The objective is not to paste a long SOP into a prompt. It is to discover the real process, simplify it, and move each control into the layer best able to enforce it. OpenAI's agent building guide recommends converting dense resources into smaller steps, defining a specific action or output for each step, and capturing edge cases. That is a useful drafting standard, while authorization and hard business rules still belong in software and policy controls. Phase 1: observe the work before rewriting it Begin with the current SOP, representative completed cases, and the people who perform the task. Record where actual practice differs from the document. Ask what operators inspect before acting, which system wins when records conflict, what makes a case unusual, and what evidence proves completion. Do not automate a stale workaround merely because it is written down. Map every step using the same fields: trigger, required input, source of truth, decision, action, output, owner, and failure path. Replace local shorthand with a linked definition. If "active account" means a particular status in a particular database, name that field and system instead of asking the model to infer status from an email. Define every terminal state. A run might finish as completed, rejected, awaiting information, awaiting approval, escalated, or failed safely. Each state needs an observable record. A polished draft is not completion when the business process requires an approved update in a system of record. Phase 2: sort rules, judgment, and authority Label each decision before writing instructions. Deterministic rules include calculations, mandatory fields, eligibility thresholds, destination allowlists, access checks, and prohibited actions. Put these in code, schemas, or policy services. The agent may call the control and explain its result, but it should not recreate the rule from memory. Contextual judgments include classifying an unstructured request, comparing documents, or selecting the relevant approved procedure. An agent can assist here when the expected evidence and acceptable uncertainty are defined. Require source identifiers for consequential conclusions. Authority decisions belong to an accountable person or an already authorized system. Sending public communications, committing funds, changing permissions, deleting records, or making high impact decisions should not hide inside an instruction to "resolve the case." Specify who approves the exact action, how approval is authenticated, and when it expires. NIST's AI Risk Management Framework says measurement should reflect deployment context and that residual risk should stay within the organization's tolerance. Use that principle to decide where judgment ends and mandatory review begins. Phase 3: write the agent ready routine Give the routine one purpose, one owner, and a narrow scope. State its allowed users, systems, data classes, tools, and prohibited actions. Then define the minimum valid input. If required data is missing, the first branch should request it or escalate; the agent should not guess. Use observable verbs such as retrieve, compare, validate, draft, call, record, ask, and stop. For every step, specify: the input and approved source; the action or tool call; the expected output schema; the success check; the failure, retry, or escalation route. Write branches as conditions with exclusive outcomes. For example: if the customer identifier is absent, ask once; if it remains absent, create a review item with the missing field code and stop. Distinguish "no matching record" from "the lookup tool failed." Those states require different responses. Describe each tool as a contract. Include its purpose, required parameters, returned fields, permission behavior, common errors, timeout behavior, and whether a retry is safe. The Model Context Protocol specification similarly treats tool inputs through schemas and calls out the need to validate inputs, apply access controls, rate limit calls, sanitize outputs, and request confirmation for sensitive operations. Keep read, draft, and commit capabilities separate so approval can attach to the consequential operation. Set budgets: maximum turns, tool retries, elapsed time, spend, records touched, and external messages. State which limit ends the run and which creates an escalation. Phase 4: make approvals and escalations usable An approval request should identify the proposed action, exact arguments, destination system and record, supporting evidence, expected effect, and reversibility. Bind approval to that payload. If an amount, recipient, file, or operation changes, require fresh approval. Define escalation as structured work, not a generic failure message. Include the reason code, completed checks, evidence consulted, missing information, tools attempted, current state, and recommended next step. The reviewer should be able to continue without replaying the full interaction. For an initial deployment, route uncertainty and high impact actions to people even if the model sounds confident. Confidence language is not authorization, and an approval screen is not useful when it omits the consequence being approved. Phase 5: test the SOP as an executable specification Build an evaluation set from representative process patterns with sensitive data removed or appropriately protected. Include the ordinary path plus missing inputs, conflicting records, obsolete policy, duplicate requests, permission denial, tool timeout, partial success, and malicious instructions inside retrieved content. For each case, record the expected terminal state, required evidence, allowed calls, and forbidden actions. Score outcome correctness, tool selection, argument accuracy, source use, approval compliance, duplication, and escalation quality. A fluent explanation cannot offset an unauthorized change. Run the routine in a sandbox, then shadow mode, before granting narrow write access. Review traces to locate the defect: instruction, source data, tool contract, authorization, model behavior, or evaluation. Change one layer at a time and rerun the affected cases plus a holdout set. Phase 6: publish, version, and maintain two artifacts Keep the human SOP and the agent specification linked but distinct. The human document explains policy, rationale, accountability, and training context. The agent specification contains executable steps, schemas, permissions, limits, and tests. Give both an owner, version, approval date, change history, and review trigger. Retest when policy, data definitions, tools, permissions, models, or APIs change. Monitor corrections, escalations, duplicate attempts, unauthorized calls, and overrides. Add confirmed failures to regression tests, but fix excessive access or a weak tool contract instead of endlessly adding prompt phrases. A useful agent ready SOP makes every route inspectable from a defined start to a verifiable finish. It names sources of truth, separates judgment from authority, enforces hard rules outside the model, carries context into review, and stops safely when its operating contract no longer applies. Sources A practical guide to building agents https://openai.com/business/guides and resources/a practical guide to building ai agents/ AI Risk Management Framework Core https://airc.nist.gov/airmf resources/airmf/5 sec core/ Tools Model Context Protocol https://modelcontextprotocol.io/specification/2025 11 25/server/tools Cover image credit Cover image by Verbadsa , made available under CC BY SA 4.0 . WIKIVISE cropped and converted the source image.