You Rebuilt the Same AI Assistant Three Times. You Only Had to Build It Once.

You did not build an AI assistant last month. You built a hostage. It only lives inside one app, and it forgets you the moment you try to leave.

The tax nobody put on the invoice

Marisol runs a nine-person bookkeeping and tax practice in Austin. Four months ago she paid a contractor $2,400 to build a month-end close assistant inside a custom ChatGPT setup. It reads the general ledger export, flags anything that looks like a duplicate charge or a miscoded expense, and drafts a two-paragraph summary for the partners every Friday. It worked. Her team stopped dreading the last week of the month.

Then her office manager wanted the same helper wired into GitHub Copilot, where the firm's part-time developer already lived. Then a new junior analyst wanted it in Cursor, to pair with the spreadsheet scripts he was writing. Same logic. Same two connections, one to the accounting export, one to the firm's shared drive. Three separate rebuilds, three separate invoices, because the folder structure ChatGPT expected was not the folder structure Copilot expected, which was not what Cursor expected.

Nobody called that a tax. It showed up as "another quick project," three times. That is the real cost of building AI tools inside a single app: not the first build, the second and third one, for work you already paid to have done.

What actually shipped, and why builders are still arguing about it today

On July 24, 2026, a group of AI companies published something almost boring on purpose: the Agent Plugins Specification 1.0.0, a shared, vendor-neutral way to package an AI skill and the external tools it uses into one folder that more than one AI app can read. The specification's Technical Steering Committee started with Amazon, Cursor, Microsoft, OpenAI, and Vercel. On August 6, Google joined as a Core Maintainer, represented by Kevin Hou of Google DeepMind, and said so plainly on its developer blog: "The core problem isn't the components. It's the manifest."

That line is the whole story. The underlying pieces, an AI skill (a written instruction set an agent can follow) and an MCP server (a small connector that lets an agent read or act on an outside tool, your invoicing system, your shared drive, your CRM), were already reusable on their own. What was not reusable was the wrapper. Every app invented its own folder layout and its own configuration shape for the exact same two ingredients, so a plugin built for one client needed a rebuild before a second client could use it.

As of this week, that fight is live. Developers on X have spent the past two days comparing the new format to what npm did for JavaScript packages, one plugin, every agent, and pointing out that OpenAI, Amazon, Microsoft, Cursor, and GitHub agreeing on a shared standard at all is unusual enough to be the actual news. Codex's own August 8 changelog already lists "install portable Agent Plugins" as a shipped feature, three weeks after the spec was published. This is not a slow-moving committee process. It is a standard that a handful of the largest AI vendors on earth adopted inside a month, and the ecosystem is visibly still reacting to it in real time.

Inside the box: what "portable" actually means

Strip away the announcement and an Agent Plugin is just a directory with a predictable shape:

my-plugin/
├── plugin.json (2 required fields: schema + name)
├── skills/ (one sub-folder per skill, each with a SKILL.md)
└── mcp.json (declares the connectors: stdio, HTTP, or legacy SSE)

The manifest, plugin.json, is deliberately thin: a schema reference and a name. Everything else, description, version, license, is optional. Skills live in their own labeled folders exactly as the existing Agent Skills format already defines them. Connectors to outside tools live in one mcp.json, with an explicit transport type on every entry so a client never has to guess how to talk to it.

The part worth sitting with is how the specification handles failure. If one skill in the folder is broken, the client skips it and keeps loading everything else. If a connector cannot authenticate, that connector fails on its own, it does not take down the skills sitting next to it in the same package. One bad wire does not blow the whole fuse box. And when an app needs to do something proprietary, an extra hook, a custom command, it gets its own clearly labeled folder inside the package that other apps simply ignore. The portable core stays small; the app-specific extras stay contained.

Who is actually plugged in today, and who is not

The specification itself does not install anything, it only defines the box. Adoption is what makes it useful, and adoption is already real but incomplete. As of this week, the project's own compatible-clients list names ChatGPT, Codex, Cursor, GitHub Copilot, VS Code, and Kiro as apps that can read a plugin built to the 1.0.0 format.

That last row matters if your team works inside Claude Code, which many small businesses do. Anthropic already ships its own plugin system, its own plugin.json, its own skills/, commands/, agents/, hooks/, and .mcp.json, documented on its own developer docs. It is built from the same underlying ingredients, skills and MCP connectors, but it is Anthropic's own format, and Anthropic is not currently named among the Agent Plugins specification's core maintainers or its listed compatible clients. If a contractor tells you Claude Code plugins are the same portable standard everyone is discussing this week, that is not quite accurate yet. The two systems rhyme. They do not (yet) read each other's packages.

What to actually do about it this week

You do not need to touch a line of code to act on this. You need one question, asked before you sign off on the next invoice.

1. Before you pay for a custom AI assistant, ask how it is packaged. "Is this built with a plugin.json, a skills/ folder, and an mcp.json, following the open Agent Plugins standard, or is it locked into one app's own format?" A contractor who knows the space will have an immediate answer.
2. If the answer is yes, you have bought optionality, not just a feature. The same package should load into any client on the compatible list without a second invoice, today that already covers ChatGPT, Cursor, GitHub Copilot, VS Code, Codex, and Kiro.
3. If your team lives in Claude Code, do not assume portability yet. Ask specifically whether the skill logic (the instructions) can be mirrored there even if the packaging cannot travel automatically. The thinking is reusable even where the wrapper is not.
4. If you already have a working AI assistant, do not rebuild it today. Ask your contractor to repackage it into the open format the next time it needs a change anyway. There is no reason to pay twice.
5. Check back in a quarter. A specification that took under a month to add Google as a maintainer and get real vendors shipping install support is moving faster than most technology standards ever do. The compatible-clients list a few months from now is unlikely to look like the one today.

The actual point

Marisol's firm did not need a smarter AI model. It needed the $2,400 it already spent to keep working after the second and third rebuild. That is the entire promise of a boring packaging standard: not a new capability, just the right to keep the one you already paid for.

Every dollar you spend teaching an AI tool your business, your ledger, your customers, your exceptions, should survive the day you switch tools. For the first time, there is an open, multi-vendor answer for how to make that true. It is early. It is incomplete. It is still worth asking about on your very next AI project.