Agent tooling had a packaging problem. The useful parts, like a skill, a script, or an MCP server, were often portable. The wrapper around them was not. On August 6, 2026, the Agent Plugins 1.0 specification was published to standardize that wrapper, and on August 12, 2026, GitHub shipped support across VS Code, Copilot CLI, the GitHub Copilot app, and the Copilot SDK. For a Friday tools post, that makes it more interesting than a feature list: it changes how teams package and share agent behavior.
1. What actually launched this month?
Two related things.
First, Agent Plugins 1.0.0 was published on August 6, 2026 as an open specification for packaging reusable agent components into a distributable plugin. The portable core is intentionally small: skills plus MCP server configuration.
Second, GitHub announced on August 12, 2026 that the format is generally available in VS Code, Copilot CLI, the GitHub Copilot app, and the GitHub Copilot SDK. That is the practical shift. A format only matters when real tools load it.
2. Why should a team care?
Because it removes duplicate packaging work.
Before this, a team could absolutely share agent customizations, but the same capability often had to be wrapped differently for different clients. GitHub's release note frames the point well: you might already have one skill and one MCP server that solve a real problem, but you were maintaining separate manifests or directory layouts around them.
If your team has a deployment runbook, a release checklist, a log-inspection flow, or a house style for code review, packaging that once is a better tool story than copy-pasting repo-local config forever.
3. What is portable, and what is still client-specific?
The important line is this: Agent Plugins 1.0 standardizes skills and MCP servers. That is the portable layer.
Other capabilities can still exist, but they are client-specific. VS Code's docs call out agents, hooks, and slash commands as client-specific capabilities. GitHub's docs also describe plugins as bundles that can include agents, hooks, and other extras, but the cross-tool promise is strongest around the standard pieces.
That means the safe mental model is:
- Put durable instructions and reusable workflows in
skills/. - Put tool integrations in
mcp.json. - Treat everything else as an extension, not the baseline.
4. What does the package look like?
Small, on purpose.
At minimum, the spec centers on a root plugin.json manifest. Skills are discovered from the skills/ folder, and MCP configuration is discovered from mcp.json. The spec also requires the manifest to declare the schema version it targets.
A minimal layout looks like this:
my-plugin/
plugin.json
skills/
deploy/
SKILL.md
mcp.jsonThat simplicity matters. A plugin that needs a wiki page to explain its layout is already drifting away from the point of the standard.
5. Where does GitHub fit versus VS Code?
GitHub is giving the format reach inside the Copilot ecosystem. VS Code is showing what cross-client behavior looks like in practice.
GitHub's August 12 changelog says one plugin can now be shared across compatible agent clients, and existing Copilot plugins still remain supported without forced migration. VS Code's plugin docs add an operational detail that matters for day-to-day use: Agent Plugins can be discovered from marketplaces, enabled per workspace, disabled without deleting configuration, and updated on their own cadence.
So the near-term tool takeaway is not "rewrite everything." It is "new shared plugins should target the portable format first."
6. How do teams govern this without making a mess?
GitHub's answer is to reuse the policy surface teams already have.
The August 12 release says Copilot Business and Enterprise customers can manage plugins with existing managed settings. The knobs to remember are enabledPlugins, extraKnownMarketplaces, and strictKnownMarketplaces. GitHub also recommends pairing plugin policy with MCP allowlists, because a plugin can carry server configuration as well as instructions.
That is the part that makes this feel production-ready instead of merely convenient. Distribution is useful; distribution plus control is what makes a tool viable in an enterprise.
7. Should you migrate an existing plugin now?
Only if you actually need portability.
GitHub explicitly says existing Copilot plugins remain supported and do not require migration. That is the right default. If a plugin only serves one client and already works, forced migration is busywork.
But if the same internal plugin is now wanted in VS Code, Copilot CLI, and another compatible client, the migration cost looks modest. GitHub describes it as mostly manifest work: add the schema declaration, keep skills in skills/, keep MCP config in mcp.json, and move Copilot-only files into the GitHub-specific namespace directory.
That is exactly the kind of migration worth doing: small mechanical change, clear reuse payoff.
8. What is the practical recommendation this week?
Adopt Agent Plugins 1.0 for new shared agent tooling, but keep the first version boring.
Start with one narrow plugin that solves a repeated internal job, such as release prep, incident triage, or environment diagnostics. Put the workflow in one skill. Add one MCP server only if it removes real manual steps. Keep client-specific extras out unless they are necessary.
The standard is new, but the launch is credible because the dates line up cleanly: spec published on August 6, GitHub support announced on August 12, and VS Code documentation already reflects the marketplace, enablement, and compatibility model. That is enough maturity for an internal pilot.
No, this is not the month to build a giant plugin platform. It is the month to stop packaging the same team knowledge three different ways.