Gemini Agent and Salesforce: Reading Isn't Building

Google’s new Gemini agent lists Salesforce among the systems it can work with, and it can plug into any MCP server you point it at. If you own a Salesforce org, that’s the part of last week’s news to pay attention to. One more “universal” agent will be sitting in front of your CRM by next year, alongside the ones you already have.

My position: this is good news, and it changes less than it looks like it does. A work agent that can read your pipeline, summarize accounts and fill in a few fields is useful. But it isn’t the same as an agent that can safely build things inside your org. The second job needs different plumbing, and nobody’s keynote shipped that plumbing for your Salesforce org last week.

What Google announced

On October 8, Google Cloud CEO Thomas Kurian opened Gemini at Work 2026 by introducing the Gemini agent. Google calls it “your new single, universal agent for work.” The pitch is that you hand it an outcome rather than a set of steps: “You give it objectives, not instructions.” Long jobs keep running after you close your laptop, and the agent can create its own team of sub-agents to split up the work.

The connector list is broad: Workspace, Microsoft Office, Teams, Slack, Confluence, Jira, Git, BigQuery, Snowflake, Databricks, Postgres, ServiceNow and Salesforce. Google also says Gemini can connect to “any Model Context Protocol (MCP) server inside or outside your company network,” and it can read Salesforce Data 360 “without copying data.”

According to Reworked’s coverage, only a small number of companies have access for now. Versions for financial services and legal are in preview, and Google says the agent will come with Gemini Enterprise at no extra charge wherever Gemini Enterprise is sold.

The governance section is the real story

Most launch posts mention safety in one line at the bottom. Google gave it a whole section, and it’s the most useful part of the announcement.

Every agent gets its own identity, “governed like an employee, with least-privilege permissions.” Every action goes into an audit trail “attributed to the agent rather than to a person.” All traffic between agents and other systems passes through an Agent Gateway that Google calls “an AI network firewall.” Spending caps are set per project, and when a cap is hit, that project’s agent pauses until someone clicks to resume it.

That’s the right shape, and it’s the shape we’ve been arguing for on this blog for months: the agent has its own identity and its own record, and a human can step in. If you’ve read our post on the AI agent audit trail, you know why logging actions under the agent’s own name matters. “Who did this?” has to have an answer that isn’t a person’s name the person doesn’t recognize.

Why “it connects to Salesforce” is a smaller claim than it sounds

Look closely at what the connector list promises. Google names Salesforce as a connected platform. It doesn’t describe a CRM development feature, a deployment path or a way to roll back a change. That’s no criticism of Google. A universal work agent is built to use your systems, not to change how they work.

For a Salesforce owner, those are two very different jobs:

• Using the org: answering “which deals slipped this quarter,” drafting a follow-up, updating a stage, pulling a report into a slide. Reading data and making small record edits.
• Building in the org: a new custom object, a trigger that routes leads by your real territory rules, a rollup Salesforce won’t give you, a cleanup across forty thousand records. Changes to metadata and code that every user feels the next morning.

The first job is what Gemini, Copilot and Agentforce are all chasing. The second is what your admin backlog is made of. We covered that split in Agentforce vs. Copilot vs. an AI developer. The Gemini agent puts a third big name in the first column, not in the second.

The Gateway and the audit trail record what the agent did. They don’t give you a Salesforce sandbox to try a deploy in first, a snapshot of the metadata as it was before the change, or a one-step way to put it back. Those have to live closer to the org.

The agent is becoming interchangeable

One line in Kurian’s post deserves more attention than it got: “Gemini is the agent, and the model underneath it is a separate choice.” Google says the agent runs on Gemini models and on Claude models from Anthropic today, with more to come.

Put that next to the past two months. In late August, Salesforce and Anthropic announced Claudeforce. Now Google has a universal agent with Salesforce on its connector list. The front door to your org is turning into a commodity, and your team will likely use more than one of them.

That makes the stable layer the important one. The agent your team prefers might change twice next year. The custom objects, automations and integrations built in your org will still be there. So the question to ask isn’t “which agent wins?” It’s “where do changes to our org get built, tested, recorded and undone, whichever agent asked for them?”

What to do this quarter

If you run a Salesforce org and the Gemini agent (or any of its rivals) is coming your way, here is the practical list.

Split read access from write access on purpose. Give work agents broad read access and narrow write access. Treat metadata and code deploys as a separate permission held by one channel, not something every assistant gets by default. Our post on Salesforce MCP write access goes through why.

Decide where builds happen before someone decides for you. If nobody owns this, the first time a manager asks a work agent to “just add a field for this,” you’ll find out where builds happen the hard way. Pick a path that runs sandbox-first with tests and keeps a record you can read.

Ask every vendor the recovery question. Not “can it break things?” Any capable agent can. Ask “when it does, how fast can we see what changed and put it back?” If the answer is a support ticket, keep looking. That’s the idea behind taking a snapshot before every deploy.

Don’t confuse an MCP connector with a developer. An MCP server that exposes Salesforce to an agent is a pipe. Whether that pipe can safely carry deploys depends on what sits at the other end. We wrote up the difference in Salesforce MCP server vs. an AI developer.

Where Sentinel fits

Sentinel covers the second column: building. It gives an AI that can use MCP (Claude Cowork is the one most of our users start with) a dedicated server that develops against your Salesforce org. Deploys go to a sandbox first with tests required, a snapshot is taken before every deploy, and every change is logged with who made it and when.

To be clear about what that means: Sentinel doesn’t stop an AI from making a bad change, and it isn’t a containment product. It makes every change visible and recoverable, so moving fast doesn’t mean losing track of what happened. It also isn’t affiliated with Google, Salesforce or Anthropic. It’s the layer that stays put while the agents in front of it keep changing.

Pricing is flat per Sentinel and is covered on a short demo call.

The takeaway

Gemini’s agent is a serious product with serious governance, and putting Salesforce on its connector list means more people will be talking to their CRM through an AI by next year. Welcome that. Just don’t mistake an agent that can read your org for a safe way to build in it. Choose your build path now, while a “quick change” is still a choice and not an incident. Last week’s AI agent incident reporting news is a good reminder of why.

Book a Demo Call to see how Sentinel gives your AI a safe, logged way to build in Salesforce.