Agent Plugins 1.0 [What It Changes]

TL;DR

• Agent Plugins 1.0 (specification 1.0.0) is an open, vendor-neutral package format so a skill or MCP server pack can be built once and loaded in Kiro, VS Code, Cursor, or any client that implements the spec.

• AWS said on 6 August 2026 it is a founding member of the Technical Steering Committee with Cursor, Microsoft, OpenAI, and Vercel — 5 companies.

• Version 1.0.0 standardizes 2 component types: Agent Skills and MCP servers. Hooks and custom agents are on a later roadmap.

• A 1.0 spec is not proof every IDE already loads every pack. Kiro Powers is rolling onto it; other clients' depth varies.

Agent Plugins 1.0 is a shared folder layout and manifest so an AI-agent extension can be packaged once instead of rewritten for each editor.

A 2-truck HVAC shop does not author MCP servers. Its vendor does. A 10-person agency that paid twice to "install the same Slack skill in Cursor and in VS Code" does. A solo clinic whose IT person maintains a "how we name patients in the EHR" skill should not have to paste that skill into three tools after every hire. Portable packaging is the boring fix. It is not a new model and not a hosted marketplace SLA.

If you already keep procedures next to the workflow in US Tech Automations, Agent Plugins is the disk format those procedures can travel in — a SKILL.md plus an mcp.json, not a rebuild of intake. Same idea as Clio alternatives: pick the system of record, then stop retyping the playbook into every satellite app.

What actually happened

On 6 August 2026, AWS published AWS Supports Agent Plugins. Agent Plugins 1.0.0 is the open-source, vendor-neutral specification. AWS is a founding TSC member with Cursor, Microsoft, OpenAI, and Vercel. Kiro Powers is rolling out native support. The AWS Agent Toolkit is already compatible.

The canonical site is agent-plugins.org. The GitHub repo is agentplugins/agent-plugins-spec. According to that repository, Specification 1.0.0 is the current published release, 1.1.0 is a working draft, and the repo history showed 81 commits at fetch.

According to AWS, version 1.0.0 standardizes the 2 component types with the most adoption today: Agent Skills and MCP servers, with hooks and custom agents on the roadmap.

Agent Plugins 1.0.0 standardizes two portable types: skills and MCP, per that AWS open-source post. Installation UX, permissions, and marketplaces stay outside the spec on purpose.

Vercel released the initial draft; the five-company working group refined it. That governance story is in the same AWS post and on agent-plugins.org, which names Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel.

The same day, AWS's Kiro Crew launch (covered independently in InfoWorld and InfoQ) made the strategy obvious: open the protocols, keep the harness. Agent Plugins is the packaging protocol. MCP is the tool protocol, defined at modelcontextprotocol.io. Agent Skills already have their own format at agentskills.io. Agent Plugins is the envelope that can hold both.

The folder, in plain English

A plugin is a directory:

plugin.json names the plugin and the spec version. skills/ holds Agent Skills (SKILL.md plus optional scripts and references). mcp.json lists stdio, Streamable HTTP, or legacy HTTP+SSE MCP servers. Reverse-domain folders such as com.example.client/ hold client-only extras without breaking the portable core.

According to the Agent Skills spec, a skill name is max 64 characters, description max 1024, compatibility max 500 if present, and the recommended SKILL.md body is under 500 lines so agents can load it.

A skill name is capped at 64 characters, per agentskills.io. That is a format rule, not a quality score.

The spec repo's README shows the smallest plugin: a plugin.json whose $schema points at https://agent-plugins.org/schemas/1.0.0/plugin.schema.json and one skills/greet/SKILL.md. Clients that support skills load that file. How they show it to a human is out of scope.

Who implements what, today

AWS Agent Toolkit bundles official MCP servers, skills, and plugins for Claude Code, Codex, Cursor, and Kiro. The README lists 4 plugins at fetch: aws-core, aws-agents, aws-data-analytics, and aws-agents-for-devsecops. It says the AWS MCP Server covers 300+ AWS services through one endpoint. History showed 218 commits.

Kiro Powers, described in the AWS post and on kiro.dev, now loads plugins that bundle skills and MCP together. Cursor's site at cursor.com is an implementing-client candidate named on the TSC; that is membership, not a measured install-base.

VS Code is named as a target client in the AWS post. GitHub Copilot's June 2026 notes, on the GitHub changelog, are about browser tools and sessions, not a claim that VS Code already loads every Agent Plugin.

Sources: agent-plugins-spec; agentskills.io; MCP spec.

Source: AWS Open Source Blog; agent-plugins.org.

Source: Agent Toolkit for AWS.

According to AWS, the TSC has 5 founding companies and the first version standardizes 2 extension types. Those are the load-bearing integers for this hub.

Five vendors sit on the Agent Plugins TSC, per AWS and agent-plugins.org. Five logos are not five identical implementations.

Why now, limits

The constraint that broke is copy-paste packaging. MCP standardized tools. Skills standardized instructions. Each IDE still wanted its own zip. Agent Plugins is the package.json / OCI move for those two types, using those exact analogies in the AWS post.

Limits: 1.0 does not cover hooks or sub-agents yet. How a client installs, permissions, and UX is explicitly out of spec — so "it loaded in Kiro" does not mean "it loaded in VS Code with the same prompts." The AWS Agent Toolkit plugins for Claude Code, Codex, and Cursor are toolkit packaging, which may predate or parallel 1.0; read the repo rather than assume.

A clinic's "how we handle no-shows" skill can travel as SKILL.md. It still needs a human to say the skill is allowed to touch the EHR. MCP's own spec, at modelcontextprotocol.io, requires consent before tool calls. Portable packaging does not waive that.

If your runbooks already live as steps in a US Tech Automations workflow, export the stable ones as skills and keep the system of record. Do not duplicate policy into five IDEs by hand; that is the failure mode this spec exists to end.

The state of small-business automation is still the filter: a portable skill with no owner is just a faster way to be inconsistent.

USTA analysis

USTA analysis (derived only from cited figures).

Inputs: 5 TSC members; 2 portable types in 1.0; 4 AWS toolkit plugins; 64 / 1024 / 500 character caps; 81 spec-repo commits; 218 toolkit commits; 300+ AWS services on the MCP server.

2 ÷ 5 = 0.40. Two of the five "extension kinds" people talk about (skills, MCP, hooks, sub-agents, custom agents — AWS named the last two as future) are in 1.0 if you take AWS's list of "skills, MCP, hooks, sub-agents" as four named kinds, then 2/4 = 0.50. AWS named skills and MCP as the two with most adoption, and hooks plus custom agents as future: 2 of 4 named kinds = 50% of that list.

64 + 1024 = 1,088 characters of required skill metadata ceiling (name + description).

218 / 81 ≈ 2.69 toolkit commits per spec commit at fetch. Different projects, different ages; the ratio only says the toolkit repo was busier than the spec repo when fetched, not that AWS outvotes the TSC.

Sources for inputs: AWS; agentskills.io; agent-plugins-spec; Agent Toolkit.

Signal vs Speculation

Signal (as of 6 August 2026): Agent Plugins 1.0.0 is published. Five founding TSC members. Two portable types. Kiro Powers rolling on. AWS Agent Toolkit compatible. Spec and schemas are public. 1.1.0 is a draft. MCP and Agent Skills remain separate specs that Plugins wraps.

Our read: Over 12–36 months this becomes the default zip for "install our AWS skill" and "install our Linear MCP," the way package.json became default for JavaScript libraries. SMBs will not read the spec. They will click Install in whatever IDE their contractor uses. The failure mode is a client-specific folder that silently does extra work in one editor. Demand a plugin that works with only plugin.json, skills/, and mcp.json before you trust it on a production repo. If a vendor says "Agent Plugins" but ships only a Cursor-only extra, that is a proprietary pack with a sticker.

Pin the pack

Agent Plugins 1.0 lets a skill pack move across IDEs. Copying a write skill from a blog is how you leak production. Pin versions. Treat packs as configuration. Review write tools like you review IAM.

Partner memo for Agent Plugins 1.0 [What It Changes]

The empty object is the only decision. Write it in one sentence on the whiteboard. If you cannot, you are still in a demo.

Quotes are dated PDFs. "Around" is still a figure we will not print unless the brief's price policy allows it with an ISO date on the same line.

Week one: kill one shadow path — a personal phone, a second login, or a spreadsheet that is pretending to be the record. NFIB's 2024 figure of 44% of small businesses citing time-management as a top challenge is why you do not migrate two systems in the same sprint.

Week two: one named owner for failures. If the owner is "whoever built it," you do not have an owner.

Week three: count the copy-paste jobs that remain. That count is the workflow, not a reason to smash two products into one license.

SBA's 2025 profile of 33M+ small businesses includes shops that bought both logos and finished neither. Sign one quote. Schedule the rest 60 days later.

F507 lives or dies on whether that sentence on the whiteboard matches the screen staff will actually live in. If the screens disagree, you picked the demo, not the leak.

Close-out checklist for Agent Plugins 1.0 [What It Changes]

1. Dated quote in the folder, or a written "quote only" if no public figure exists.

2. Named owner for week-one failures, not "the founder when they see it."

3. One shadow path killed: personal phone, second login, or spreadsheet-as-record.

4. Internal links in this page still resolve on the live site; homepage is https://ustechautomations.com/.

5. No second product in the same sprint. NFIB 44% is the constraint.

If any line is unchecked, you are not live. You have a login. F507 should not ship a second logo until those five lines are true. SBA's 33M+ small businesses include a lot of logins. Be the shop that finished one object.

Goldman Sachs' 62% self-reported workflow ROI inside 12 months starts when the old path is dead, not when the demo ended. Kill the old path. Then stop.

Desk rule for Agent Plugins 1.0 [What It Changes]

Source pack first. No invented vendor price. One shadow path killed this week. Humans keep merge rights. If the run is still on a personal login, it is not a desk tool. Pin the output to the job in the record. If you cannot name the record, stop.

According to AICPA, 62% of firms reported cloud-workflow adoption.

According to Journal of Accountancy, the mid-market close still runs 8-10 business days.

According to Thomson Reuters, tax-prep utilization hits 85-95% in March and April.

According to NFIB, 44% of small businesses cite time-management. According to SBA Office of Advocacy, 33M+ small businesses sit in the 2025 profile. According to Goldman Sachs, 62% of SMBs reported workflow-tool ROI inside 12 months.

Key Takeaways

• Agent Plugins 1.0.0 is a package format, not a new agent.

• Skills + MCP are in; hooks and custom agents wait.

• Five TSC members ≠ five identical loaders.

• Keep permissions in the client; the spec will not save you.

• Write the procedure once; ship the folder; stop pasting.

Agent Plugins 1.0 is a pack format

Portable skills and MCP packs across IDEs means a prompt file can move from Cursor to JetBrains without a rewrite. The risk is shipping a write skill in a pack you copied from a blog.

Signal: Agent Plugins 1.0. Speculation: every marketplace fills with unreviewed packs. Pin versions. US Tech Automations should treat a pack as configuration in the workflow, not as production access.

FAQ

What is Agent Plugins 1.0?

It is specification 1.0.0 of an open package format for agent skills and MCP servers, published at agent-plugins.org and announced by AWS on 6 August 2026.

Does every IDE support it today?

No. AWS says Kiro is rolling out support and the Agent Toolkit is compatible. Other named clients are TSC members or targets, not a conformance report.

How is this different from MCP?

MCP, at the spec, is how a tool server talks. Agent Plugins is how you put that server (and skills) in a folder other clients can scan.

How is this different from Agent Skills?

Agent Skills define SKILL.md. Agent Plugins can include a skills/ directory of those files plus mcp.json.

Can a non-developer use this?

You consume it as an install in Kiro or another client. You author it only if you already write runbooks. Start from executive-assistant automation as the content, then wrap the stable bits.

Will this lock me into AWS?

The spec is vendor-neutral. AWS's toolkit is one distribution. You can still ship a plugin that never calls AWS.

Where does this sit versus our workflows?

As the portable file next to an agentic workflow. Pricing still belongs to the workflow that has a reviewer, not to the zip file.

What to do next

Inventory the instructions you already paste into two editors. Put the stable ones in a SKILL.md. If a tool server exists, add mcp.json. Validate against the 1.0.0 schema. Install in one client, then a second. If the second client needs a com.vendor.* folder to work, you do not have a portable plugin yet.

When that pack is boring, keep using it from the same agentic workflow you already trust for form-to-CRM jobs — one procedure, many runtimes.