Why AI Capability Management Should Be Model-Agnostic

Enterprise AI infrastructure is not going to converge around a single model, provider, artifact format, or execution environment any time soon. Even within one organization, different teams are likely to make different choices because the underlying workloads are different. A provider that is well suited to software development may not be the obvious choice for research, document analysis, internal automation, or a highly controlled production workflow. Those choices will change as models improve, pricing moves, security requirements develop, new interfaces emerge, and internal AI systems become more capable. None of this is particularly unusual. Technology layers evolve, organizations use more than one implementation, and abstractions that looked permanent eventually become implementation details. The mistake would be to let the reusable knowledge being created on top of today's AI systems become inseparable from whichever provider happened to be there first.

This is the premise behind model-agnostic AI capability management. A capability for reviewing a contract according to company policy is not fundamentally an Anthropic capability, an OpenAI capability, or an internal-model capability. It is an organizational capability that may have one or more provider-specific implementations. The same is true of a workflow for investigating an incident, preparing a customer research brief, evaluating a security finding, or generating code according to an engineering team's standards. The provider matters because it affects how the capability is represented and executed, sometimes substantially. It should not, however, become the canonical identity of the work itself. Once a reusable AI capability begins to encode organizational procedure, judgment, policy, examples, or domain knowledge, the organization needs a durable way to identify and govern it that can survive changes in the underlying execution layer.

This distinction can sound like an argument about portability, but portability is only part of it. The more important question is where the organizational system of record lives. If a provider's object model becomes the canonical representation of a capability, then ownership, provenance, version history, review, approval, access, and eventually usage all tend to become attached to that same provider-specific object. This works reasonably well while one system contains everything. It becomes progressively less coherent as soon as a second provider enters the organization, a team stores the source in GitHub, an internal agent consumes a transformed version, or someone recreates the capability elsewhere. At that point the organization does not merely have several technical copies. It has several partial accounts of what is supposed to be the same asset, each with its own identifiers, history, permissions, and assumptions about authority.

The provider should describe the implementation, not define the asset

There is an obvious temptation when designing a provider-neutral system to invent a universal schema and force every platform into it. I do not think that is the right answer either. Provider differences are real, and many of them are useful. One platform may represent a reusable capability as a directory containing instructions and supporting files. Another may combine persistent instructions with tools, connectors, actions, project context, or agent configuration. Execution controls, metadata, permissions, runtime behavior, model selection, context management, and publishing semantics can all differ. A system that claims portability by discarding everything that is not common to every provider produces a cleaner abstraction at the expense of representing what people are actually using.

A better boundary is to standardize the organizational concepts while preserving the provider-specific implementation. Commonset can know that a capability exists, who owns it, where it originated, which versions exist, what has been reviewed, what has been approved, who can use it, and where it has been distributed without requiring Claude, ChatGPT, an internal system, or some future provider to represent those concepts identically. The provider-specific object can retain its own identifiers, metadata, packaging, and features. An integration layer maps between that implementation and the organizational capability rather than asking one representation to become the other. This is why I think model-agnostic is a more accurate goal than model-independent. The model and provider still matter. In some cases they matter enough that a capability cannot be moved without material changes. What should be independent is the organizational identity and lifecycle of the capability.

That boundary also gives provider adapters a much more precise job. An adapter should understand how a particular platform represents a capability, what information can be imported or exported faithfully, which identifiers need to be retained, what transformations are necessary, and where translation becomes ambiguous or unsafe. If a provider changes its API or introduces a new artifact format, the adapter may need substantial work. The capability's organizational identity should not. Similarly, if a provider adds useful metadata that has no equivalent anywhere else, there is no reason to throw that information away merely because it does not belong in the common model. It can remain attached to the provider-specific implementation. The durable core stays stable while the edge remains free to evolve.

This is a fairly ordinary architectural principle when stated that way: put durable concepts in the durable layer, and put volatile integration details at the boundary. AI makes the principle more important because both the providers and the artifacts are changing unusually quickly. If the organizational data model moves every time a provider introduces a new primitive, the organization has not actually created an abstraction above the provider. It has created a synchronized copy of the provider's current worldview.

Lock-in is not just about whether you can copy the text

When people talk about AI portability, the discussion often collapses into whether instructions can be moved from one system to another. For simple artifacts, the answer may be yes. Copying text is not especially difficult. The harder question is what survives the copy. Suppose a team has spent nine months developing a reusable due-diligence capability. The instructions have changed repeatedly. The current version has a known owner, a repository history, a security review, an approval decision, a limited audience, and several provider-specific distributions. Moving the visible instructions to another system may reproduce much of the behavior, but it does not automatically preserve any of the context the organization relied on when deciding that the original capability could be trusted.

This is where provider coupling becomes a more consequential form of lock-in than file format alone. If the canonical identity is a provider ID, what happens to identity when the capability moves? If version history exists only inside one provider, how does a newly created artifact elsewhere relate to the version that was reviewed? If approval is represented as a property of the provider copy, does that approval follow the capability, disappear during migration, or get incorrectly inherited by a transformed implementation? If an artifact is translated because the target provider uses a different structure, which changes are merely representational and which may affect behavior? If someone subsequently edits the provider copy directly, has a new version of the organizational capability been created or has the distribution drifted away from its source?

These questions expose why a governed capability is more than its current content. Portability has to preserve enough context to explain what moved. At minimum, the organization needs to retain the capability's identity, version relationship, provenance, ownership, governance history, and the mapping between an organizational version and its provider-specific implementations. In some cases it should also record the transformation applied during distribution because a provider cannot consume the canonical source directly. That does not mean an approval on one representation automatically validates every transformed copy. Quite the opposite. If a transformation or runtime difference is material, the system should be able to say that clearly and require whatever additional review the organization considers appropriate. The point of preserving context is to avoid making trust claims that the evidence does not support.

There will also be capabilities that simply are not portable in any meaningful sense. A workflow may depend on a provider-specific tool API, permission model, runtime, context feature, or execution primitive with no equivalent elsewhere. That does not invalidate the model-agnostic approach. It demonstrates why the organizational capability and its implementations need to be distinct. The organization can still know what the capability is, why it exists, who owns it, which implementation is approved, and why another target cannot currently support it. A provider-neutral system should be able to distinguish between a direct translation, an adapted implementation, and a capability whose behavior cannot presently be reproduced in the target environment. Hiding those differences behind a universal abstraction would create the appearance of portability while discarding information that matters.

The useful goal is therefore not to promise that every capability can execute identically everywhere. Models behave differently. Providers expose different functionality. Even the same instructions can produce different operational results when the surrounding tools, context, permissions, or execution environment change. The goal is to make those differences explicit while preserving the organizational lineage around them. Portability is valuable partly because it makes movement possible, but it is equally valuable because it gives the organization a coherent way to describe where movement stops.

Governance is the stronger reason to sit above provider boundaries

The case for a provider-neutral layer becomes stronger when you stop looking at it primarily as a migration system and start looking at it as a governance system. Most of the questions an organization eventually needs to answer about reusable AI capabilities are not model questions. Who owns this? Where did it come from? What changed? Which revision was reviewed? Which revision is approved? Who can use it? Has it been deprecated? Where is it available? Are the copies in two different systems actually the same revision? These are organizational facts. A provider may contain evidence relevant to answering some of them, but no single provider can become the authoritative source for the organization once capabilities exist in more than one place.

Provider-native registries are therefore necessarily partial views. Claude can describe the objects Claude knows about. OpenAI can describe the objects inside its environment. GitHub can tell you what exists in a repository. An internal AI platform may have yet another view. Each can be completely accurate within its own boundary and still leave the organization without a complete answer to a basic question such as "what reusable AI capabilities do we actually have?" The fragmentation becomes more pronounced when an organizational capability has several implementations, when the source lives somewhere other than the execution target, or when different versions have been distributed to different environments.

A control plane above those boundaries can represent the relationships that none of the individual systems can see. The capability can have an organizational identity. Versions can describe changes to that capability. Provenance can record where a version came from and how it relates to earlier material. Review and approval can apply to a specific version rather than to a mutable provider object. Distribution can describe where that version has actually been made available. Provider identifiers remain useful, but as mappings to the organizational asset rather than as the asset's only identity. This does not replace the controls inside each provider. It gives the organization a layer where those provider-specific facts can be understood in relation to one another.

That distinction also reduces a subtle governance failure that becomes more likely as AI adoption broadens. If every provider carries its own independent lifecycle, organizations will tend to review the same conceptual capability several times without necessarily recognizing that the reviews concern related implementations. Conversely, they may assume that a review performed in one environment applies elsewhere even when the execution context has materially changed. Neither outcome is especially desirable. A shared capability model creates a place to preserve the common history while still allowing provider-specific review where provider-specific risk justifies it. Governance can then be reused when the evidence is actually reusable and repeated when the environment introduces something meaningfully new.

Model choice should remain an execution decision

There is a strategic consequence to this architecture that is easy to underestimate. If reusable organizational knowledge has its own identity and lifecycle, model selection can remain closer to what it should be: an execution decision. One workload may perform best with one provider. Another may require a particular security boundary or tool environment. A third may eventually move to an internal system. The capability layer does not need to predict which model provider will be dominant three years from now, and an organization does not need to make that prediction every time it invests in a reusable workflow.

This is more useful than provider independence as an abstract objective. Organizations should take advantage of provider-specific features when those features are valuable. Refusing to do so in the name of theoretical portability would impose its own cost. The architectural requirement is narrower: using a provider-specific feature should not require surrendering the organizational identity of the capability to that provider. If a capability only works in one environment today, Commonset should be able to represent that fact. If another implementation is added later, it should be possible to relate the two. If the original provider is eventually replaced, the capability's history should not have to begin again.

That preserves something more important than the ability to switch vendors cheaply. It preserves continuity. Organizations will spend increasing amounts of time encoding procedures, policies, examples, technical judgment, security controls, and domain knowledge into reusable AI capabilities. The aggregate value of those assets may become considerably larger than the value of any particular model integration. Treating them as disposable provider configuration is increasingly hard to justify once they begin to represent how the organization actually works.

The durable layer should therefore remain organizational. Capability identity, ownership, version lineage, provenance, review history, access decisions, and distribution state need a stable home above individual execution environments. Provider-specific implementations can change as the underlying platforms change, and in some cases they will need to change substantially. That is acceptable. The abstraction is doing its job if change at the provider boundary does not require the organization to forget what the capability was, who was responsible for it, how it evolved, or why a particular version was trusted.

That is what we mean by model-agnostic AI capability management. It is not an argument that models are interchangeable, that provider differences should be erased, or that every capability should run everywhere. It is an argument about where the organization's durable state belongs. Models and providers are execution choices. The capabilities an organization develops on top of them increasingly represent organizational assets. Those assets need a lifecycle that can outlast the infrastructure underneath them.

Commonset is being built around that separation.