Part 17 · One Agent, Five Platforms

The third platform is different from the first two. MuleSoft and Boomi sit between the agent and the ERP. With SAP, the vendor that owns the system of record also offers to host the tools. So this part asks one question: when the ERP vendor hosts the tools, what changes?

Like Parts 11, 14 and 15, this build is documentation-only. It's based on SAP's own published material as I read it on 5 November 2026: the SAP Architecture Center, the SAP API Policy and SAP's July 2026 Integration Suite update, all linked below. I couldn't confirm product details on the SAP Help Portal for this part, so treat the specifics as "check before you build". The agent, the approvals and the scores come in Part 18.

The nine tools on SAP Integration Suite, with SAP as system of record

What's different about SAP

In the reference architecture from Part 3, the ERP is a system of record at the bottom of the picture. Here, it's also the vendor of the integration layer, the tool host and the agent platform. Three things follow from that:

  1. The tools sit next to the data. Invoices, purchase orders, goods receipts and supplier records all live in SAP S/4HANA. The tools are thin, and most of the logic is already in the ERP.
  2. The vendor sets the rules of access. SAP's API Policy now says how agents may reach SAP systems. More on that below.
  3. The approval can live in the ERP's own workflow. That's Part 18's question.

Where the tools live: MCP Gateway in Integration Suite

SAP's answer for exposing tools is the MCP Gateway in SAP Integration Suite. The July 2026 Integration Suite update describes it as a place to host and manage MCP servers, and lists three ways to create one:

  • from an API artifact,
  • from existing API Management specifications,
  • from RFC and remote-enabled function modules in ECC and S/4HANA.

The same update says the gateway translates technical specifications "into MCP schema with natural-language semantics", and lists security features: rate limiting, IP blocking, OIDC-based authentication and payload protection, plus logs, traces and analytics. The Copilot Studio reference architecture adds that the gateway exposes a Streamable HTTP endpoint.

So the hosting model is close to Boomi's in Part 14: tools are generated from API definitions you already have. The same lesson applies. The Copilot Studio architecture says to write "precise, action-oriented tool descriptions in the gateway", because the agent picks tools by them.

Mapping the nine tools

From the contract in Part 7:

  • Six read tools (get_invoice, get_purchase_order, get_goods_receipt, get_supplier_history, check_duplicate_invoice, run_three_way_match). The data is in S/4HANA. The four plain reads can be thin API artifacts over published S/4HANA APIs, exposed as MCP tools. The duplicate check and the three-way match need rule logic in front of the data.
  • request_approval goes to a workflow. Whether that's SAP's own workflow or an external one is Part 18.
  • post_invoice_adjustment and notify_supplier are the writes. They still need the approval_id check from Part 6.

One design point carries over unchanged: tools sit over process APIs, not system APIs. A raw S/4HANA OData service is a system API. The approval check, the duplicate rule and the three-way match need logic in front of it. On SAP, that means an integration flow or an API artifact with policies in front of the backend. The July update lists "API composition" to combine backend APIs into one MCP endpoint. Composing resources from several API artifacts into one MCP server is on the roadmap.

The rules of access: SAP's API Policy

This is the biggest change from the first two builds. The SAP API Policy, published 27 April 2026, says:

  • "Integration with autonomous AI agents" is restricted to "an endorsed SAP architecture". The endorsed patterns are A2A (through Agent Gateway) and MCP.
  • Third-party AI platforms are allowed if they connect through an endorsed architecture with open protocols.
  • Published APIs are supported for their documented use. Non-published APIs are at the customer's own risk, and undocumented APIs mustn't be used for "agentic access".

The July update lists MCP Gateway as an endorsed path for agents reaching SAP systems, both for third-party agents and for agents built on SAP BTP.

What this means for the invoice agent:

  • Use published S/4HANA APIs only. Before exposing a function module as a tool, check it's released for that use.
  • If the ERP is SAP, the MuleSoft and Boomi builds raise a question. Their tools call SAP through process APIs, which is ordinary integration. The policy deck doesn't say whether an agent reaching SAP through a third-party integration layer counts as "integration with autonomous AI agents". That's worth asking SAP before you build.

Errors and identity

Two open points, the same as on the other platforms:

  • Named errors. Nothing I read says how a backend error from S/4HANA becomes an MCP result, or whether isError is set. The Part 8 errors such as GR_MISSING and PERIOD_CLOSED have to be produced by the process layer either way, because S/4HANA's own error messages aren't the contract.
  • Identity. The third-party MCP access architecture says an MCP server should never pass the caller's token straight to a backend API. It should exchange it for a scoped credential that identifies the agent. The July update lists principal propagation through the gateway as on the roadmap, so check what's available today.

What this sets up for Part 18

SAP's hosting story is strong where the data is: tools next to the system of record, a gateway with security built in, and a clear policy on how agents get in. The trade-off is that the vendor's rules now shape the architecture, not just the integration team's.

Part 18 builds the agent in Joule Studio, looks at approvals in the ERP workflow and A2A through Agent Gateway, and gives SAP its provisional scores.

SAP teams: inside or outside SAP for agent tools?

This series describes a reference build on a fictional company. This part is based only on SAP's published material as of 5 November 2026; no hands-on build has been run yet. Views are my own. Check current docs before you build.