In a July 8 AWS for SAP blog, AWS introduced an Agentic Standard Operating Procedures framework designed to help AI agents resolve ERP exceptions by reading approved business procedures, retrieving live SAP data, taking controlled actions, escalating high-risk cases to humans, and logging every step for audit.
The framework runs on Amazon Bedrock AgentCore and uses Strands, AWS’s open-source agentic SDK. It connects to SAP systems through OData and MCP-based tooling, allowing agents to work across processes such as unmatched payments, blocked invoices, purchase order approval holds, month-end close, intercompany reconciliations, and accrual workflows.
AWS is aiming the framework at work that is too variable for rigid robotic process automation, too sensitive for unconstrained AI, and too important to leave buried in manual exception queues. That should help push agentic AI performance beyond answering questions about ERP data toward acting inside ERP workflows. That shift puts standard operating procedure (SOP) quality, data access, identity controls, authorization rules, and audit evidence under much closer scrutiny.
Analysis
What this means: ERP agents need more than model intelligence. Finance, procurement, and shared services teams need agents that can follow approved procedures, respect business thresholds, prove what they did, and stop when judgment or approval is required. AWS is making the case that SOPs can become the control surface for agentic ERP work.
From Scripts to SOP-Driven Agents
The AWS framework targets the operational gap left by earlier automation approaches.
Robotic process automation can mimic clicks, but it often breaks when user interfaces change. Classical machine learning can predict exceptions, but it cannot reliably resolve them. Built-in ERP automation can handle structured scenarios, but manual work still piles up across invoice exceptions, payment matching, purchase order holds, intercompany issues, and close activities.
AWS’s answer is a single SOP-driven agent that interprets procedures from a curated knowledge base and invokes tools at runtime based on the exception type and process context.
Instead of building a separate agent for each process, the architecture uses approved SOPs as reasoning context. Business teams can update the procedure without requiring a code change, while technical teams can keep the agent grounded in known systems, approved APIs, and structured guardrails.
ERP exceptions rarely follow a perfect script. A blocked invoice may require checking purchase order data, vendor history, goods receipt status, approval thresholds, and business context. An unmatched payment may require reconciling bank data, open invoices, customer information, and cash-application rules.
A useful ERP agent has to reason through those steps without inventing evidence, bypassing policy, or turning every exception into a new IT project.
Guardrails in the Architecture
AWS’s framework is built around progressive trust. Agents can start in advisory mode, where humans take every action. They can then move into supervised execution, where the agent does more of the work but humans approve key steps. Eventually, agents can resolve lower-risk exceptions autonomously when confidence is high and defined thresholds are met.
The framework also separates agent identity from human identity. When the agent acts on its own, it uses a service account. When a human intervenes, AgentCore Identity propagates the verified human identity through to the target system. That separation helps compliance teams distinguish agent-initiated actions from human-approved actions.
Authorization is handled through Cedar policies in AgentCore Policy. Help Net Security highlighted the deny-by-default model, where policies govern what an identity can do before the tool call reaches SAP. For example, a company could allow an agent to read purchase orders but only post journal entries below a defined dollar threshold.
The architecture also captures reasoning traces, tool invocations, escalation events, human decisions, resolution outcomes, timestamps, authenticated identities, and SAP transaction references in an append-only state layer.
Analysis
What this means: Trust has to be designed into the ERP agent before it touches the transaction. The most important control is not a dashboard after the fact; it is the ability to decide who the agent is, what it can do, when it must escalate, and how every action will be reconstructed for audit.
SAP Data Actionable Through OData
The framework depends on access to live SAP data. AWS describes an architecture where Amazon EventBridge triggers AWS Lambda on a configurable schedule to poll SAP OData services for exceptions. New exceptions are written into Amazon DynamoDB, and the agent is invoked to retrieve the relevant SOP, check SAP and connected systems, and determine the next step.
The agent uses a knowledge base containing SAP OData API specifications to discover the correct endpoints and fields at runtime. AWS says that helps prevent hallucinated API calls because the agent can only invoke endpoints it can find in the documentation.
This builds on the May general availability of AWS for SAP MCP Server on Amazon Bedrock AgentCore. AWS said that server was purpose-built to connect AI agents directly to SAP ERP systems securely and at scale, using MCP and SAP OData standards. It supports processes across finance, procurement, logistics, and supply chain operations and can create, read, update, and delete SAP business objects such as sales orders, purchase orders, materials, and finance documents.
This is where agentic AI becomes more serious. The agent can interact with SAP business objects, route exceptions, prepare postings, trigger escalations, and update process state. The ERP value will depend on whether companies can control that access tightly enough to satisfy finance, audit, security, and process owners.
AI for Exception Management
AWS gives one example of the framework applied to purchase order accruals.
A global manufacturer used the approach to manage more than $250 million in custom tooling purchases across more than 1,000 active purchase orders. AWS said the agent retrieved the applicable SOP, resolved each purchase order through the appropriate workflow, and created parked journal entries in SAP for finance approval. Work that previously consumed more than 30 days of manual effort per close cycle was reduced to minutes per purchase order.
The example fits a broader pattern. Many ERP environments do not fail because the core system lacks automation entirely. They struggle because exceptions keep escaping the happy path and landing with experienced employees who know the policy, the workaround, the vendor pattern, or the approval nuance.
Agentic SOPs are an attempt to capture that procedural knowledge and apply it repeatedly, while still escalating cases that exceed policy or confidence thresholds.
Analysis
What this means: Exception work is a proving ground for ERP agents. These workflows are repetitive enough to justify automation, but judgment-heavy enough to expose weak controls. Finance and procurement leaders should treat agentic SOPs as a test of whether their procedures are clear, current, and executable by both people and machines.
Sponsor Industry-Grade Research
The SOP Quality Problem
The framework also exposes a practical readiness issue. An AI agent can only follow a procedure that is clear enough to retrieve, interpret, and apply. Many organizations still rely on fragmented SOPs, tribal knowledge, outdated process documents, informal approval rules, and exceptions handled through email or spreadsheets.
That creates a new kind of AI preparation work. SAP teams may need to review which SOPs are authoritative, who owns them, how often they change, which thresholds require escalation, which systems hold the evidence, and which actions can be automated under policy.
The technical architecture can enforce controls, but it cannot fix a broken procedure on its own.
This makes agentic ERP automation a joint effort across IT, finance, procurement, audit, security, and business process owners. IT can connect the agent to SAP. Finance and procurement have to define what good judgment looks like. Audit has to know what evidence will be acceptable. Security has to enforce identity and access. Process owners have to keep SOPs current.
New ERP Control Model
AWS’s Agentic SOPs framework fits into a larger shift across enterprise software. Agents are being pushed closer to the systems that run the business.
In SAP environments, that means agents may soon help reconcile payments, clear blocked invoices, prepare journal entries, resolve purchase order issues, and support close activities. The opportunity is meaningful, but the control model has to change with it.
Traditional ERP controls were built around human users, system roles, approvals, segregation of duties, workflow status, and audit logs. Agentic ERP introduces a new actor that can reason, invoke tools, carry context, and operate across systems. That actor needs its own permissions, thresholds, logging, monitoring, evaluation, and escalation model.
AWS is not saying every exception should become autonomous immediately. The stronger message is that agentic AI needs a controlled adoption path. Start with advice. Move to supervised execution. Automate only where the process is understood, the risk is bounded, and the audit trail is strong enough to defend.
Analysis
What this means: SAP leaders should not evaluate agentic ERP only by what the agent can resolve. They should ask how the agent proves its reasoning, which identity it uses, which actions it cannot take, where it escalates, and how the business will audit the full chain of events. The control model will decide whether ERP agents stay in demos or enter daily operations.
