Summary: Autonomous AI agents need ERP systems built to be understood and acted on by machines, not just operated by people. This blueprint, first published by Tarento Labs in August 2025, sets out how to make S/4HANA Public Cloud agent-ready through an agentic interface and a Model Context Protocol. In the year since, SAP has moved decisively in the same direction, confirming the thesis rather than overtaking it.

In brief: ERP platforms were designed for a human in the loop, and that assumption breaks down the moment autonomous agents need to initiate transactions, query data, and act on business processes without one. The fix isn't more AI features bolted onto existing screens, it's an API-first, semantically mapped, policy-enforced interface purpose-built for agents. Tarento Labs proposed a three-layer architecture and a Model Context Protocol (MCP) for S/4HANA Public Cloud in August 2025. SAP has since announced extensive MCP support at TechEd 2025, shipped full MCP support in SAP HANA Cloud in early 2026, and partnered with Anthropic to run Claude inside Joule using MCP, exactly the pattern this blueprint anticipated.

In This Article:

• Why human-centric ERP design breaks under autonomous agents
• The five principles of an agent-ready ERP
• The three-layer blueprint: AI, integration, and ERP
• The Model Context Protocol: the contract agents actually need
• Where this stands now, and why the market caught up
• Strategic recommendations, and the risk that has to be managed rather than ignored

Why human-centric ERP design breaks under autonomous agents

S/4HANA, Dynamics 365, and Infor Cloud Suite all share the same foundational assumption: a human is in the loop. Transactional screens, reporting tools, and approval flows are built around a person reading, deciding, and clicking. Where AI has entered these systems so far, it has mostly been piecemeal, predictive analytics here, automated matching there, layered on top of an interface still designed for people.

Autonomous agents need something structurally different. An agent has to initiate transactions, query real-time data, subscribe to events, and adjust workflows dynamically, and it has to do all of that through an interface that lets it understand business meaning precisely, enforce compliance automatically, and produce results a human can audit after the fact. That's not a UI problem you solve with a chatbot skin over existing transactions. It's an architecture problem.

This thesis was shaped in part by recent research arguing that the web, and by extension enterprise software, increasingly needs to be built for agents rather than retrofitted for them after the fact. Our position at Tarento Labs is the same applied to ERP: every enterprise platform eventually needs to be either rebuilt or extended to be agent-friendly, and the sooner that's treated as a design principle rather than an add-on, the cheaper it is to get right.

The five principles of an agent-ready ERP

An ERP that's genuinely ready for autonomous agents rests on five design principles, and skipping any one of them tends to reintroduce the human bottleneck the whole exercise was meant to remove.

• API-first by default. Every business function, from creating a sales order to closing a fiscal period, needs to be accessible through secure, well-documented APIs, not just the functions someone happened to prioritise for integration.
• Event-driven responsiveness. An event backbone such as SAP Event Mesh lets agents react to business changes as they happen, rather than polling for state on a schedule built for human attention spans.
• Semantic accessibility. Technical objects like VBAK or BKPF mean nothing to a reasoning agent. Mapping them to a shared business ontology, "Sales Order," "Financial Document," with defined field types, units, and relationships, is what lets an agent reason about the business rather than just call an endpoint correctly.
• Delegatable, idempotent workflows. Agents need to execute high-level tasks through single endpoints, or orchestrate granular operations when a task genuinely requires it, and every one of those operations has to be idempotent, so a retried action doesn't silently duplicate a transaction.
• Observability and guardrails. Detailed logging, explainable outcomes, configurable autonomy levels, and a simulation environment are what keep autonomous execution safe, transparent, and reversible, rather than a black box that happens to usually get things right.

The three-layer blueprint: AI, integration, and ERP

The architecture that makes these principles operational separates cleanly into three layers.

At the top sits the AI Layer, the agent mesh itself: orchestration agents that break a goal down into steps, task agents that execute specific operations, and compliance agents that check policy adherence before and after execution. The middle Integration Layer hosts the MCP Gateway, which mediates between agents and the ERP, translating intent into API calls, enriching requests with semantic context, and applying execution policy at the point of action rather than after the fact. At the bottom, the ERP Layer is S/4HANA Public Cloud itself, exposing APIs and events while continuing to execute the core business logic it was always responsible for.

The discipline this layering enforces matters as much as the layers themselves: the ERP core stays untouched and stable, the integration layer absorbs all the complexity of translating agent intent into safe action, and the AI layer can evolve, new agents, new orchestration patterns, without either of the layers beneath it needing to change.

S/4HANA Public Cloud already exposes more than 3,000 APIs through SAP API Hub, so the raw connectivity mostly already exists. What's missing is the semantic abstraction layer on top of it, and that's where SAP BTP does the work: SAP Graph can unify cross-application data, SAP CAP can wrap the raw APIs with simplified, high-level endpoints an agent can actually reason about, and a mirrored Q-system gives agents a simulation environment to test workflows without touching production. Access runs through OAuth2 or SAML with fine-grained authorisation, and sensitive operations should always trigger a workflow-based approval rather than executing silently.

The Model Context Protocol: the contract agents actually need

Raw API access isn't enough on its own, agents need a machine-readable contract that tells them what the ERP can actually do. That's the role of the Model Context Protocol: it lists the available actions (create_sales_order), queries (get_gl_balance), and events (on_stock_below_threshold) an agent can use, and attaches to each one its intent, its input and output schema, the authentication scopes it requires, and the validation rules that apply.

The MCP Gateway, hosted on SAP BTP, is what turns those MCP-defined capabilities into real OData or SOAP calls on the way in, and maps ERP events to MCP event subscriptions on the way out. A context store caches frequently used ERP data in a vector database for semantic retrieval, which speeds up agent reasoning meaningfully compared to querying the ERP fresh on every step. Governance runs through SAP Workflow Management, so high-risk actions still require explicit human approval regardless of how confident the agent's reasoning appears.

Where this stands now, and why the market caught up

We published this blueprint in August 2025 as a Tarento Labs research position, at a point when MCP was still an emerging pattern rather than an industry standard. The twelve months since have moved the enterprise ERP market decisively in the direction this paper argued for.

SAP announced extensive MCP support at TechEd 2025, giving AI agents structured access to SAP data across its business applications. SAP HANA Cloud shipped full MCP support in early 2026, giving Joule agents direct access to SAP's database engine rather than routing every query through an intermediate layer. Most notably, SAP and Anthropic announced a partnership integrating Claude into the SAP Business AI Platform and Joule using MCP standards, enabling agents to coordinate across S/4HANA, SuccessFactors, and Ariba without custom integration code for each system. SAP has also confirmed that flows built into SAP Integration Suite can now be converted directly into MCP tools, effectively productising the gateway pattern this blueprint proposed as custom architecture.

None of this makes the blueprint obsolete, if anything, it validates the underlying architecture while shifting the open question from "should we build an MCP layer" to "how do we design our specific business ontology and governance policy on top of the MCP layer SAP now provides natively." That's a better problem to have, and it's still very much an unsolved one for most enterprises running S/4HANA Public Cloud today.

Strategic recommendations, and the risk that has to be managed rather than ignored

Enterprises and system integrators starting this work now should resist the instinct to design for every process at once. Start with three to five high-value scenarios, sales order management, purchase order approval, and vendor invoice posting are a sensible first set, and prove the pattern there before expanding. Keep BTP as the agent-facing layer rather than modifying the ERP core directly, so simulation, caching, and governance can evolve independently of the transactional system underneath them. Build the semantic dictionary from day one rather than retrofitting it once agents are already live, since agents reasoning against SAP-specific technical field names instead of business concepts is where most early agentic ERP pilots quietly go wrong. And treat simulation mode as mandatory before any autonomous execution touches production, not as an optional staging step that gets skipped under deadline pressure.

The classic objection to this kind of architecture is execution risk, an agent acting wrongly inside a live ERP is a materially different failure mode to a chatbot giving a wrong answer. That risk is real, and the right response is containment, not avoidance. Configurable autonomy levels mean an agent can be scoped to advisory-only, approval-required, or fully autonomous per action type, tightened or loosened as trust in a specific workflow builds over time. Idempotent operations mean a retried action doesn't compound the damage of a first mistake. Detailed logging and explainable outcomes mean every agent action is auditable after the fact, the same discipline good compliance teams have always applied to human-executed transactions, just automated. None of this eliminates risk. It's what makes autonomous execution a manageable engineering problem instead of an act of faith.

Conclusion

The shift from human-centric ERP design to agent-ready ERP platforms is one of the defining architectural changes in enterprise technology this decade, and it's arriving faster than most enterprise roadmaps currently account for. By embedding an agentic interface and implementing a Model Context Protocol, organisations can unlock autonomous process execution while keeping compliance intact and workflows orchestrated safely across systems in real time. For S/4HANA Public Cloud customers specifically, this is no longer a speculative research direction, SAP's own platform roadmap has moved to meet it. The strategic pathway is the same one this paper set out in 2025: build the semantic and governance layer now, on top of the MCP foundation SAP is already shipping, rather than waiting for agent-first ERP to become the default and starting from behind.

The architectural pattern set out here, an MCP-based agentic interface layered over BTP, generalises beyond SAP. The same approach applies to any enterprise application platform with a comparable API surface, including Microsoft's Azure-based Dynamics 365 ecosystem and Infor OS, which is why we built it as a reusable blueprint rather than an SAP-specific integration.

If you're evaluating what agent-ready means for your own S/4HANA Public Cloud, Dynamics 365, or Infor Cloud Suite landscape, talk to Tarento's Enterprise Integration and AI team.

This paper was first published by Tarento Labs in August 2025 as original research. It has been updated to reflect SAP's subsequent MCP announcements through mid-2026; the underlying architecture and recommendations are unchanged from the original.