Platform
Salesforce on Google Cloud: what the 'one connected AI stack' changes for architects
At Dreamforce 2026, Salesforce and Google went from letting their agents call each other to sharing infrastructure: Hyperforce running on Google Cloud, Gemini inside the Atlas reasoning engine, and Salesforce capabilities exposed to Gemini through MCP. Here is what actually shipped, what is still a date on a slide, and how to decide which engine owns a workflow.
For years the Salesforce and Google Cloud story was a competitive one, two agent platforms circling the same enterprise seat. At Dreamforce 2026 the framing changed. On September 15 the two companies said they would run one connected AI stack: Salesforce running on Google Cloud infrastructure, and agents on either side reasoning over the same data without a custom pipeline between them.
My read: the headline that matters is not another model in the menu. The change is that Salesforce is putting its own platform on Google Cloud while wiring Gemini into the reasoning loop, so the integration tax between the two shrinks.
That change is real for a Google-heavy shop, and it comes wrapped in a set of dates, some shipped, some not, that you need to separate before you plan around them.
What actually shipped, and what is a date on a slide
Three things are generally available today. Gemini models are available for the Atlas reasoning engine that drives Agentforce, so you can run an agent’s planning and classification on Gemini alongside the other models in the menu.
Zero Copy between Data 360 and BigQuery is GA, which was already true for the connector and now sits inside the joint story. And Salesforce capabilities are exposed to Gemini through the Model Context Protocol, so a user inside Gemini can check pipeline health, summarize an account, or triage a case without a bespoke integration.
Two things are still ahead of you. Hyperforce on Google Cloud reaches general availability in North America in November 2026, with Salesforce migrating select US customers in the fourth quarter and phased regional expansion through 2027, Germany included. The Salesforce Federated Connector for Gemini is in private preview, with GA planned for late October 2026. Treat both as roadmap, not as something to design a go-live around this quarter.
The distinction matters because the pieces you can use now are the model choice and the MCP bridge, and those you can pilot immediately. The infrastructure move is real but phased, and it lands on your org through the same Hyperforce migration mechanics that were already coming for you, now with Google Cloud as a destination option.
The bridge runs in both directions
The interesting part is that the connection is bidirectional, and the two directions solve different problems.
Salesforce into Gemini is the direction the Federated Connector and MCP serve. A person who lives in Gemini Enterprise reaches Salesforce data and actions from there, the same headless pattern that powers AIforce. Thousands of Salesforce capabilities are exposed as MCP tools, so the Gemini-side agent discovers and calls them under the running user’s permissions rather than through a hand-built connector.
Gemini into Salesforce is the model direction. Gemini becomes an option for Atlas, which means an Agentforce agent can plan and reason on a Google model while still grounding on your CRM and Data 360. That is the same per-subagent model choice I covered in the model selection guide, now with Google’s frontier models in the list next to the rest.
The partnership does not merge the two platforms. It lets a Salesforce agent borrow a Google model, and a Google agent borrow Salesforce data. You still choose which engine owns the workflow.
Salesforce is also shipping an Agentforce Sales Agent for Gemini Enterprise, in beta on the Google Cloud Marketplace, which is the prebuilt version of the Salesforce-into-Gemini direction for a sales team that runs in Google’s stack.
The decision this forces: which engine owns the workflow
Interoperability sounds like it removes a decision. It does the opposite. Now that a workflow can run on either side, you have to say which side owns it, and the answer has cost, latency, and governance consequences.
Let the Atlas engine own the workflow when the work is CRM-centric and the grounding lives in Salesforce. A service agent resolving cases, a sales agent updating opportunities, anything where the data of record and the actions are in your org. Running that on Atlas keeps the reasoning close to the data and inside the Einstein Trust Layer. You can still point it at a Gemini model if that is the better reasoner.
Let Gemini Enterprise own the workflow when the center of gravity is Google: a task that spans Workspace, BigQuery, and a dozen non-Salesforce systems, where Salesforce is one source among many. There the Gemini-side agent reaches into Salesforce through MCP for the CRM slice it needs and orchestrates the rest itself.
The rule is the one from the buyer comparison: assign the workflow to the platform that owns most of its data and actions, and let the other platform contribute through the bridge. What changed at Dreamforce is that the bridge is now sturdy enough to make “contribute through the bridge” a real option instead of a custom integration project.
Where your workloads run, and why co-location is the quiet win
The Hyperforce-on-Google-Cloud piece is easy to file under “infrastructure, not my problem,” and for most orgs the day-to-day will not change. The place it does matter is data gravity. If your analytical data already lives in BigQuery and your Salesforce runs on Google Cloud, the round trips between them get shorter and the egress math gets friendlier.
Zero-copy federation already meant you were not duplicating the data. Co-locating the compute means the queries that federation fans out to BigQuery are not crossing a cloud boundary to get there. For a heavy Data 360 workload grounded on warehouse data, that is a latency and cost story worth modeling before your Hyperforce window arrives, because the destination cloud is becoming a choice rather than an assignment.
None of this removes your own work. Hyperforce migration still breaks the hardcoded instance URL, the IP allowlist, and the pinned certificate, exactly as the Hyperforce post lays out, and moving to a Google Cloud instance does not change that checklist.
The AWS side, for contrast
Salesforce made the same move with AWS on the same day, and the shape is worth knowing so you do not think Google is the only path. Agentforce Model Choice through Amazon Bedrock is available now, putting Bedrock’s frontier models, including Anthropic and NVIDIA, into the Agentforce menu, with OpenAI models named as coming. Agentforce Voice will interoperate with Amazon Connect through Agent2Agent support in fall 2026, and Data 360 zero-copy extends to more AWS products.
The pattern is consistent across both hyperscalers. Salesforce is making its platform reachable from, and its reasoning engine open to, whichever cloud you already run, rather than asking you to consolidate on one. If you have read the bring-your-own-LLM map, this is that strategy extended from models to infrastructure and agents.
What to do with this now
The infrastructure dates are not yours to act on yet, so do not build a plan around a November GA. What you can do now is pilot the two shipped pieces on a real workflow. Put a Gemini model behind one Agentforce subagent and regression-test it against your existing set, the same way you would test any model change, because swapping the reasoner can change how an agent classifies and plans. Separately, if your users live in Gemini, wire one Salesforce capability into it through MCP under a real user’s permissions and confirm the audit trail.
Keep the governance frame from AIforce in place while you do it. A bridge that lets a Google agent reach your CRM is another front door, and it needs the same least-privilege and identity discipline as any other. The partnership makes the plumbing easier. It does not make your permission model someone else’s job.
Understanding the basics
What did Salesforce and Google Cloud announce at Dreamforce 2026?
An expanded partnership described as one connected AI stack: Salesforce running on Google Cloud infrastructure through Hyperforce, Gemini models available inside the Agentforce Atlas reasoning engine, Salesforce capabilities exposed to Gemini Enterprise through MCP, and continued Zero Copy between Data 360 and BigQuery. It was announced on September 15, 2026.
Is Hyperforce on Google Cloud available now?
Not yet. General availability in North America is scheduled for November 2026, with Salesforce migrating select US customers in the fourth quarter of 2026 and phased regional expansion through 2027. The Salesforce Federated Connector for Gemini is in private preview with GA planned for late October 2026.
Can I run an Agentforce agent on a Gemini model?
Yes. Gemini models are available for the Atlas reasoning engine that powers Agentforce, so you can assign a Gemini model to an agent or a subagent through the same model-selection controls you use for the other models in the menu, while still grounding the agent on your Salesforce and Data 360 data.
Does this replace the Data 360 to BigQuery zero-copy connector?
No. Zero Copy between Data 360 and BigQuery is generally available and is part of the joint story, not superseded by it. The new pieces are the shared infrastructure and the Gemini reasoning and MCP bridges, which sit alongside the existing data federation.
If you run Salesforce on Google Cloud
The two shipped pieces, a Gemini model in Atlas and a Salesforce capability exposed to Gemini through MCP, are worth piloting now under real permissions, before the infrastructure dates arrive. If you want help deciding which engine should own which workflow, or whether co-locating on Google Cloud changes your Data 360 cost model, talk to us, or start with the Agentforce readiness assessment.
