A vendor shipping a comprehensive-sounding agent control tower is not the same as your enterprise having an answer for agent management. The architects who conflate the two will inherit a control plane by default, along with a definition of the problem shaped by whoever moved fastest in their estate.
ServiceNow's expansion of its AI Control Tower is a substantive piece of work. The announcement covers real ground — thirty new connectors spanning the hyperscalers and the major enterprise applications, an access graph from the Veza acquisition mapping fine-grained permissions across humans, machines, and agents, runtime observability from Traceloop, cost tracking across model providers, and Action Fabric exposing governed workflow execution to external agents through a generally available MCP server. The kill-switch demo is a credible illustration of what a control plane can do when identity, observability, and execution are wired together. None of this is marketing theater. It is a serious contribution to a category that is forming in real time.
The category is what the announcement signals, and the category is bigger than any single announcement will hold.
The Planes Are the Architecture
Agent management is not one concern. It is a set of distinct concerns that fail in distinct ways, and any architect who has run a production agent in anger has already discovered this the hard way. Identity and access — who the agent is, what it can see, what it can do, and how those permissions move when the model or the agent version changes. Runtime observability — what the agent actually did, what it reasoned over, what tools it called, and what it cost to do so. Policy and guardrails — prompt injection defense, output filtering, jurisdictional rules, model-choice constraints. Lifecycle and versioning — how agents get built, evaluated, promoted, and retired, which is closer to MLOps than to workflow. Cost and FinOps — token spend, model routing, budget enforcement, and the attribution that lets anyone tie spend to outcome. Action and workflow governance — the system-of-action question of which enterprise flows an agent is permitted to execute and under what audit conditions. Inter-agent coordination — how agents talk to other agents, what trust they extend, how multi-agent systems are reasoned about. Data access and grounding — what the agent retrieves, from where, with what freshness and lineage guarantees.
That list is not a definitive taxonomy. Other practitioners will draw the lines differently and they will be no more or less right. The point is not the names. The point is that these are different problems. They have different failure modes, different blast radii, different operational owners, and different regulatory exposure. A platform that covers four of them well does not cover the other four by implication. A platform that covers all of them at the level of a vendor announcement does not necessarily cover any of them at the depth a production incident will demand. We do not know, from any announcement, what is under the hood at the level that matters. What we know is that the planes exist and must be considered.
The Magic-Bullet Pattern, Moved Up a Layer
We argued last week, in a piece written for the CFO, that capital requests for agent governance arrive on the desk one platform at a time, each defensible on its own merits, and the financial exposure lives in the gap between them. A request positioned as sufficient on its own is a down payment on a contingent liability the finance organization has not yet priced.
The same pattern is now arriving at the architect's chair, and the failure mode is identical. A comprehensive-sounding control plane invites the conclusion that agent governance has shifted from an architectural problem to a procurement problem. It has not. The vendors moving into this space — ServiceNow visibly today, others inevitably over the next eighteen months — will each frame agent management in the shape of what they already sell. The platform whose strength is the system of record will frame agent management around data and identity. The platform whose strength is the system of action will frame it around workflow and execution. The platform whose strength is productivity and the corporate graph will frame it around user context and connectors. The hyperscalers will frame it around model serving, infrastructure, and the runtime. None of those framings is dishonest. Each is structural. A vendor cannot help defining a new category in the shape of its existing product surface, because that is the surface its engineering organization knows how to build against.
The architect's job is not to wait for one of those framings to win. It is to hold the full shape of agent management as a reference architecture independent of any single vendor's product, and to make consolidation decisions against that reference deliberately. The magic-bullet failure mode at this layer is the assumption that a sufficiently impressive control plane removes the need for that work. It does not. It changes which seams you have to design for, but it does not eliminate the seams, and the seams are where production incidents live.
Passivity Is the Real Lock-In
The lock-in conversation in enterprise software has been the same conversation for fifteen years, and it has trained architects to think about it in terms of data migration, contract terms, and integration debt. Agent management lock-in is a different shape, and it is more consequential than what the SaaS era taught us to expect.
When an agent control plane becomes the place identity is resolved, policy is enforced, runtime is observed, and action is governed across the enterprise, switching costs are no longer measured in data export and re-platforming. They are measured in re-establishing every permission scope, every audit trail, every policy binding, and every workflow handoff across every agent that routes through that plane — including the agents the platform did not build, which it now governs. That is a deeper commitment than any system-of-record decision an enterprise has made, because it touches every other system rather than centralizing one.
The architect who does not make a deliberate call here will still end up with a control plane. It will be chosen by whichever vendor's footprint grew fastest in the agent estate, which is almost always whichever vendor moved first or sold hardest. And along with the platform, the enterprise inherits a definition of agent management shaped by what that platform's product surface naturally covers — and an invisibility around the planes it does not. Those invisible planes do not stop existing. They continue to fail, on their own schedule, in ways the inherited control plane was never designed to detect.
The defense is not picking the right vendor first. We do not know enough yet to pick the right vendor first, and we may never know it in a way that is durable across the next thirty-six months of platform consolidation. The defense is the reference architecture itself — a deliberate position on what agent management means, which planes the enterprise is consolidating, which it is keeping portable, and where the seams between them are designed rather than discovered.
What an Architect or CIO Should Do This Quarter
The first move is to name the planes your organization considers in scope, in your own language, against your own regulatory and operational context. Eight, six, ten — the count matters less than the deliberateness. The artifact this produces is a reference architecture for agent management that exists independently of any vendor's product page.
The second move is to map the agent estate you already have — and the one you are about to have — against that reference. Most organizations will discover that several of the planes are being addressed implicitly by tools and processes that were never designed for agent governance, and that several others are not being addressed at all. The point of this exercise is not to indict the current state. It is to make the seams visible before a vendor announcement makes them invisible.
The third move is to decide, deliberately, which planes are candidates for consolidation onto a major platform — ServiceNow, Salesforce, Microsoft, a hyperscaler, or whatever the relevant set is for your estate — and which planes you are choosing to keep portable. Identity may consolidate well. Observability across vendor-specific tracing creates exactly the forensic blind spot that turns an incident into a regulatory event, and may need to remain independent. Policy and guardrails are likely to be a hybrid for years. None of these answers is universal. All of them deserve to be made on purpose.
The fourth move is to write the design for the seams. Where two planes meet — where identity hands off to action, where observability hands off to policy enforcement, where lifecycle hands off to runtime — there is a contract that has to exist. If it is not designed, it is being assumed, and the assumption is what the next post-mortem will be about.
The CFO question we raised last week was where the financial exposure lives in agent governance spend. It lives in the gaps between platforms that no capital request was written to cover. The architect's question is the same question, asked of design instead of dollars: where is the design that ties the planes together, and who owns it. The vendors who move first will answer that question for you by default, and the answer will be shaped by their product. The architects who do the work first answer it for themselves, and the platforms become tools inside the answer rather than the answer itself.
That distinction is the difference between a control plane and an inheritance.