The Salesforce and Google Cloud partnership: what it means for your Salesforce estate

On 15 September at Dreamforce 2026, Salesforce and Google Cloud announced an expanded partnership. Salesforce workloads move to Google Cloud through Hyperforce, and Salesforce's headless architecture connects to Gemini Enterprise.

The connection is the part worth reading twice. In Salesforce's own words, it is "built on the Model Context Protocol (MCP) open standard", and that architecture "allows native interoperability between Gemini Enterprise and Salesforce", so that "agents on either platform can reason and act upon the same data without custom integrations".

Two of the largest enterprise software companies did not build a bespoke integration between their AI platforms. They used a published open protocol. That is the news.

#What that changes about MCP

Until now, a reasonable enterprise position on MCP was to watch it. It looked like a developer standard: useful for wiring a model to a tool on a laptop, not yet something to commit an architecture to.

That position is harder to hold when it is the wire between Agentforce and Gemini Enterprise. A protocol two platforms of this size have agreed on is one you can design against and reasonably expect to still exist in three years. It has moved from convention to infrastructure, and the practical difference is that it is now worth building permanent things on.

#The three layers

Read the announcement carefully and it describes a separation Salesforce states plainly: the alliance "aligns the essential layers of enterprise AI: the trusted data, workflows, business logic, and actions of Salesforce, the agentic and reasoning capabilities of Gemini Enterprise, and the everyday interfaces where teams and consumers interact in real-time."

That is three layers, and the important property is that they come apart.

Salesforce has since given the top layer a name. AIforce, announced the same day, is described as "a live interface layer that brings the full power of Salesforce to wherever people and agents work", launching with Claude, Slack and the Lightning interface as its first three surfaces. Gemini Enterprise is one consumer of that layer. It is not the only one, and that is the point.

For most of CRM's history these three were one thing. You bought a platform and got its data model, its logic, its intelligence and its screens as a single unit. What is being described here is a stack where the middle and the top can change without the bottom being rebuilt.

#Why that is good news and a warning at once

The good news is obvious: a model you commit to this year is a smaller decision than it looked. If reasoning is swappable, choosing wrong is recoverable.

The warning is the other side of the same coin. If the model is the cheap layer to change, the context layer is the expensive one, and that is exactly the layer most organisations have neglected. Every hour spent arguing about which model to standardise on is an hour not spent on the thing that will still be costing you in three years: whether a fact has one owner, whether permissions are enforced where data is read, whether anyone can tell a right answer from a plausible one.

An interoperable stack does not rescue a bad data model. It gives more systems more ways to read it.

#The detail most people will skim past

The single most instructive line in the announcement is about Tableau. Salesforce says that "with Tableau MCP, governance, row-level security, and semantic models are enforced with every agent query for consistent, business-grounded insights".

That is the right pattern, and it is worth naming explicitly because it is the thing that usually goes wrong. The permission boundary is being enforced at the protocol, on every query, rather than inside whichever agent happens to be asking. An agent that has to be trusted to respect row-level security is a security model built on hope. An agent that physically cannot see rows it should not see is a security model.

If you take one design principle from this announcement, take that one. Whatever you connect to your data, enforce access at the connection, not in the caller.

#What MCP changes in an integration estate

If you own a Salesforce estate, the question is not whether MCP is interesting. It is what it does to the integration layer you already paid for.

The honest answer is: less than the excitement suggests, and in a useful direction.

MCP is a protocol for exposing tools and context to a model. It is not an integration platform, it does not do transformation, orchestration, error handling, replay or throttling, and it has no opinion about what happens when the downstream system returns a 500 at three in the morning. Everything that made API-led integration hard is still hard.

What changes is the shape of the last mile. Previously, connecting a model to your systems meant building a bespoke tool layer per model and per surface: one for the assistant in the CRM, another for the one in the chat client, a third for whatever the data team was piloting. Each had its own auth, its own schema and its own drift. MCP collapses that into one contract that several consumers can speak.

Read the bottom row twice, because it is where the money is. If adopting a new AI surface stops being an integration project, the cost of trying one collapses, and the strategic value of your context layer rises accordingly. The organisations that benefit are the ones whose data is worth exposing.

#Designing a context layer worth connecting to

This is the work we would actually be doing for you, and it is unglamorous in the way that load-bearing things usually are.

One owner per fact. For every field an agent might read, a named system of record and a named person who can change it. Where two systems disagree, the disagreement is resolved before anything is exposed, not after an agent has confidently reported the wrong figure to a customer.

Objects an agent can reason about. Salesforce data models accumulate. Fields named Status__c, Status_New__c and Current_Status__c all live on the same object, two are dead, and no human is confused because everyone knows which one the report uses. A model has no such institutional memory: it sees three plausible fields and picks one. Deprecating dead fields is now a functional requirement rather than housekeeping.

Descriptions that are worth reading. MCP exposes tools with descriptions, and those descriptions are what a model uses to decide whether to call them. A field labelled "Type" with no help text is a coin toss. This is the cheapest high-leverage work in the whole programme and it is almost always skipped.

Actions with explicit boundaries. An agent that can read is one risk profile. An agent that can write, refund, cancel or escalate is another entirely. Each action wants its own decision about who may invoke it, what it may do, and what the reversal path is when it does the wrong thing at scale.

#Enforce access at the connection, not in the caller

Salesforce's Tableau line is the pattern worth stealing, and it generalises past Tableau.

The instinct most teams have is to give an agent broad access and instruct it to behave: a system prompt that says do not reveal salary data, do not read records outside the user's territory. That is not a control. It is a request, made to something that is optimised to be helpful, and it fails the first time a user phrases the question a way the prompt did not anticipate.

The alternative is to make the boundary structural. The agent runs on behalf of the asking user, the connection enforces the sharing model on every query, and rows the user cannot see are not returned to be filtered later. The agent cannot leak what it never received.

In a Salesforce context that usually means a short, specific list: agents run as the user rather than an integration account, custom code in the path declares with sharing, field-level security is set on the profile rather than assumed from a page layout, and any service account that does hold broad access is not reachable from an agent surface. None of that is new advice. What is new is that it has moved from good practice to load-bearing, because there are now many more ways to ask.

#What we would do in the first ninety days

Not a platform migration, and not a proof of concept.

Weeks one to three, an exposure review. Take the one workflow you would most want an agent in, and trace it: every object it touches, every field, the sharing model on each, and what a reasoning chain running as a typical user could actually reach. This routinely finds one object that has been Public Read/Write since an implementation nobody currently at the company ran. That finding alone usually pays for the review.

Weeks three to six, the context layer. Resolve the facts that disagree, deprecate the dead fields, write the descriptions, and define which actions an agent may take with an explicit reversal path for each.

Weeks six to ten, the evaluation baseline. Build the replay set from closed work, assert on the path as well as the answer, and measure the current process so any later claim of improvement is falsifiable.

Weeks ten to twelve, one narrow agent. A single workflow, a tested refusal set, a named person who can switch it off without approval, and the old path still live and reachable.

At the end of that you have something in production, and more importantly you have a context layer that any of the three reasoning options can be pointed at. If you decide in March that Koa suits one workflow and Gemini another, that is a configuration decision rather than a rebuild.

That is the whole argument for taking the layering seriously: it converts a series of irreversible platform bets into reversible ones.

For what the interface layer itself now looks like, and why it makes your existing permission model load-bearing in a way it has never been, see Salesforce AIforce explained.

#What to do about it

Three things, in order, and none of them are urgent in the way an announcement makes things feel urgent.

Revisit residency decisions. Salesforce states Hyperforce on Google Cloud reaches North America GA in November 2026, with phased regional expansion through 2027 including Germany, and says it is already carrying live production customer traffic. If where data could physically run shaped an architecture choice you made in the last two years, the constraint may have moved.

Write down which layer each of your AI ambitions belongs to. Most stalled AI programmes we pick up are stalled because a context problem was being solved with a reasoning tool. Sorting your backlog into the three layers above tends to make it obvious which items are actually blocked on data work.

Then do the data work. It is the same advice as before the announcement, and the announcement strengthens it rather than weakening it. The layer that is hard to change is the one worth investing in.

#The honest summary

This is a genuinely significant piece of plumbing, and the three-layer separation is the right way to think about what an enterprise AI stack now is. It is also, like every platform announcement, a statement about what becomes possible rather than what becomes easy.

The organisations that get value from an interoperable agent stack next year will be the ones whose context layer was worth connecting to.