We looked at making SAP agent-ready with Joule. But your transactional core is only half the estate - for most consumer brands, the data and the customers live in Google Cloud. This is the agent layer for that half, and why the two need to work as one.

An earlier article looked at making SAP agent-ready with Joule. But for most consumer brands, SAP is only half the estate - the process and transaction core. The other half, the customer data, analytics and commerce, increasingly lives in Google Cloud, and in particular in a data warehouse such as BigQuery.

In April 2026, at Cloud Next, Google consolidated its AI stack into the Gemini Enterprise Agent Platform - the evolution of what was Vertex AI - into a single environment to build, scale, govern and optimise agents. If Joule is the agent layer for your SAP processes, this is the agent layer for your data and your customers.

What it is, in one paragraph

It is a single platform to build agents (a low-code visual studio, and a code-first Agent Development Kit for engineers), to run them (a runtime that supports long-running agents with persistent memory), and - the part that matters most for a data-rich brand - one that is wired directly into BigQuery, where your customer and analytics data most likely already sits. It is also model-agnostic, offering a large library of models: Google's own, and third parties including Anthropic's Claude and open models. As with any fast-moving platform, some capabilities are generally available and some are in preview, so confirm the specifics before you plan around them.

Where it fits for a consumer brand: the data and customer side

The clean way to think about it is by halves. SAP's agents act on your processes - finance, supply chain, orders - which the Joule article covered. Gemini Enterprise's natural home is the other half: the data and the customer.

That shows up concretely. There are data-engineering agents that work directly on BigQuery - one can build a data pipeline from a plain-language request - alongside analytics, customer-service and personalisation agents. For a brand whose edge is understanding and serving its customers, this is where a great deal of the value sits: turning the data warehouse from a place you query into something that acts.

SAP's agents act on your processes. Google's act on your data and your customers. Open protocols make them one estate.

The governance is the shape you already need

Encouragingly, Google has built in the controls we argued for in the article on interfacing AI with your ERP safely. Every agent is given its own cryptographic identity - a granular alternative to shared service accounts - with permissions assignable to specific data, such as a particular BigQuery dataset. An agent registry catalogues every agent, and every MCP server, with its metadata. And an agent gateway, with simulation, evaluation and observability, provides the single control plane that keeps sprawl in check.

In other words, the identity-registry-gateway pattern we described as good practice is now shipped as product. That is a helpful sign of where the whole market is heading, on both platforms.

It speaks the same open protocols as SAP

Here is the point that matters most for a business on both platforms. Gemini Enterprise supports both MCP and A2A - the registry even catalogues MCP servers directly. That is what lets the two halves of your estate work together rather than sit in silos: a Gemini-built data or customer agent and a Joule-built process agent can interoperate through the open protocols.

This is the practical basis for the vendor-neutral position we have held throughout the series. It is not SAP versus Google. It is SAP where it fits, Google where it fits, joined by open standards - and a model choice you make deliberately rather than have made for you.

The catches, with the same honesty as before

The balance is the same as it was for Joule. This is a powerful platform, not a finished solution, and three things are worth saying plainly:

• Value rides on your data. Agents working on BigQuery are only as good as what is in it; the data-readiness precondition applies here as much as anywhere.

• It is new and moving fast. Much of the platform arrived in 2026, with capabilities at different stages of release - confirm what is generally available before committing a roadmap to it.

• It is real engineering. Building and running production agents is a discipline, not a switch, and the breadth of model choice is a decision you own, not a default.

The point: two halves, one estate

The mistake is to treat this as a platform beauty contest. For a consumer brand running both SAP and Google Cloud, it is not a contest at all. SAP and Joule are the agent layer for your transactional processes; Gemini Enterprise is the agent layer for your data and your customers; and open protocols make the two into a single estate. The real work is deciding what belongs where, getting the data ready, and governing both through one control plane.

The bottom line

If your processes run on SAP and your data and customers live in Google Cloud, your agent strategy has two halves - and the advantage is in making them work as one, rather than betting the business on either alone. Mapping which agents belong on which platform, and how they interoperate safely, is where we would start.