To integrate AI agents with SAP S/4HANA, expose a small set of approved business operations, usually OData services, through a governed gateway, and let the agent call only those operations under a scoped identity.
Reads come first. Writes such as creating a purchase requisition need server-side validation and a named approver. The agent should never compose raw OData URLs or hold broad SAP credentials.
This guide covers three integration patterns, the controls each needs, a worked example and a pilot plan. It is written for SAP architects, integration leads and CIOs evaluating agent use cases on their ERP.
Why SAP Integration Is the Hard Part
The model is rarely the bottleneck in an ERP agent project. The work sits in authorizations, data quality, concurrency handling and change control inside SAP.
• Authorizations: SAP roles are granular; the agent's access must map to them, not bypass them
• Data semantics: entity sets, keys and status codes need business context the model does not have
• Concurrency: updates may need ETag handling and CSRF tokens
• Change control: transports, releases and upgrades can change the APIs agents depend on
Three Integration Patterns
Most enterprise designs fall into one of three patterns. They are not exclusive; many landscapes combine a gateway with MCP tools.
| Pattern | How it works | Fits | Main risk |
|---|---|---|---|
| Direct OData through API management | Agent tools call curated OData services via an API proxy | Teams with mature API management | Tool sprawl if every service is exposed |
| MCP gateway over SAP APIs | Selected APIs are published as MCP tools behind the same gateway policies | Several AI clients needing the same access | Tool descriptions drive agent choices and need review |
| Middleware or event-driven | Agent writes to a queue or integration flow; SAP posts asynchronously | Write-heavy or batch processes | Slower feedback to the user |
SAP's architecture guidance for agents as API consumers recommends one governance plane: expose agent tools from the same API proxies that serve other channels, rather than building separate agent-only paths.
Step 1: Pick One Process and Its Operations
Choose a process with clear rules and measurable volume, such as purchase-order status, invoice-mismatch triage or customer credit checks. List the exact operations the agent needs.
For each operation, record the OData service, entity set, fields, and whether it reads or writes. AWS's SAP MCP documentation notes that S/4HANA OData services must be activated in SAP Gateway and enabled as service type WEB_API.
Step 2: Map Identity and Authorizations
Decide whether calls run as the end user, through principal propagation, or as a technical user with restricted roles. SAP guidance recommends validating token issuer and audience at the gateway and propagating user identity where the backend applies its own checks.
• Use separate credentials for agent-to-gateway and gateway-to-SAP access
• Grant only the roles each operation needs
• Review the technical user's roles with your SAP security team before testing
Step 3: Design Write Controls
Writes and function imports can trigger business side effects. Treat them as approval actions by default, and keep the expected effect visible to the approver.
• Validate first: check fields against metadata and reject read-only fields
• Handle concurrency: pass ETags and CSRF tokens correctly
• Make retries safe: use idempotency keys so a retried call does not post twice
• Record evidence: log operation, parameters summary, approver and SAP response
Step 4: Ground the Agent in Business Context
The agent needs to know what a status code means and which plant or company code applies. Provide this through curated tool descriptions and a small reference knowledge base, not by letting the model guess.
Retrieval over SAP documentation and internal process notes is a RAG problem. Our guide on how to evaluate a RAG system explains how to test it.
Worked Example: Purchase-Order Status and Expedite Requests
Illustrative example: a hypothetical design, not a customer project. Buyers ask an internal agent about delayed purchase orders and want to request expedites.
| Tool | SAP operation | Effect | Control |
|---|---|---|---|
| get_po_status | Read purchase order header and items | Read | Scoped to buyer's purchasing group |
| list_overdue_items | Read schedule lines past delivery date | Read | Max 200 rows per call |
| draft_expedite_note | Create a note for vendor follow-up | Draft | Buyer reviews before sending |
| change_delivery_date | Update schedule line | Write | Named approver; ETag required |
Version 1 ships the three read and draft tools. The date-change tool waits until the team has reviewed four weeks of logs and confirmed the agent selects the right items.
Pilot Plan
Illustrative example: durations below are planning assumptions, not measured results.
| Phase | Weeks | Exit criteria |
|---|---|---|
| Phase 1: Discovery | 1 to 2 | Process, operations, roles and success metrics agreed |
| Phase 2: Read-only build | 3 to 5 | Read tools pass accuracy and authorization tests |
| Phase 3: Limited users | 6 to 8 | Pilot group uses agent; issues logged and triaged |
| Phase 4: Write trial | 9 to 12 | One write tool with approvals runs without unrecoverable errors |
LuMay's pricing page lists a Discovery Sprint and a Production Pilot as engagement formats; scope and price are set per project.
Common Mistakes to Avoid
• Exposing whole services: publishing every entity set gives the agent too many choices and widens the blast radius
• One technical user for everything: broad roles make audit findings hard to explain
• Skipping the sandbox: test writes in a non-production client with realistic master data first
• Ignoring upgrades: API changes in a release can silently break tools; add contract tests to your transport process
• No business owner: each tool needs an owner who approves its description, limits and approval rules
Questions to Ask Any Integration Partner
• Which SAP releases and services have you integrated, and can we speak to that team?
• How do you handle principal propagation versus technical users?
• How are write retries made idempotent?
• Where are logs stored, and can our SAP security team review them?
How We Evaluated This Guidance
We reviewed current vendor and standards documentation listed under Sources, read on October 31, 2026, and compared it with the pages ranking for this topic. We did not run benchmarks; figures marked Illustrative example are assumptions, not results.
Limitations
ECC and older releases may lack the OData services you need, which can require custom services or middleware. SAP licensing and indirect-access terms should be confirmed with your SAP account team; this guide does not assess them.
Agents also inherit data quality. If master data is inconsistent, the agent will repeat those errors faster. See our legacy integration requirements guide for readiness checks.
Our own product (disclosure: LuMay sells this). LuMay's AI integration services page describes connecting AI to ERP and legacy systems through secure APIs, middleware and agents, with RBAC, audit logs and human-in-the-loop controls.
It does not name SAP specifically; confirm SAP experience in a scoping call.
Next Step
Bring one SAP process and its operations list to LuMay's AI integration services team. We will map tools, identities and approval rules before any code is written.
Sources
• SAP Architecture Center: API managed integration with SAP Integration Suite
• AWS for SAP MCP Server user guide
• SAP Community: From OData to MCP with SAP Integration Suite
