It looks like AWS follows them. Both companies lean on the agent extension standard as a claim that matters, because a real migration between clients is the only test that does. A vendor saying "we support the standard" means little on its own. What survives a move, and what quietly breaks, is where that claim gets checked.
On a Friday afternoon, Priya, a platform engineer at a logistics startup, decided to run that check herself. She had been meaning to move one of her team's agent extensions off the vendor's own client and onto a compatible third-party one for weeks. The vendor had published a support matrix, and the third-party client had an integration page that promised "drop-in compatibility." Both felt authoritative. She had half an hour before her last meeting, and she wanted to know if her team's most-used extension, the one that triaged support emails, would come over in one piece.
She exported the extension, imported it into the new client, and watched the first error appear within minutes. A configuration field the vendor's client had populated silently was missing entirely in the new one. The extension loaded, but it was pointed at a storage backend that the new client did not expose, so it fell back to local state. For a few test messages it worked. Then it failed on the first real attachment. The queue backed up. She had two choices: dig into the client's extension API, or roll back and tell her team the migration would have to wait until Monday. The second option was safe. The first option was the one that would cost her the rest of her Friday either way.
She dug in. The session log showed the standard's fields were all declared correctly, which meant the extension was not at fault. The new client simply did not implement one of the optional hooks the vendor's client had always handled behind the scenes. That was the pattern hiding in the compatibility page: nothing on it had been false. It was just incomplete in a way that only a real move would expose.
What she learned maps to a repeatable test that anyone can run in an afternoon, using the same basic steps.
What the standard actually standardizes
The agent extension spec, which AWS's new agent plugins effort also builds on, defines a portable format for describing what an extension does and how it is configured. If a client says it supports the spec, your extension should be recognized, installed, and able to declare its capabilities. That part is the genuine progress: it is an open standard that multiple vendors can implement, and it is a meaningful answer to the fragmentation that has made agent tooling a headache for a while.
But support for the spec is a floor, not a ceiling. Clients have a lot of room underneath the standard itself.
What survived, what broke, what needed rebuilding
Here is what Priya's move actually produced, broken down by category.
What survived: The extension's manifest, its metadata, its declared permissions, and its core logic. The standard handled the structure. That is the part that worked exactly as advertised, and it is worth acknowledging, because it is a real improvement over the days when moving an extension meant reimplementing it.
What broke: Any configuration that depended on the client's internal conventions. The missing storage field was one example. The standard does not mandate how a client stores state, so each client makes its own choice, and your extension has to account for that.
What needed rebuilding: The parts that were never portable to begin with. Priya's extension had a small amount of logic tied to the vendor client's notification system, and a hardcoded path to a cache directory that meant nothing on the new client. Neither violation was flagged at import time. The standard validates structure, not behavior.
The test to run before you trust a compatibility claim
The Friday migration test takes one real extension and moves it between two clients that both claim compatibility. It uses one of your actual extensions, not a toy example. The point is to document, in writing, three columns: what survives, what breaks, and what needs rebuilding.
Run it before you commit to a toolchain change, before you let a vendor's support matrix drive a buying decision, and before you tell your team the new client is "compatible." The test takes an afternoon. The cost of skipping it is discovering the gaps on a Monday morning, with a production workload depending on the move.
The compatibility pages were not lies. They were precisely as informative as a support matrix can be, which is to say not informative enough. Priya's Friday test caught the missing storage field before it became a Monday incident. A vendor's declaration of support is a starting point, and it is the only one you should trust without verifying. Move one real thing, and you will know what the standard actually standardizes.
Comments
No comments yet.