AWS Builder Center

Builder Center

Deploy an AI agent for SAP exception handling on AWS | Agentic ERP Quickstart

Deploy an AI agent for SAP exception handling on AWS | Agentic ERP Quickstart

One launcher command puts an agent in your AWS account that works any case your team handles from a written procedure. Accounts payable ships with it, and SAP is optional to get started.

Series: Building Production-Grade ERP Agents on AWS (18 articles)

  1. 1
    Building Governed ERP Agents on AWS: Series Guide
  2. 2
    Deploy an AI agent for SAP exception handling on AWS | Agentic ERP Quickstart This article
  3. 3
    How should an AI agent authenticate to SAP? | Agentic ERP Quickstart

zachdaniels

Solutions Architect I @ AWS | Applied AI for SAP/ERP

Deploy an AI agent for SAP exception handling on AWS | Agentic ERP Quickstart

Month-end leaves a pile of ERP exceptions nobody wants: invoices that do not match their purchase order, goods receipts that never arrived, accruals stuck on hold. Every one of them needs judgment, which is why rules engines never cleared the backlog, and every one of them touches financial records, which is why nobody sane hands them to an unsupervised model. This post gets a governed agent for that work running in your own AWS account in under half an hour, and it does not need an SAP system to prove it works.
Series: Building governed ERP agents on AWS · Series guide → 
This post: Get the reference implementation running in your own AWS account and confirm the agent responds.
Prereq: An AWS account you can deploy into. No SAP system needed.

What you get from this post

A working deployment in your own AWS account, a browser sign-in, and a real response from the agent. You do not need to connect SAP to reach that point, which means you can evaluate the reference implementation before you start an integration project.
You also get:
  • A read-only readiness check you can run before anything touches your account.
  • The two values the guided launcher asks for, and what each one affects.
  • A clear success test, so you know whether the deployment worked.
  • The two controls to understand before you connect SAP, including the one people mistake for a write switch.
Time: the deployment guide estimates 20 to 30 minutes for a first run, including 10 to 20 minutes of CDK deployment. Actual time varies by account and Region.
You will need: an AWS account, Node.js 20 or later, Python 3.10 or later with pip, configured AWS CLI credentials, and Amazon Bedrock model access in your target Region.
IMPORTANT
Bedrock model access is the most common first-deployment failure. Request access for the Claude models in your target Region before you begin. If you skip it, nothing fails during deployment. The error appears later, as a model-not-found response when you first talk to the agent.

What the Quickstart is

The Agentic ERP Automation Quickstart  is an open source reference implementation, maintained by AWS, for handling ERP exceptions with an AI agent on Amazon Bedrock AgentCore. Think of the exceptions that pile up at month end: invoices that do not match their purchase order, goods receipts that never arrived, accruals on hold. Too variable for traditional automation, too sensitive to hand to an unchecked model.
The deployment includes the agent runtime, authentication, case and queue infrastructure, knowledge base resources, and a web frontend. Which optional integrations you get depends on your configuration.
Two things to set expectations. First, a first run does not need SAP connectivity, so you can deploy, sign in, and confirm the agent responds before adding any SAP credentials. Second, this is a reference implementation and not a production-readiness test. Before production, assess its controls, SAP release compatibility, networking, identity model, and operational requirements against your own environment.

About cost

The AP benchmark in the repository recorded an average Bedrock inference cost of $0.26 across 41 of the 50 cases that had cost data. Six fully resolved cases, each using two invocations, averaged $0.56.
Those are benchmark results from one measured run, not a price commitment or a quote for your workload. Idle cost is low, but it is not zero, so clean up when you finish evaluating. The benchmark documentation  in the repository records how those figures were produced and what they leave out.

Step 1: Clone and check readiness

1
2
git clone https://github.com/aws-samples/sample-agentic-ai-process-automation-for-sap.git
cd sample-agentic-ai-process-automation-for-sap
Before anything touches your AWS account, run the readiness check:
1
python3 launch.py doctor
This inspects your local environment and your AWS access. It installs nothing and creates nothing.
You do not need a global CDK installation. The project uses the pinned CDK version declared in cdk/package.json. Docker and Finch are not required for the default ZIP deployment type.

Step 2: Run the guided launcher

1
python3 launch.py
The launcher checks your environment, collects configuration, shows the target account and Region, and asks you to confirm. Nothing is written to AWS until you approve that target, and declining stops the process.
It asks for two values:
  • Stack name. A short kebab-case identifier, up to 35 characters. It prefixes resource names, parameter paths, and secret names, so pick something you will recognize later.
  • Admin email. The launcher can create the first Amazon Cognito user and email a temporary password to this address. Leave it blank only if you intend to create that user yourself after deployment.
The flow also offers optional SAP credential sync and knowledge base sync. Skip both for now. You can run them later, once you have validated the application without SAP.
A successful run completes five stages:
  1. Configuration and target confirmation.
  2. CDK bootstrap and stack deployment.
  3. Lambda refresh.
  4. Frontend deployment.
  5. Optional SAP and knowledge base steps.
When the frontend is ready, the launcher prints the application URL. Keep it with your deployment record, and do not paste account-specific URLs into anything public.

Step 3: Sign in and send a message

Open the application URL the launcher printed. If you supplied an admin email, check that inbox for a temporary password and complete the password change. Then send the agent a simple message.

Step 4: Confirm it worked

A response in the chat interface is your success signal. It confirms two things: you can reach the application, and the deployed agent can respond.
For deeper validation, run the post-deployment tests:
1
2
3
4
cd test-scripts
python3 test-gateway.py
python3 test-agent.py
python3 test-memory.py
You can check the state of the deployment at any time later with:
1
python3 launch.py status

What connecting SAP changes

Without SAP, the application runs and the agent responds, but it cannot work real SAP exceptions. When you are ready to connect a system, two separate paths reach SAP:
  • The odata_poller Lambda function polls SAP for exceptions using a configured technical account.
  • The agent does its SAP reads, writes, and service discovery through the external AWS for SAP MCP Server, which you deploy separately.
Those are two independent pieces of configuration, and it is worth knowing that before you start. The auth profile overview  covers the identity profiles that govern them. The default, cognito-basic, reaches SAP as a configured technical user. entra-obo is the verified path when SAP needs to see the individual signed-in person, on the tested S/4HANA 2023 system running SAP_BASIS 7.58.

Two controls to understand before adding SAP

This is a good moment to separate the control that starts work from the controls that permit writes, because they are easy to conflate.
trigger_mode decides whether unattended work starts on its own. In manual mode, the poller does not automatically queue cases. In auto mode, it can. That is all it does. It is not a SAP write switch.
SAP write availability depends on your deployed topology. On a Gateway path, Cedar policy can enforce permissions only when the relevant Gateway target and the policy engine are deployed and enforcement is set to ENFORCE. On the direct on-behalf-of path, the runtime bypasses Gateway entirely, so write availability comes down to the external MCP Server's deploy-time write flags and SAP-side authorization.
Do not assume a policy engine covers every route. Before you make any claim about write controls, check the stack outputs, the identity path you selected, the external MCP configuration, and the SAP permissions themselves.

Add SAP credentials later

Once you have set sap.base_url for the poller path, sync the SAP credentials:
1
python3 launch.py sync-sap
To publish SOPs and SAP API documentation to the knowledge base:
1
python3 launch.py sync-kb
Both are separate operational steps, and neither changes the fact that you can deploy and test this application without SAP.

Clean up when you are done

If this was an exploratory deployment, remove it when you no longer need it.
WARNING
Teardown deletes deployed resources, including S3 buckets and DynamoDB tables. Save anything you want to keep before you run it.
1
cd cdk && npx cdk destroy --force

Where to go next

# sap# amazon-bedrock-agentcore# getting-started# aws-cdk# enterprise

Series: Building Production-Grade ERP Agents on AWS (18 articles)

  1. 1
    Building Governed ERP Agents on AWS: Series Guide
  2. 2
    Deploy an AI agent for SAP exception handling on AWS | Agentic ERP Quickstart This article
  3. 3
    How should an AI agent authenticate to SAP? | Agentic ERP Quickstart
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article