Kiro powers now support Agent Plugins

You built something good. A skill that encodes how your team actually deploys, plus an MCP server that talks to your internal service. It works. So you package it for the client your team uses, and then you package it again for the client the team next door uses, and again for the one your open source contributors prefer. Same knowledge, same tools, three sets of docs, three packages to keep in sync.

Extension authors have been paying that tax since agents started accepting extensions. Developers pay the other half of it: you find a plugin that does exactly what you need, and it does not load in the tool you are in.

When we introduced Kiro powers, the pitch was that agents should not have to know everything upfront. Bundle an MCP server with the framework expertise for using it correctly, load it only when it is relevant, and your baseline context cost stays minimal.

That model works. The limit was supply, because a power had to be authored for Kiro to run in Kiro.

Today, Kiro powers is rolling out support for Agent Plugins 1.0.0, an open, vendor-neutral specification for packaging agent extensions. AWS is a founding member of the Agent Plugins Technical Steering Committee alongside Cursor, Microsoft, OpenAI, and Vercel. In practice, this means a plugin published to the standard is installable in Kiro as a power.

Agent Plugins is an open, vendor-neutral specification (v1.0) that defines an interoperability floor for the reusable components that extend AI agents. It standardizes how Agent Skills and MCP servers are packaged so any compatible client can discover and load them consistently.

An Agent Plugin is essentially a directory with a manifest and components in fixed locations:

We have watched this pattern play out enough times to recognize it. Before package.json, installing a JavaScript library meant downloading scripts by hand and managing dependencies by copy and paste. Once the format converged, npm, yarn, and pnpm could all install the same package. Before Open Container Initiative (OCI), a container image was a Docker artifact; after it, the same build runs under containerd, Podman, or anything else that complies.

Agent extensions are at that same point. The components are good, and the packaging is where the time goes.

Agent Plugins got there the way the durable standards do. Vercel published the initial draft, then convened a working group of companies that had each been solving the problem privately. AWS, Cursor, Microsoft, OpenAI, and Vercel refined the specification together and set up governance so that no single company's roadmap steers the format. The Technical Steering Committee draws core maintainers from all five, and the contribution process and technical decisions are public. For anyone authoring a power, that is the practical guarantee: as the specification evolves, powers evolve with it, and you are not waiting on a proprietary migration.

Adopting the standard also expands what a power is. Kiro has supported skills for a while, what it did not have was a way to ship them inside a power. Until now, a power was a POWER.md file, optional steering files packaged for a purpose, plus an mcp.json. Agent Plugins brings Agent Skills in as a native component: a power can now carry one or more structured skills under skills/, each with its own SKILL.md, supporting scripts/, and references/.

For developers, this means:

• Expertise that runs, not just reads. A skill can bundle executable scripts and reference material alongside its instructions, and those run as part of the power.
• Composition instead of one long file. Several skills can live in one power, each activating for its own workflow, rather than everything competing for room in a single file.
• A defined home for each concern. Tools live in mcp.json, knowledge lives in skills/, client-specific behavior lives under a namespace. Authoring, reading, and extending a power - all get easier when the structure is a given.

If you install powers, the catalog is no longer bounded by what was built for Kiro:

• A team publishes an Agent Plugin for its internal API. The team’s users install it in Kiro with no Kiro-specific packaging.
• A vendor already maintains a plugin for its service. Kiro users install it without waiting for a port.
• Community-created plugins, wherever they were first published, become candidates for the powers panel.

If you author powers, you write against one documented format with public schemas, and what you ship reaches developers on every compatible client rather than one.

Nothing you have installed breaks, and nothing you have published stops working. Powers built the original way continue to load as they always have. We do recommend migrating to the Agent Plugins layout sooner rather than later, because that is where new capability lands first, and because it is what makes your work portable.

Powers remain the Kiro experience around plugins, and that is the part we are still building on: curation, one-click install from the IDE or kiro.dev, credential prompts on first use, and keyword-driven activation so multiple installed powers cost you virtually nothing in usage until some of them are activated only when needed for a particular task.

The original thesis still holds. Agents get better not by knowing everything upfront, but by loading the right expertise exactly when it is needed. What changes today is where that expertise can come from. The skills and servers the ecosystem is already producing are now powers your agent can pick up, and the collection grows as fast as the standard spreads.

Read the specification at agent-plugins.org, revisit the original powers launch, and open the powers panel to see what is already installable. Then package something of your own and tell us what you built.