What is an agentic SOP? Skills vs procedures | Agentic ERP Quickstart
Put the procedure in code and a business owner cannot change it. Put it all in documents and nothing is enforced. Where the useful boundary actually falls.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 7What is an agentic SOP? Skills vs procedures | Agentic ERP Quickstart This article
What is an agentic SOP? Skills vs procedures | Agentic ERP Quickstart
Write your business procedures into the agent's code and the finance team cannot change a threshold without an engineer, a review, and a release. Drop them into a folder of documents instead and nothing guarantees the agent ever reads the right one, or reads one at all. Both failures are common, and both come from treating domain knowledge and operating procedure as a single artifact. They are not one artifact, and the line between them decides who in your organization is allowed to change what.
Series: Building governed ERP agents on AWS · Series guide →
This post: Why skills and SOPs are separate artifacts, and what has to happen when you change one or the other.
Prereq: None. If you want to follow along in a running deployment, start with the deploy walkthrough . The SOP authoring walkthrough is the hands-on version of this post.
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. Three terms matter below:
- An SOP is a standard operating procedure: the written steps a person would follow to resolve one kind of exception. Here, the agent reads it.
- A skill is a deployed package that tells the agent about one business domain, such as accounts payable. It declares which tools the agent may use, which values it knows, and which SOP applies to which kind of case.
- A process type is the label on an incoming case, such as an invoice-to-purchase-order mismatch. It is how the agent knows which procedure to load.
The problem: procedure changes should not need a deployment
A finance team raises an approval threshold after month end. It is a reviewed, legitimate policy change, and it affects one exception type.
If that threshold lives inside the agent's code, changing it means a code change, package validation, and a deployment. That is tolerable once. It stops being tolerable when the agent handles ten processes, each with a different owner and a different revision cycle.
So the question is not whether procedures matter. It is where they should live, and what has to change when they change.
Two approaches that fail
Put everything in code. A business policy update now shares a release path with routing logic and infrastructure. Adjusting one tolerance triggers a full redeploy, and the finance team waits on an engineering queue.
Put everything in a document folder. The agent has procedures, but no idea which tools it may use, which contacts own an escalation, or which document applies to the case in front of it. It cannot tell one process type from another.
Rely only on search. Retrieval-augmented generation, where the agent searches a document store and uses what comes back, is the right tool when the agent genuinely needs to look something up. But when a case arrives already labeled with its process type, you already know which procedure applies. Searching for it adds a chance to retrieve the wrong one.
One thing none of these approaches can do is turn SOP text into a permission system. SOPs guide decisions. They do not authorize SAP writes. Authorization is a separate layer, made of Cedar policy, IAM, and SAP-side roles.
The split: skills frame the work, SOPs supply the procedure
The implementation uses two artifacts with two different release paths:
| Artifact | What it does | How it changes |
|---|---|---|
Skill (config.json plus base_prompt.txt) | Maps process types to SOP paths, declares the allowed tools, and defines constants and contacts | A code deployment, versioned and validated |
| SOP (in the managed corpus) | Holds the actual procedure for one process type | A content update: review, then sync to the knowledge base |
When a case arrives with a known process type, the router does six things:
- Finds the skill that owns that process type.
- Loads that skill's base prompt.
- Injects the shared platform mechanics.
- Fetches the mapped SOP from the corpus.
- Resolves the declared constants and contacts.
- Assembles the full agent context.
1
2
3
4
5
6
7
8
# TEACHING VERSION; the essential pattern
# Full reference: agentcore/agent/utils/skill_router.py
def assemble_context(process_type: str) -> str:
skill = find_skill_for(process_type)
prompt = inject_platform_mechanics(skill.base_prompt)
sop = fetch_mapped_sop(skill, process_type)
return inject_sop(resolve_constants_and_contacts(prompt, skill), sop)The payoff is the line between the two paths. Editing the body of an SOP that already exists is a content sync, with no code change. Adding a new skill, or changing which process type maps to which document, is a deployment.
Which SOP formats work today
The router handles plain text, Markdown, and PDF, using
PyPDF2 to extract text from PDFs. Text and Markdown are the easiest to author and the a to review in a pull request.Some sources do not work directly. Scanned documents, diagram-heavy PDFs, screen recordings, and voice recordings all need a conversion step first, because the ingestion path expects text. You can absolutely write an SOP based on those materials. You just cannot hand them to the agent as they are.
How the SOP storage is protected
The S3 bucket holding SOPs uses:
- Versioning. Prior versions are retained. A lifecycle rule moves them to Amazon S3 Glacier after 30 days and expires them after 7 years.
- Non-public, TLS-only access.
- Write and delete restricted to the
sop-adminprincipal.
Those are real controls. Be precise about their limits, because each one is easy to overstate:
- Versioning is not permanent retention. The lifecycle rules still apply.
- Restricting writes is not the same as restricting file types. There is no format allowlist.
- Nothing verifies a digital signature on an uploaded SOP.
You still need a human review process: who approves a change, how it gets tested, and when it goes live.
Trade-offs
| You gain | You give up |
|---|---|
| Procedure owners update SOPs without waiting for a code release | Two things to reason about instead of one: content changes and skill or routing changes |
| Routing, tool scope, and authorization stay explicit and reviewable | Everyone has to know which of those two boundaries they are crossing |
Where this design breaks down. If the authoritative version of your process is a diagram, a scan, or a recording, you need an extraction and review step before the agent can use it. Build that into your workflow before you treat the result as an SOP.
The takeaway
The skill is the stable frame. The mapped SOP is the part that changes. Business owners revise reviewed content on their own cycle, and the agent's code stays still while they do it.
Where to go next
- How to write an SOP an agent can follow . Map a procedure to a skill, resolve constants, and sync it to the knowledge base.
- How an agent loads its procedure . Routed injection, focused lookup, and vector search, and why they behave differently.
- Adding skills (repository docs) . The full reference for skills and SOP mappings.
Series: Building Production-Grade ERP Agents on AWS (18 articles)
- …
- 7What is an agentic SOP? Skills vs procedures | 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