Why IT Teams Should Connect ServiceNow to Gemini Enterprise

Nobody wakes up wanting to browse a service catalog. They want the VPN fixed, and they will ask whichever window is already open. On October 27, ServiceNow and Google Cloud made the ServiceNow Gemini Enterprise integration for ITSM, ITOM and CMDB generally available to mutual customers, which puts your service desk in that window.

What the ServiceNow Gemini Enterprise integration covers

Per the announcement, helpdesk agents can triage incidents and assess change risk. SREs can investigate alert storms and trace configuration dependencies. Employees get guided self-service. All of it runs from Gemini Enterprise.

ServiceNow Action Fabric is the plumbing. It connects these workflows to Gemini Enterprise "headlessly" through MCP servers (Model Context Protocol, the standard way for AI apps to call tools) and A2A (Agent2Agent, a protocol for agents to hand work to other agents). Headless means ServiceNow still runs the workflow and Gemini only asks for it.

The release gives no endpoints, versions or pricing. It says ServiceNow will publish the connectors as plugins in Google Cloud Marketplace. The telecom integration is not ready and is expected in early 2027.

Three reasons to put IT self-service in chat

People ask where they already are. An IT self-service AI agent in Gemini Enterprise does not replace the catalog. It is a friendlier way to reach it, and ServiceNow stays the system of record.

The context already lives in the CMDB. Triage and change risk are correlation jobs: which service does this configuration item (CI) feed, and what else touched it recently? Today a human collects that from several tabs. Here the agent reads it where the human already works.

Answers turn into actions. ServiceNow's John Aisien put it this way: "Conversational AI is only as useful as the action it drives." A chat that explains the incident and then files, routes or escalates it beats one that only explains it.

The strongest objection: a messy CMDB and a second front door

The fair objection has two halves.

First, an agent reasons confidently over whatever the CMDB holds. If half your CIs are stale or duplicated, you get fast, polished wrong answers. ServiceNow's CMDB Health dashboard scores completeness, correctness and compliance. Correctness covers orphan, stale and duplicate CIs. Look at those scores for the classes you plan to expose before anything else.

Second, permissions. ServiceNow's Action Fabric explainer says ACLs apply at the data layer, and calls that a baseline. Admins also choose which tools are exposed to which clients, and AI Gateway tracks each connection from review to approval. Use that, and keep the first tool list short.

Then there is the second front door. Two intake paths can mean duplicate tickets and routing rules that drift apart. The answer is to have chat create records through the same catalog items and flows, not to build parallel logic in the chat layer.

I would argue this is a reason to pilot narrowly, not to wait. A CMDB that nothing visibly depends on rarely gets cleaned.

Gotchas before you connect ServiceNow MCP and A2A

• Licensing and version: the explainer says you need a Now Assist SKU for the relevant domain (ITSM, ITOM). The MCP Server Console needs Zurich Patch 9 or Australia Patch 2 at minimum.
• A2A is less governed than MCP: the explainer says AI Gateway does not govern A2A traffic in the current GA release. On the Google side, registering an A2A agent was Pre-GA when I checked, supports A2A v0.3, and its traffic does not pass through Agent Gateway.
• Check which path the plugin uses: those docs describe the general mechanisms, not the Marketplace connectors. Ask ServiceNow and Google which one your pilot rides on.
• Both vendors, both contracts: the GA applies to mutual customers, so check licensing on both sides first.

Start with one read-only pilot

1. Pick one read-only workflow, such as incident summaries for helpdesk agents. The explainer says the Quickstart MCP Server ships pre-configured incident and case summarization tools.
2. Check CMDB Health for the classes that workflow touches, and fix the worst offenders.
3. Expose only those tools to a small group of helpdesk agents.
4. Track what you already measure: time to correct assignment group, reassignment rate and duplicate tickets.
5. Add write actions, such as change-risk checks and self-service requests, after the read-only version has earned trust.

The integration is worth wiring up only if you treat it like any other production system, with scoped permissions and data you trust behind it.