ServiceNow in the Age of Agentic AI: AI Control Tower, AI Agent Fabric, and the New Moat of Governed Execution

For more than two decades, enterprise software has been sold by the seat. How many people log in. How many modules they adopt. How many seats you grow into next year. The value of a SaaS platform tracked, more or less, the number of humans touching it.

Agents break that. An agent can query data, summarize it, open a ticket, call an API, talk to another agent, finish a workflow. No login. No screen. No click. So the fear is reasonable. If the human stops touching the interface, the per-seat model starts to leak.

I think that fear is real but incomplete. An agent does not work in a vacuum. To do anything useful inside a big company it needs context, identity, permissions, business rules, secure access to data, an audit trail, and someone to govern and pay for it.

And here is the part I keep coming back to. Almost none of that comes from the model. Most of it lives in the platforms the agents are supposed to replace.

ServiceNow sits right on top of that tension. AI Control Tower and AI Agent Fabric are its two bets here. One is the plane where you inventory, govern and price agents. The other is the fabric where internal and external agents talk to each other.

I am not sure they will pull it off. But I think the bear case — SaaS is dead, ServiceNow with it — is too simple. The rest of this piece is me trying to explain why.

AI adoption in big companies is almost never tidy. Different teams buy different tools. They wire in external models, stand up their own copilots, build local automations, plug in third-party agents. Usually with no shared governance.

People have started calling this Shadow AI. It is AI in use inside the company that nobody has inventoried, approved, or monitored.

The risk is not just technical. It is operational, financial, regulatory, and reputational at the same time. A company can quietly lose track of what data is going to external models, which prompts carry sensitive information, which agents are touching critical systems, and what all of it costs in tokens and runs.

In a Fortune 500 that is hard to call acceptable. And agents make it worse, because they do not stop at text. They execute. A badly governed agent can open, change or close records, read sensitive data, trigger flows, push information to third parties — and do it with no clear chain of responsibility behind it.

So the real question is not whether a company will use agents from OpenAI, Anthropic, Microsoft, Google, AWS or ServiceNow. It will. The question is how those interactions get inventoried, authorized, observed, audited and billed. That is the gap AI Control Tower is aiming at: turning a fragmented pile of AI into a governed system of assets, risks, consumption and measurable value.

The way I think about ServiceNow's agentic architecture is three layers. A foundation/data layer. A governance/control layer. An orchestration layer. The split is useful because it separates the data that gives context, the machinery that governs risk, and the protocols that let agents execute.

The bottom layer is context — the operational ground the agents stand on. In ServiceNow it rests on the CMDB, the AI Asset Inventory, the discovery and inventory data model, the Knowledge Graph, the AI assets themselves, and the multi-instance framework. The CMDB is the structured record of assets and their relationships. In the AI context it stretches to cover AI systems, models, prompts, datasets, agents and MCP servers, so AI assets become governable entities and not loose tools. The Knowledge Graph adds the semantic layer that makes context navigable for an agent: users, roles, the assets they own, prior incidents, affected services, technical dependencies.

The middle layer decides who can use which AI asset, under what conditions, with what risk, through which controls, and measured against what value. This is where AI Control Tower lives, along with AI Asset Lifecycle Management, AI Risk and Compliance, the AI Steward role, audit, runtime monitoring, consumption and ROI dashboards. AI Control Tower is the hub for strategy, governance and analytics. It inventories assets, manages their lifecycle, scores risk, maps compliance and measures outcomes.

The top layer is where agents actually act, with each other and with outside systems: AI Agent Fabric, AI Agent Studio, MCP client and server, A2A, Agent Cards, external agents and the AI Gateway. AI Agent Fabric is the communication and coordination layer.

The AI Gateway is the part I would underline. It is the transactional control point. In a well-governed design, calls do not run straight from agents into critical systems. They pass through identity, permissions, observability, audit, and the option to block.

An enterprise agent is only as good as its context. A generic agent can write, classify and summarize. But to run a critical process it has to know who is asking, what they are allowed to do, which assets they own, which service is affected, what incidents already exist, which dependencies are in play, and which business rules apply.

This is where a real part of ServiceNow's moat shows up. The advantage is not the best foundation model — they are not in that business. The advantage is sitting next to the system of record and the system of action. The CMDB, the ITSM, CSM and HR workflows, years of business rules, incident history, service catalogs and approvals. Together that is a context that is genuinely hard to rebuild from outside.

And this moat is operational, not theoretical. A large company does not casually migrate years of customizations, tables, rules, integrations and critical flows into a purely external agent stack. You can connect external agents over APIs or MCP, sure. But keeping security, traceability, permissions, workflows and compliance intact through that move is expensive enough to create real switching costs.

So even when the user is sitting in Microsoft Copilot, Slack, Teams or some external agent, the execution of the critical process can keep running on ServiceNow as the governed backend.

Open protocols play an ambiguous role in this thesis. On one hand they cut technical lock-in, because they make interoperability easy. On the other, they raise the need for a governance plane — precisely because they make it easy for external agents to reach corporate systems.

MCP, the Model Context Protocol, is client-server. It lets an AI application, an agent or an LLM reach tools, APIs, databases or context sources exposed by an MCP server. What I find interesting is that ServiceNow can sit on either side. A client when an internal agent consumes external tools. A server when it exposes its own capabilities to third-party agents.

A2A, Agent-to-Agent, is more about collaboration between agents than about exposing tools. Agents trading tasks, negotiating capabilities, delegating subtasks. The Agent Card is the key unit there: a structured card describing what an agent can do, at what endpoint, with what capabilities.

Put together, MCP and A2A are not just connectors. They are the communication infrastructure a distributed digital workforce would be built on. And the strategic question is not whether they exist. They will. The question is who controls that interoperability, who decides which agents are trustworthy, and who records every interaction.

MCP gives you a way to structure the relationship between clients and tool servers. Outbound, a ServiceNow agent uses an MCP client to call an external tool. Inbound, an external agent calls ServiceNow capabilities through an MCP server.

The inbound case is the one I would watch. It turns ServiceNow into a system of action that outside agents can consume. Concretely: an external AI application — Microsoft Copilot, Claude, whatever — asks for context or execution through the AI Gateway. The request enters ServiceNow, passes authentication and routing, reaches the MCP Server Console, and finally touches internal workflows or data.

That shape lets ServiceNow keep a strategic role even when the visible interface belongs to someone else. If the user is interacting from an external surface but the secure execution, the structured data and the enterprise workflows live in ServiceNow, the platform still captures value as the system of action.

Here is the defensible version of the thesis. ServiceNow is trying to be the control point for agents that need to execute actions across regulated enterprise processes. Microsoft, Google, AWS, Anthropic or OpenAI may own part of the interface or the model. ServiceNow can still own the governed execution inside the workflow.

The most pessimistic version of the market story assumes that if agents reduce SaaS interface usage, they also reduce the platforms' value. In some cases that is plausible. What it underweights is the shift toward consumption-based pricing.

ServiceNow does not have to abandon per-seat licensing. It looks more like it is complementing it. Consumption units tied to assists, actions, executions, tool calls, usage logs and value measurement. That matters because it lets the company capture value even when the interaction never starts in the traditional interface.

This is the part where, over the last year, I have changed my mind. I used to read ServiceNow on seat growth. I am now fairly sure that is the wrong metric.

If an external agent invokes a ServiceNow capability, if a flow runs in the background, if a tool is called over MCP, if an agent finishes a task with no human in the loop — value stops being measured purely by connected users. It starts being measured by automation volume, AI consumption, time saved, execution success, captured productivity.

Usage logs, assist-consumption dashboards, token metering and execution metrics give you the plumbing to see AI as both a cost and a source of value. Agentic AI may pressure seat-based models. But it also opens a new monetization axis built on governed execution. If I had to pick the metric that matters in three years, I would take executions per quarter over seats per year. I could be wrong about that.