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.
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:
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:
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.
From the contract in Part 7:
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`` post_invoice_adjustment and notify_supplier`` approval_id check from 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.
This is the biggest change from the first two builds. The SAP API Policy, published 27 April 2026, says:
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:
Two open points, the same as on the other platforms:
isError is set. The 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.
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.