Agentic SAP: Google Cloud + BTP Implementation Lifecycle
65% of S/4HANA migrations overshoot quality targets. Agent networks across Google Cloud and SAP BTP change the Migrate → Design → Run lifecycle.
Introduction
Sixty-five percent of completed S/4HANA migrations still had "severe to very severe" quality deficiencies after go-live (SAPinsider, 2025). That's not a people problem. It's an architecture problem — and adding more consultants doesn't fix it.
In April 2026, SAP and Google Cloud expanded their partnership to deploy multi-agent AI at enterprise scale. Most coverage focused on the marketing use case. But the real story is what this means for implementation: the entire SAP lifecycle — from data migration through system design to live operations — is being rebuilt around autonomous agents.
The model is a three-phase shift: Migrate → Design → Run. Google Cloud provides the intelligence and the data lake. SAP Business Technology Platform (BTP) provides the business process context and governed ERP execution. The implementation partner's new job is to build and manage the communication protocol between them.
Key Takeaways
- 65% of S/4HANA migrations have severe quality deficiencies post-go-live; agent-led validation resolves 90% of data conflicts before a single record touches S/4HANA (SAPinsider, 2025).
- Google Cloud's A2A protocol reached 150 organizations in production by April 2026, enabling agents across SAP BTP and Gemini Enterprise to share context and trigger cross-platform actions (Google Cloud Next 2026, 2026).
- SAP partners are shifting from help-desk support to agentic governance — managing the trust, security, and compliance layer between two clouds.
What Is an Agentic-First SAP Implementation?
Gartner predicts 40% of enterprise applications will include task-specific AI agents by end of 2026, up from less than 5% in 2025 (Gartner, 2025). For SAP, that shift isn't cosmetic. It changes what an "implementation" means — from a time-bound migration project to a continuously operating agent network.
An agentic-first SAP implementation distributes intelligence across two complementary platforms. Google Cloud's Gemini Enterprise Agent Platform (rebranded from Vertex AI at Cloud Next 2026) acts as the reasoning layer: it handles large language model inference, external data analysis, and complex decision-making. SAP BTP acts as the execution layer: it governs ERP access, enforces business rules, and processes transactions inside S/4HANA.
The connective tissue is SAP Business Data Cloud (BDC), which enables bidirectional, zero-copy data access between SAP and Google BigQuery with enterprise-grade security. Agents on both platforms can read the same real-time dataset without physically moving data — eliminating one of the most expensive integration tax points in traditional SAP implementations.
What makes this architecture work at scale is the Agent-to-Agent (A2A) protocol. As of April 2026, 150 organizations — including SAP, Google, Microsoft, Salesforce, and ServiceNow — had A2A in production, routing real tasks between agents built on different platforms (Google Cloud Next 2026, 2026). A Google Cloud reasoning agent doesn't need to know SAP's OData schema. It reads an SAP BTP agent's AgentCard — a small JSON file describing capabilities, endpoints, and authentication — and dispatches tasks via standard API calls.
Our finding: The defining characteristic of the agentic implementation isn't which cloud you're on. It's whether you've designed the contract between your reasoning agents and your execution agents. Organizations that skip that design step find themselves with capable agents that can't hand off work — the same integration bottleneck as before, just renamed.
For a deep dive on how AgentCards work in SAP integrations, see what agent cards are and how they enable agent interoperability.
How Do Agents Automate the S/4HANA Migration?
Only 8% of S/4HANA migrations completed on schedule, with projects averaging 30% longer than planned and 65% exceeding budget (Horváth study of 200 SAP companies, 2025). Data quality accounts for 32% of migration delays and 27% of budget overruns. Those are the numbers that agent-led migration architectures are designed to attack directly.
The pattern replaces the traditional human-led data preparation phase with an agent-led pipeline. Google Cloud becomes the staging environment: legacy data — from SAP and non-SAP sources alike — flows into BigQuery and the Cortex Framework. Gemini agents crawl legacy documentation and Z-code to define business intent, then map source fields to target structures. SAP Business Data Cloud agents manage the target semantic layer on the SAP side.
The GC–BTP Validation Handshake
The architectural insight here isn't just speed — it's the handshake. Before a single record is loaded into the target S/4HANA environment, Google Cloud migration agents and SAP BTP agents run a joint validation pass. The GC agent checks data completeness and structural mapping against the BigQuery/Cortex model; the BTP agent checks functional compliance — whether the mapped data will actually satisfy S/4HANA's business rules for the target configuration.
This cross-cloud validation is what enables the "Zero-Error Migration" service guarantee that forward-looking partners are now offering. Agents resolve data conflicts autonomously — deduplication, missing attribute inference, key field reconciliation — before any human needs to review. The 54% reduction in total cost of ownership for data analytics through SAP BDC + BigQuery zero-copy integration (Google Cloud, 2026) is partly a reflection of this — less manual data prep, fewer post-go-live corrections.
According to a 2026 Syniti analysis, data quality issues account for 32% of migration delays and 27% of budget overruns across SAP projects (Syniti, 2026). An agent-led pipeline that addresses these before cutover converts what was a reactive cleanup problem into a pre-emptive quality gate.
For a technical walkthrough of how SAP OData calls work within an agent pipeline, see wiring an agent to S/4HANA via OData.
What Does "Clean Core" Mean in an Agentic Architecture?
Clean Core in 2026 means more than keeping S/4HANA free of custom code. It means distributing intelligence across clouds. The reasoning-heavy work — LLM inference, external signal analysis, complex decision logic — moves to Google Cloud's Gemini Enterprise Agent Platform. The governed execution work — posting transactions, enforcing business rules, updating master data — stays on SAP BTP, close to the ERP core.
This reframes Clean Core from a constraint ("don't customize S/4HANA") into an architectural pattern ("put your smarts where they belong, and connect them with contracts"). S/4HANA remains upgrade-safe because neither cloud-hosted agent modifies its core. The complexity lives outside, and the A2A protocol defines the only interface.
Agent Roles in the Hybrid Architecture
The practical split looks like this:
Google Cloud Logic Agent — runs on Gemini Enterprise Agent Platform (formerly Vertex AI). It reads external signals: supplier disruptions from news APIs, weather events affecting logistics, social sentiment shifts. It maintains no persistent state in SAP. Its job is to reason over the outside world and decide when something warrants an ERP response.
SAP BTP Execution Agent — runs inside the BTP boundary. It holds the SAP session, understands the process context (current plant capacity, open purchase orders, committed stock), and knows which S/4HANA transactions are safe to execute. It doesn't know or care about external signals. It responds to requests from the GC Logic Agent via A2A.
The A2A protocol is what lets these two agents communicate without tight coupling. The GC Logic Agent reads the BTP Execution Agent's AgentCard, discovers the check_inventory and adjust_production_schedule skills, and dispatches tasks via secure API calls. The BTP agent enforces its own authorization rules — the caller never gains privileges it wasn't explicitly granted. This is the technical definition of Clean Core in an agentic world.
For a worked example of cross-platform agent delegation in this architecture, see when your orchestrator calls SAP's agent: patterns and pitfalls.
How Does the Autonomous Enterprise Operate After Go-Live?
Industry research suggests up to 80% of routine enterprise tasks can be automated through agentic systems (Prolifics, 2026). After go-live on a well-designed Google Cloud + SAP BTP stack, that number stops being a target and starts being an operating baseline.
The architecture shifts from project mode to continuous operation. S/4HANA runs on Google Cloud infrastructure — ultra-low latency between the ERP core and the surrounding agent fleet. That physical proximity matters: a corrective action triggered by an external signal doesn't queue across a WAN connection; it executes in the same network fabric.
The Joule–Gemini Communication Loop
The operational loop works like this: Google Cloud agents monitor the external world — shipping delays, weather events, supplier news, commodity price movements. When an agent detects a signal that crosses a configured threshold, it doesn't just send an alert. It contacts the SAP BTP/Joule agent fleet via A2A to check whether the signal's operational implications are already handled.
The Joule Agent Gateway is the inbound checkpoint for this interaction. External agents — whether from Google Cloud's Gemini, Microsoft's Copilot Studio, or AWS Bedrock — call the Gateway to access Joule's capabilities inside SAP. The MCP (Model Context Protocol) governs internal routing within SAP's own agent stack; A2A governs the external interface. The two protocols don't conflict — they operate at different layers of the architecture.
According to a SAP-confirmed pattern, Joule acts as the engagement layer within SAP applications: it executes tasks, orchestrates workflows, and optimizes outcomes in response to inputs from external orchestrators (SAP News, 2026). What's significant is that Joule doesn't need to understand where the signal came from. It only needs to understand what action is being requested and whether the caller is authorized to request it.
Our finding: The MCP vs. A2A distinction matters more than most architectural diagrams show. Using A2A where MCP belongs (inside SAP's own agent stack) adds unnecessary overhead and breaks SAP's internal authorization model. Using MCP where A2A belongs (at the external cloud boundary) leaves you without the discovery and capability-advertising mechanism the external agent needs. Map the protocol to the boundary, not to the capability.
For a technical grounding in A2A and how it enables the Vertex/Gemini side to call into SAP agents, see building your first A2A-native agent on Vertex AI.
What Role Do SAP Partners Play in the Agentic Ecosystem?
SAP implementation partners in 2025 supported go-lives. SAP implementation partners in 2026 own the trust layer between two clouds. That's a different job description.
The traditional post-go-live model — reactive help-desk support, patch management, user training — doesn't disappear. But it no longer represents the core value. Partners who position their service around "Agentic Governance" are managing something more fundamental: the security, compliance, and continuous optimization of an agent fleet that makes real-time ERP decisions.
The RISE with SAP framework anchors this model — its 99.95% SLA uptime guarantee (Google Cloud, 2026) provides the infrastructure baseline. Partners build their governance layer on top: defining which agents are authorized to trigger which S/4HANA transactions, monitoring agent decision chains for compliance, and maintaining rollback capability when an autonomous action needs to be reversed.
Three Partner Capabilities to Build in 2026
A2A Protocol Expertise. Partners need fluency in Agent-to-Agent protocol design — how to write AgentCards, how to scope skills to the minimum necessary capability, and how to test agent-to-agent interactions in a staging environment before pushing to production. This is the new "integration consulting" skillset.
Hybrid Architecture Design Patterns. The GC reasoning / BTP execution split described above isn't a product you buy — it's a design you create. Partners who've built reference architectures for this pattern will have a significant head start over those who are learning it on a customer engagement.
Agent Governance Frameworks. This is the highest-value capability. It covers auditability (who authorized what action, when, against which data), rollback procedures for autonomous actions that produce unintended results, and continuous optimization of agent fleet performance over time. Partners who can offer this as a managed service own the post-go-live relationship permanently.
What Are the Security and Governance Considerations?
When two cloud providers share agent authority over real-time ERP decisions, governance isn't a project phase — it's the architecture.
78% of brands say AI will be integral to their customer retention efforts, but only 46% can connect their data in a way that's accessible to power AI sustainably (SAP/Google research, 2026). That gap — between AI ambition and data readiness — is exactly where most agentic SAP implementations will stall if governance isn't designed in from day one.
The SAP Sovereign on Google Cloud offering addresses data residency requirements for enterprises operating under GDPR, DSGVO, and equivalent frameworks — ensuring that SAP data processed by Google Cloud agents stays within defined geographic and jurisdictional boundaries. SAP BDC Connect's zero-copy architecture adds a second layer: data never physically moves between platforms, which significantly reduces the attack surface for data exfiltration.
Our finding: In practice, the riskiest governance gap isn't data movement — it's agent authorization creep. A service account provisioned for "inventory-read" during migration testing quietly retains that scope in production. Agents don't forget permissions. The trust hierarchy — which agents can trigger which actions without human approval, and at what transaction threshold — needs to be an explicit design artifact, not a post-launch audit finding.
The SAP Agent Gateway enforces this trust hierarchy at the protocol boundary. Every inbound agent call — whether from Gemini, Copilot Studio, or Bedrock — passes through the Gateway before reaching Joule or the BTP execution layer. The Gateway validates the caller's identity, checks authorized skills against the AgentCard declaration, and logs the interaction for auditability. What it doesn't do is substitute for the authorization design that must happen at the partner level, before the Gateway is ever configured.
For a detailed treatment of authentication propagation and BTP authorization scoping in multi-agent calls, see when your orchestrator calls SAP's agent: patterns and pitfalls.
Frequently Asked Questions
What is the difference between SAP BTP agents and Google Cloud agents?
Google Cloud agents (on the Gemini Enterprise Agent Platform) handle external reasoning: LLM inference, external data analysis, and complex multi-step decisions that require world knowledge. SAP BTP agents handle transactional process execution: posting documents, checking availability, enforcing business rules, and accessing S/4HANA with governed credentials. The two types don't overlap — they're designed to be complementary.
How does the A2A protocol work with SAP and Google Cloud?
A2A is SAP's preferred protocol for external agent communication. By April 2026, 150 organizations had A2A in production, routing real tasks between agents on different platforms (Google Cloud Next 2026, 2026). A GC agent reads a BTP agent's AgentCard, discovers available skills, and dispatches tasks via standard API calls — no custom integration code, no knowledge of OData or BTP auth required on the calling side.
Is Vertex AI still used with SAP integrations after the Google Cloud rebranding?
Google rebranded Vertex AI to the Gemini Enterprise Agent Platform at Cloud Next 2026, consolidating Vertex AI, Agentspace, and Gemini Code Assist into one product. The underlying platform is the same. Existing code using the Vertex AI SDK for SAP ABAP continues to work. The ABAP SDK documentation is now published under the Google Cloud SAP documentation umbrella.
What is SAP Business Data Cloud (BDC) and why does it matter for agentic SAP implementations?
SAP BDC is the unified data foundation that connects SAP and non-SAP sources with Google BigQuery via zero-copy sharing — no data physically moves between platforms. It enables agents on both the Google Cloud and SAP BTP sides to operate on the same real-time dataset while SAP's governance and security controls remain intact. The SAP-announced 54% reduction in analytics TCO is largely attributable to eliminating the data movement layer.
Conclusion
The three-phase model — Migrate, Design, Run — isn't a framework invented for this article. It's the pattern that emerges when you look at what Google Cloud and SAP are actually building together in 2026: a migration factory powered by Gemini agents and BigQuery; a Clean Core architecture where reasoning lives on GC and execution lives on BTP; and an autonomous operational loop where Joule and Gemini agents handle the outside-in signal processing that used to require a monitoring team.
Partners who understand this model have a concrete set of capabilities to build: A2A fluency, hybrid architecture design patterns, and agent governance frameworks that give enterprise customers an auditable, rollback-capable path to autonomous ERP operations.
The agentic enterprise isn't a destination you arrive at. It's an architecture you maintain. And that's the service opportunity for the next decade.
[INTERNAL-LINK: explore the foundational agent concepts → complete guide to agent cards and A2A interoperability]