How to write an SOP an AI agent can actually follow | Agentic ERP Quickstart
Name every entity set, keep thresholds out of prose, and pull variable values into config. The authoring rules that survive an SAP reviewer, plus a checklist.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 8How to write an SOP an AI agent can actually follow | Agentic ERP Quickstart This article
How to write an SOP an AI agent can actually follow | Agentic ERP Quickstart
Most procedures written for people are unusable by an agent for the same reason they frustrate a new hire: the thresholds are buried in prose, the system objects are implied rather than named, and the escalation path says "use your judgment." An agent will use its judgment too, which is exactly the problem. Two authoring rules do most of the work: name every entity set explicitly, and get every number out of the sentences and into configuration where somebody can change it without rewriting the document.
Series: Building governed ERP agents on AWS · Series guide →
This post: The hands-on workflow for turning a reviewed procedure into an SOP the agent can actually load.
Prereq: An existing skill and a known process type. The agentic SOP model explains why skills and SOPs are separate, if you want that background first.
What you get from this post
A procedure written so that a reviewer can check every decision, boundary, and escalation without guessing what you meant. By the end you will have an SOP mapped to a skill, its variable values pulled out into configuration, and the document synced to the knowledge base.
You also get:
- The pre-flight check on the skill config, which tells you early whether your change is a content update or a code deployment.
- A structure and a set of keywords that make policy choices visible at a glance.
- Two rules that SAP reviewers care about most: name every entity set, and keep thresholds out of prose.
- A reviewer checklist you can paste into a pull request.
Time: about 8 minutes to read. Writing a real SOP takes as long as agreeing on the procedure does.
Companion reading: For the general SOP authoring framework, including locked and open zones, the reasoning behind RFC 2119 keywords, and common anti-patterns, see Sagar Tallapragada's How to write agent SOPs that give AI agents space to think . This post covers the implementation-specific wiring.
New to this series? Start here
The Agentic ERP Automation Quickstart is an open source reference implementation that deploys an AI agent for work your team does by hand from a written procedure, on Amazon Bedrock AgentCore. Accounts payable is the worked example, where a case looks like an invoice that does not match its purchase order. A new process type is a skill directory and your own SOPs. Four terms recur below:
- An SOP is a standard operating procedure: the written steps for resolving one kind of exception. Here, the agent reads it.
- A skill is a deployed package covering one business domain, such as accounts payable. It declares the allowed tools, the known values, and which SOP applies to which case.
- A process type is the label on an incoming case. It is how the agent picks the right procedure.
- An entity set is a named collection in a SAP OData service, such as
A_SupplierInvoice. OData is the REST-style API protocol SAP exposes for business data.
Step 1: Check the skill config before you write
Open the target skill's
config.json and confirm all five of these with the skill's owner:| Check | Where to find it |
|---|---|
| The process type that routes to this SOP | The process_type_to_sop mapping |
| The SOP file path it expects | The same mapping. The value is the S3 object key. |
| Constants the SOP is allowed to reference | The constants object |
| Contacts available for escalations | The contacts object |
| Allowed SAP entity sets | The skill's tool grants, plus the SAP service catalog |
IMPORTANT
If you need a new process type, a new constant, or a new tool, that is a skill change and it needs a code deployment. Only edits to the body of an SOP that already exists are content updates. Sort out which kind of change you are making now, because it decides who has to be involved.
Step 2: Use the standard structure
Every SOP in this implementation follows the same skeleton:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Version 1.0
## Purpose and Scope
<What this procedure covers. What it explicitly does NOT cover.>
## Preconditions
<What must be true before the agent starts.>
## Steps
<Numbered, single-action instructions using RFC 2119 keywords.>
## Escalation Rules
<When to stop. Who to notify. What evidence to include.>
## Reference
<Tolerances, contacts, revision history.>Use the RFC 2119 keywords consistently, because they let a reviewer spot every policy choice by scanning:
- MUST means mandatory, with no exceptions.
- SHOULD means recommended, and an exception needs a justification.
- MAY means optional, at the agent's judgment.
NOTE
These keywords are an authoring convention and nothing more. They do not make the model's output deterministic, and they grant no SAP permissions. Their value is that a human reviewer can audit intent quickly.
Step 3: Write instructions that stand alone
Too vague: "Check the invoice and escalate if it looks wrong."
That sentence gives a reviewer nothing to verify. Write each instruction so it carries its own context:
1
2
3
4
5
6
7
8
9
10
## 3. Validate the invoice amount
3.1 The agent MUST read the invoice, purchase order, and goods-receipt
records before calculating a variance.
3.2 The agent MUST compare `InvoiceAmount` with `NetOrderAmount` using
the configured {{AMOUNT_TOLERANCE}}.
3.3 If the absolute variance exceeds {{AMOUNT_TOLERANCE}}, the agent MUST
escalate with: document IDs, calculated variance, and source values.Three things make that version reviewable. It names the records the agent has to read. It states the boundary the comparison uses. And it specifies exactly what evidence travels with the escalation.
Step 4: Name every SAP entity set
Do not write "look up the invoice in SAP." That hides the data boundary, which makes it impossible for a SAP reviewer to confirm service activation and authorization. Name the collection instead:
1
2
The agent MUST read the `A_SupplierInvoice` entity set before evaluating
invoice status.Then specify the fields and filters. If a step writes data, name the operation explicitly, and give it both a precondition and an escalation path.
Step 5: Put thresholds in config, not in prose
Any value that can change belongs in the skill's
constants, referenced from the SOP with a {{SYMBOL}} placeholder:1
2
3
4
5
{
"constants": {
"AMOUNT_TOLERANCE": "100.00"
}
}1
The agent MUST escalate when the variance exceeds {{AMOUNT_TOLERANCE}}.At runtime, the router substitutes every constant that the skill declares. If a symbol is not declared, it stays in the prompt as the literal text
{{AMOUNT_TOLERANCE}}. That is deliberate. A placeholder visible in the prompt is an obvious signal that the SOP or the config needs fixing before release, which is safer than silently substituting a default.Step 6: Write the escalations before you need them
Every non-trivial procedure needs a stop condition. Be explicit about three things: what the agent must not do, who owns the next decision, and what evidence has to travel with the handoff.
1
2
3
4
If the supplier name on the invoice does not match the PO supplier,
the agent MUST NOT update the invoice. The agent MUST escalate to
{{AP_EXCEPTION_OWNER}} with: invoice ID, PO ID, both supplier values,
and source timestamps.Good escalation rules stop the agent from continuing simply because the next step is technically available to it.
Step 7: Sync to the knowledge base
Once the SOP owner and the SAP reviewer have approved the document, confirm the skill mapping points at the right file. Then sync:
1
python3 launch.py sync-kb --only sopsWhat that does: it syncs the local SOP directory to S3, then starts an Amazon Bedrock ingestion job.
WARNING
The sync deletes remote objects that have no local counterpart. If anything was uploaded directly to the bucket and does not exist locally, save it before you run this.
What it does not do: it does not confirm that ingestion finished, or that it finished correctly. Check the ingestion status in the target environment after the command returns.
Reviewer checklist
Before you mark the SOP ready:
- [ ] Every MUST, SHOULD, and MAY reflects a real policy choice, not habit
- [ ] Every SAP data action names its exact entity set or operation
- [ ] Every variable value is declared in
config.jsonand referenced as{{SYMBOL}} - [ ] Every escalation names an owner and the required evidence
- [ ] The version and revision history are updated
- [ ] The SOP owner, the SAP integration owner, and the release reviewer have all approved
Where to go next
- How an agent loads its procedure . Routed injection, focused lookup, and vector search, and why the three behave differently.
- Adding skills (repository docs) . The full reference for skills and SOP mappings.
- Deployment guide . Knowledge base synchronization details.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 8How to write an SOP an AI agent can actually follow | Agentic ERP Quickstart This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article