Agent Portability Is Now a Platform Decision: What the Plugin Standard War Means for Your Infrastructure Choices

The infrastructure risk that most engineering teams are underestimating in agentic deployments is not the model layer and it is not the orchestration framework. It is the distribution and packaging of skills and tools. As the agent plugin ecosystem fragments across competing standards, the integration work your team does today to connect agents to APIs, data sources, and internal systems is quietly becoming a platform commitment. The organisations that recognise this now will have architectural options. Those that do not will spend the next two years rewriting connectors.

Companion piece to our broader work on agent architecture and reusable workflow design. See AI Agent Workflows as Reusable Products for how to structure agent logic for long-term reusability across platforms.

The Skills Layer Is Where Lock-In Actually Happens

Most engineering leaders focus their vendor risk assessment on the model provider or the orchestration runtime. Both are reasonable concerns, but they are also the most portable layers. Swapping an LLM backend or migrating from one orchestration framework to another is painful, but the interface contracts are increasingly well-understood.

The skills and tool layer is different. When an agent needs to call an internal API, query a knowledge base, or trigger a workflow, that capability is encoded as a plugin or tool definition. If that definition is expressed in a platform-specific schema, it cannot move without being rewritten. At scale, across dozens of integrated systems, that rewrite cost becomes a structural barrier to migration.

This is not a theoretical concern. It is the same pattern that created the data pipeline lock-in problem a decade ago, and the resolution took years of standardisation effort before teams could move workloads freely between environments.

What the Agent Plugins Standard Actually Proposes

The emerging Agent Plugins specification attempts to define a vendor-neutral packaging format for agent capabilities. The core idea is that a skill, meaning a discrete capability an agent can invoke, should be describable in a portable manifest that any compliant runtime can interpret. The manifest covers the capability's interface, its authentication requirements, its input and output schemas, and its invocation contract.

This is architecturally significant because it separates the capability definition from the runtime that executes it. A tool built to the standard could, in principle, be registered with an agent running on one cloud platform and reused by an agent running on another without modification.

The practical gap between that principle and current reality is still wide. Compliance is voluntary, runtime implementations vary, and the specification is still being shaped by parties with competing commercial interests.

MCP Server Bundling and the Tradeoffs Engineering Teams Are Not Discussing

The Model Context Protocol has gained adoption as a mechanism for connecting agents to external context sources and tool endpoints. MCP servers act as the runtime layer that exposes tools to agents, and bundling your tool implementations inside a managed MCP server is operationally convenient. It reduces the surface area your team needs to manage directly.

The Bundling Risk

The tradeoff is that when your tool implementations live inside a managed MCP server operated by a platform vendor, your portability depends on that vendor's continued cooperation. If the vendor changes their pricing model, deprecates an API version, or simply acquires a competitor and shifts roadmap priorities, your tool layer moves with their decisions, not yours.

Teams that have built tool implementations as independently deployable services, with MCP server compatibility treated as an interface rather than a hosting dependency, retain the ability to re-register those tools against a different runtime. Teams that have accepted bundled hosting as the default have traded that optionality for convenience.

What Portable Tooling Actually Requires

Portable tool implementations require three things: a schema expressed in a vendor-neutral format, an invocation endpoint your team controls, and authentication that is not coupled to a single platform's identity system. None of these are technically difficult. They require deliberate architectural decisions that are easy to skip when a managed bundle is available and the deadline is close.

Google Cloud's Steering Committee Position and What It Signals

Google Cloud's involvement in the Agent Plugins standardisation process is not purely a technical contribution. Steering committee positions in emerging standards bodies carry significant influence over which design decisions get prioritised, which edge cases get resolved in whose favour, and how quickly competing proposals get absorbed or sidelined.

This is a familiar pattern. The organisations that shape a standard during its formative period tend to produce implementations that align most naturally with the final specification. That alignment is commercially valuable because it reduces the friction for teams adopting the standard through that vendor's tooling.

Engineering leaders should read Google Cloud's steering role as a signal that the Agent Plugins standard is being taken seriously as a market-structuring mechanism, not just a technical convenience. That is a reason to engage with the standard directly rather than waiting for a vendor to package it for you.

How to Make the Portability Decision Before It Makes Itself

The window for making deliberate portability decisions is the period before your tool and skill implementations reach production scale. Once a significant number of integrations are live and downstream teams are depending on them, the cost of schema migration becomes prohibitive in practice even if it remains possible in theory.

The decision framework is straightforward. For each tool or skill your team is building, ask whether the capability definition is expressed in a format that a different runtime could interpret without modification. Ask whether the hosting and invocation path is controlled by your team or delegated to a platform vendor. Ask whether the authentication model would survive a platform migration.

These are not questions that require the Agent Plugins standard to be finalised before you can act on them. They are questions about interface discipline and hosting architecture that good engineering practice already demands. The standard provides a convergence point, but the underlying discipline is independent of which specification wins.