Versioning AI Agent Changes in the Enterprise
Agents don't arrive through a central procurement process. They spread laterally, opportunistically, often without anyone making a deliberate decision. Employees deploy their own through SaaS tooling. Platforms auto-provision agents as product features, frequently without explicit IT review. MCP server connections get added piecemeal by individual teams chasing a workflow improvement on a Tuesday afternoon. Shadow deployments are already the norm in most enterprise environments; IT frequently has no idea what's running, let alone what version of it.
I've watched this movie before. When data analytics decentralized, every team built its own dashboards and data extracts. Metric definitions diverged. Access policies varied by team rather than by policy. Governance became an expensive retrofit that took years to untangle, and some organizations never fully untangled it. AI agents are following the same arc, but faster and with higher stakes, because these aren't dashboards; they're decision-makers.
What unversioned proliferation looks like in practice: five teams rebuilding the same prompt-based workflow independently, each accumulating their own undocumented iteration history. No canonical record of what each agent is authorized to do. No way to audit which version of an agent was running when a specific decision was made. That last problem becomes acutely real the first time a regulator, a customer, or an executive asks why the agent did what it did on a specific date, and you realize the answer lives in someone's personal Notion doc.
Eighty percent of Fortune 500 companies are deploying active AI agents in production workflows. Only 28% have implemented MCP servers, meaning most production deployments lack even a basic integration standard, let alone versioning infrastructure built on top of it. The gap between "deployed" and "governed" is where version chaos lives, and most enterprises are currently, uncomfortably, occupying that gap.
What MCP Changes About the Versioning Problem, and What It Doesn't Solve on Its Own
Before MCP, every AI-to-tool integration was custom. N applications times M tools meant a sprawling proliferation of bespoke connectors. Boston Consulting Group characterizes this as quadratic integration complexity, and MCP collapses it to linear. Think of MCP the way you think about HTTP for the web: a universal, stateful, bidirectional interface using JSON-RPC 2.0, so any compliant agent can talk to any compliant server without a custom integration for each pair.
Why this matters specifically for versioning: once agents connect to tools via a standard protocol, those connections become trackable units. You can version which MCP server an agent connects to, which version of that server, and which tools that server exposed at a given point in time. Without MCP, the integration surface is too fragmented to version coherently. You cannot govern what you cannot enumerate. That's a constraint, not a philosophy.
MCP's own versioning story is instructive. The protocol uses date-based version identifiers, for instance 2025-06-18, marking the last backwards-incompatible change, and it includes version negotiation so old and new implementations can interoperate during transitions. A forthcoming release candidate introduces a formal deprecation policy: a minimum 12-month window between a feature's formal deprecation and its earliest possible removal. The fact that the protocol's own maintainers felt compelled to codify that is a governance signal worth reading carefully. Even they recognize that enterprises cannot absorb surprise breakage without it metastasizing into something uglier.
What MCP doesn't solve on its own: discovery of what servers are actually running in your environment, ownership attribution, change history, rollback, and scoped access control. Those require a registry layer built on top of the protocol. MCP is the plumbing; the registry is the governance. Conflating the two is a category error that leads organizations to declare victory prematurely.
The Registry as the Versioning Substrate: What It Contains and How It Enforces Change Control
A registry entry is not just a name and a URL. A properly constructed entry contains a unique server name, a semantic version number, a description of what tools the server exposes, an owner, the team or individual responsible for it, access scopes defining who can call which tools, and the remotes or packages configuration needed to run it. Without every one of those fields, you have a directory. With them, you have a governance instrument. The distinction matters enormously when something goes wrong at 2 a.m.
The official MCP Registry launched in preview in September 2025: community-owned, backed by Anthropic, GitHub, Microsoft, and others. It functions as a metaregistry, hosting metadata about servers rather than the binaries themselves. That's the right architecture for a public, community-level resource. Enterprises, however, need private, self-hosted registries layered on top of it for three reasons: internal agents expose proprietary tools and data that cannot live in a public directory; access scoping must be tied to the enterprise's own identity provider, whether that's Entra ID, Okta, Cognito, or something else; and governance over what gets published requires an internal approval layer that a community registry cannot and should not provide.
Kiro's implementation demonstrates what a governed registry looks like in practice. Every client fetches the registry at startup and re-syncs periodically. If a server is no longer in the registry, clients terminate it and block re-addition. If a newer version is specified, clients relaunch automatically with the updated version. The registry is the authoritative source of truth for what version of every server should be running. Not a suggestion, not a default, the source of truth.
AWS released an open-source MCP Gateway and Registry under the Apache 2.0 license in May 2025, and its design is instructive. It routes all agent-to-server connections through a single gateway, which yields three concrete benefits: a simpler network topology, fine-grained access control enforced at tool-invocation time, and a persistent audit trail of who called what with which parameters and when. There's a particularly important detail in how access scopes are enforced: at discovery and listing time, not only at invocation. An agent that has no business seeing a tool never learns it exists. That's the right model, and it's the kind of detail you only appreciate after you've watched the wrong model fail.
Ownership within the registry follows a natural organizational topology. Domain teams own the agents and skills relevant to their function. Platform engineering owns the registry itself, the standards, the certification process, and the access controls. Central IT maintains a list of approved servers for the whole organization; each business unit publishes its own entries within its designated scope. It's the same model software teams use for internal package repositories, and it works for the same reasons.
Audit Trails: What They Need to Capture and Why Change History Alone Isn't Enough
The minimum bar for an audit trail that actually supports governance is higher than most teams initially assume, usually discovered only after an incident. It must capture which version of an agent or server was active at a given time; who made a change and when; what the change was, including prompt, tool, permission scope, and model; and whether it was approved and by whom. Without all four of those elements, "rollback" is a manual archaeology project, not an operational capability.
Change history alone is insufficient because it tells you what happened without telling you whether what happened was authorized. These are different questions. The identity layer is inseparable from the audit layer. Every agent should operate under an isolated service account with scoped permissions. Warehouse-native RBAC, where permissions are granted to roles rather than individuals and the same policies that govern human analysts govern agents, is the right structural model. If a credential is compromised, an isolated service account limits the blast radius. A shared credential does not, and you will be surprised at how many organizations are still running shared credentials in 2025.
What a change event should look like in a governed registry: user identity via enterprise SSO, timestamp, server name, old and new version numbers, which tools were added or removed, and which scopes were affected. That's a parseable, attributable, auditable record. A shared drive of prompt files is not, regardless of how carefully it's organized.
Marco Palladino, CTO of Kong, has articulated the observability problem clearly: enterprises need centralized visibility into tool usage, health, and failures to support monitoring, optimization, cost management, and compliance. Without it, organizations face fragmented integrations and increased operational risk. That framing is technically accurate, but it understates the business reality. Regulators and auditors don't ask "what is your AI policy?" They ask: "Show me who approved this agent's access to customer data and when." A registry with version history and attribution answers that question in seconds. A collection of Slack threads and shared prompt files cannot answer it at all, which creates a specific kind of institutional panic that's entirely avoidable.
Shadow deployments deserve specific attention because they represent the primary audit gap in most enterprise environments today. The first step isn't writing audit policy; it's discovering what's actually running. An AI agent inventory needs to cover OAuth grants, API keys, MCP connections, and non-human identities. You cannot audit what you don't know exists. That sounds obvious, but most organizations skip this step and write policy instead, which is exactly backwards.
Safe Iteration: How Versioning Enables Teams to Update Agents Without Breaking Production
The core tension in agent development is genuine. Agents need to evolve as business context changes: business rules shift, data schemas change, new tools become available, and prior prompt designs reveal failure modes that only appear at scale. But uncontrolled updates in production are precisely how silent regressions happen. An agent that behaved correctly last week, subtly modified by a well-intentioned team member, can degrade in ways that don't surface immediately and are genuinely difficult to diagnose without version history. I've seen this described as a "mystery," as though the agent changed on its own. It didn't. Someone changed it and there was no record.
Safe iteration requires three structural elements. First, pinned versions in production: agents must reference a specific, named version of an MCP server, not "latest." "Latest" is not a version; it's a liability. Second, a staging or shadow environment where new versions can be tested against real traffic before promotion to production, not synthetic test cases, real traffic. Third, a rollback path that is procedural, not manual. If the registry governs which version runs, rolling back is a registry update. It is not an incident response exercise that requires waking someone up.
The two-layer governance model that Snowflake's engineering practice has articulated is worth examining as a structural template. Layer one is domain autonomy: business units design workflows, define business logic, and measure outcomes. Innovation happens at the team level, which is where it should happen. Layer two is centralized standards: a dedicated platform function owns canonical data models, tool registration and certification, risk-tier definitions, and cross-domain policy rules. Central governance doesn't approve every individual agent change; it curates the standards that agents inherit, so domain teams can move with confidence rather than waiting for central approval on each iteration. That distinction, between governing standards and approving changes, is where a lot of organizations get stuck.
Risk-tiering is where this governance model becomes practical rather than theoretical. Not every update carries the same risk, and treating all changes with the same approval overhead is how governance becomes a bottleneck that teams route around, which defeats the purpose entirely. A prompt wording adjustment in a low-stakes summarization agent: low risk, team-level approval. Adding a tool that can write to a CRM or financial system: elevated risk, platform engineering sign-off required. Expanding permission scope across data sources: highest risk, security review required and a registry update with a full audit record. The tier determines the process, not the other way around.
MCP's own deprecation policy offers a replicable model for planned obsolescence. The 12-month minimum window between formal deprecation and earliest removal is a forcing function for traceable migration rather than surprise breakage. Enterprises can apply the same logic to internal agents by publishing deprecation notices in the registry before removing a server version, giving consuming teams time to plan, test, and migrate rather than discovering a broken dependency in production on a Friday afternoon.
The compounding benefit of this discipline is institutional memory. A team that versions its agents accumulates a history of what was tried, what broke, what the rollback was, and what the approved path forward looked like. That history is a governance asset in its own right, and it only exists if the versioning infrastructure exists to capture it.
Reuse as the Downstream Reward for Getting Versioning Right
Without a governed registry, each team that needs a CRM-connected agent builds its own, independently, without shared context, without shared permissions, and without any of the testing and iteration history the first team accumulated. Gartner projects that 40% of enterprise applications will feature task-specific AI agents by end of 2026, up from less than 5% in 2025. At that scale, duplication graduates from a nuisance to a structural drag on AI investment, the kind that shows up in budget reviews and is difficult to explain to leadership.
What a versioned, registered agent enables that an unversioned one does not: a second team can consume a published, versioned skill with confidence that it was tested, approved, and iterable. When the owning team updates the skill, the version bump is visible in the registry. Consumers can choose to adopt the update or pin to the version they've already validated. Permissions inherited from the registry mean the consuming team doesn't need to redefine access from scratch; they receive what their identity and role already authorize. The compliance and security review that the first team completed travels with the versioned artifact, not with each individual deployment. That last point is underappreciated; it's where a significant amount of duplicated effort currently lives.
The fintech sector, where MCP adoption is currently running highest among enterprise verticals, arrived at this discipline earlier than others, not because they were more philosophically inclined toward governance, but because multi-system data requirements forced integration rigor before agents even existed. When your agent needs to touch payments data, trading data, and customer records simultaneously, you develop strong opinions about access scoping and audit trails quickly, out of necessity. Every other regulated enterprise sector is heading toward the same forcing function.
The organizational model that versioning makes possible is cumulative rather than redundant. Platform engineering publishes and maintains certified, versioned agent skills. Domain teams compose them, extend them for local context, and publish domain-specific additions back to the registry. Each contribution makes the next team's work faster and more trustworthy, because the foundation has already been stress-tested. That dynamic only emerges if the registry and versioning infrastructure exist to support it; absent them, each team starts from scratch, and the organization pays for the same work multiple times.
The teams that build versioning infrastructure now are not doing extra work. They are doing the work once, correctly, in a way that scales. The ones deferring it are doing the work repeatedly, incorrectly, in a way that eventually requires an expensive unwind.
