Stories
One capability, many agent surfaces
10 August 2026 by Matt Gibbs
Agent Plugins is a new open, vendor-neutral effort to give reusable agent components a portable package format. Its initial steering group includes maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel.
That work arrives as agent clients are developing their own ways of adding tools.
There are MCP servers, browser tools, Skills, plugins, embedded assistants, app directories and client-specific configuration files. That variety is understandable. Different clients have different jobs and different ways of presenting capabilities to their users.
But it creates a problem for anyone building the tools behind them.
If I describe the same website capability separately for every agent client, I do not really have one capability anymore. I have several copies of it. One copy may accept different inputs. Another may return more information. Another may omit an important limit. Another may accidentally be treated as writable when it was meant to be read-only.
The packaging has started to control the product.
That is exactly what I do not want for Open for Agents.
The website owner's reviewed decision should remain authoritative: what the capability does, what it may read or change, which inputs it accepts, how much it returns, and where approval is required. MCP, WebMCP, plugins and an embedded Assistant should carry that decision to different places. They should not each invent their own version of it.
I recently ran a small experiment to find out whether that distinction works in practice.
The question behind the experiment
Agent Plugins 1.0 is the emerging specification behind that effort. A package can bring together instructions, Skills and MCP tools in a form that a compatible client can discover and install.
Version 1.0.0 is still a working draft. I was not looking for a reason to announce another product or rush a plugin into a marketplace.
I wanted to answer a narrower question:
Could I take one capability that Open for Agents already understands, package it for a new agent surface, and keep its contract intact?
If the answer was yes, it would support a simpler architecture: define and review the capability once, then project it into the formats people choose.
One deliberately small capability
I used a read-only capability called search_documentation.
Its job is straightforward. It accepts a search query and returns a short list of relevant passages from reviewed documentation. It can also accept the identifier of the page the visitor is currently reading, which helps it understand context.
The important part was not the search itself. It was the boundary around it:
- The query is required and cannot exceed 200 characters.
- The current-page identifier is optional and must use the expected format.
- The capability is read-only.
- It returns no more than five results.
- It cannot roam across the web.
- It cannot change anything.
For the experiment, which I ran on 10 August 2026, I used a small fictional documentation set. It was not connected to the live Open for Agents service, a production database, customer information or a model provider. That kept the test focused on interoperability rather than hiding the result behind a much larger system.
I packaged the capability with an Agent Plugins manifest, an MCP configuration, a Skill explaining when to use it, and a small local MCP server.
Then I installed it into an isolated Codex environment.
It worked through the real client path
Codex found the package. It found the Skill. It started the MCP server and discovered the search_documentation tool.
I then called the tool through Codex's own MCP interface. The request returned three relevant results from the fictional documentation set.
That distinction matters. Starting a local server and sending it a request would only show that the server worked. The experiment showed that the package could travel through the client's actual installation, discovery and invocation path.
There was no model call involved. The result did not depend on whether a model chose the right tool or wrote a persuasive answer. It was a direct test of the package and its contract.
The rules survived the journey
The most encouraging result was not that the search returned something. It was that the capability remained the same capability.
Codex saw the same tool name, description and input schema. The 200-character query limit remained in place. The optional page identifier kept its validation rule. The tool remained read-only. The result ceiling remained five.
No additional tools appeared. The package did not gain general web access, production credentials or broader authority.
That may sound unremarkable. It is not.
In an agent system, a small difference in packaging can become a meaningful difference in behaviour. A missing limit can turn a bounded query into an expensive one. A vague description can lead a client to use the wrong tool. A lost read-only classification can change how a client explains or approves an action. A second copy of a schema can quietly fall behind the live product.
Portability is useful only if the policy travels with the capability.
Failure mattered as much as success
I also tried calls that should not work.
An unknown tool name failed. An empty query failed. A query longer than 200 characters failed. Unexpected arguments failed.
I then broke the two layers separately.
A malformed Skill was rejected by the Skill validator, but it did not alter the MCP server's authority. A broken MCP command did not corrupt the Skill itself.
That separation is healthy. A Skill can help a client understand when and how to use a capability, but it should not be able to grant the server new powers. The server still owns the actual contract and authorization boundary.
This is an important design principle for Open for Agents. Instructions can improve how a tool is presented and used. They must not become a back door around the website owner's reviewed decision.
Codex needed only a small adapter
I tested with an early Codex build that supported portable Agent Plugins. This particular installation still needed two small client-specific configuration files to present the package and start its MCP server. The portable package itself remained unchanged.
This showed that the portable package could retain its meaning behind a small Codex-specific adapter. It did not prove that this Codex version could install the package without those client-specific files.
The Codex files changed presentation and installation, not meaning. They did not rename the tool, widen its inputs, relax its limits or grant it new authority.
That is the shape I was hoping to see.
Clients will continue to have different packaging conventions. The important thing is that an adapter stays thin: it should translate the package into the client's expected shape without redefining the capability.
Clean removal is part of portability
Installation is only half of a plugin lifecycle.
After the test, I removed the package. Codex no longer reported it as installed. The MCP registration disappeared. No server process remained. The experiment did not alter my normal Codex configuration, and no package data escaped the isolated test environment.
Agent plugins can start processes, register tools and introduce configuration. Clean removal is part of being portable.
What this proves—and what it does not
The experiment showed that one reviewed Open for Agents capability could be projected into an Agent Plugins 1.0 package and used through Codex without weakening its contract.
It did not prove universal portability.
I did not test VS Code or another independent client. I did not publish the package remotely, sign it, update it between versions or distribute it through a marketplace. I did not connect it to a production Open for Agents tenant. I did not test a package containing dozens of capabilities.
Those are meaningful gaps, and Agent Plugins itself is still developing. The correct conclusion is not "Open for Agents now works everywhere." It is that the architecture held up in one real client: the reviewed capability remained authoritative while a thin adapter handled the packaging.
One catalogue, several ways to use it
This is the larger idea behind Open for Agents.
A website owner should not have to make the same safety and publication decisions again for every agent surface.
The owner should be able to review a capability once:
- This information is public.
- This tool is read-only.
- These are its accepted inputs.
- This is the maximum result.
- This action changes state and requires approval.
- This action must remain human-only.
The Open for Agents architecture is designed to project that reviewed contract into the places where it is useful.
An MCP client may discover it through an MCP server. A compatible browser may receive it through WebMCP. A visitor may use it through the optional site Assistant. An agent client may eventually install it as part of a portable plugin package.
The surface changes. The website owner's decision does not.
That is a better model than rebuilding the capability inside every new agent ecosystem. It reduces duplication, but more importantly, it reduces policy drift.
Why this could become useful
If portable agent packages mature, they could give website owners another way to meet users where they already work. A developer might install a reviewed documentation capability in a coding client. A publisher or merchant might offer limited tools without handing over unrestricted access to the underlying system.
The client would provide the interface. Open for Agents would continue to govern what the website has chosen to expose.
That leaves room for people to use their preferred agent without turning one vendor's packaging convention into permanent website architecture.
The next test
The next step is deliberately small.
I want to run the same immutable package in a second independent client. The package should expose the same tool, schema, limits and read-only classification. The same valid call should work. The same invalid calls should fail. Installation and removal should leave the client clean.
If that works without changing the meaning of the capability, we will have stronger evidence that the projection is genuinely portable rather than merely compatible with one client.
Only after that would it make sense to consider a larger package or a connection to a non-production Open for Agents tenant.
The part worth keeping
Agent formats will keep changing. Website owners should not have to move their source of truth every time that happens.
The useful result from this experiment is simple:
A capability can have one reviewed home and still travel.
That is the direction Open for Agents is pursuing: one governed catalogue projected into the agent surfaces people choose. The packaging can change. The promise should not.