Agent plugins are runbooks, not decorations

GitHub's Agent Plugins 1.0 announcement looks like a packaging story: build one plugin, use it in VS Code, Copilot CLI, the Copilot app, and the Copilot SDK.

That is useful. It is also the least interesting part.

The more important bit is that the package can carry both skills and MCP server configuration. In plain English: the agent can receive the instructions and the tool wiring together. A deployment runbook can travel with the deployment tools. A repo policy can travel with the repo automation. The boring folder layout starts to look like product design.

Sources: GitHub's Agent Plugins 1.0 changelog, Agent Plugins author documentation, Agent Plugins specification, GitHub docs on enterprise managed settings for agents.

The tool is not enough

Most agent demos treat tools as the hard part. Give the model a GitHub API, a shell, a browser, and a Slack connector. Watch it move.

That framing is how you get confident chaos.

A tool tells the agent what it can touch. A runbook tells it when touching the thing is allowed, what evidence counts, how to recover, and when to stop. If those two live in different places, the workflow depends on memory, prompt discipline, or whichever context happened to be pasted into the chat that morning.

Agent Plugins 1.0 gives teams a cleaner unit: the capability plus the operating instructions. GitHub says a plugin can bundle skills with MCP configuration, while Copilot-specific files live in a com.github.copilot/ directory that other clients ignore. That is a good separation. The portable part stays portable. The platform-specific behavior does not leak into every other client.

This is how agent work should feel. Less magic. More manifest.

Portability changes the maintenance math

Before this kind of packaging, one automation often became three almost-identical integrations. One for the editor. One for the CLI. One for the app or cloud agent. Same policy, different wrapper. Same MCP server, different setup notes. Same mistakes, copied politely.

GitHub's migration guidance is mostly file movement: add $schema to plugin.json, keep skills under skills/, keep MCP configuration in mcp.json, and move Copilot-specific files into the namespaced directory.

That sounds minor until you operate agents across more than one surface.

If the same runbook works in VS Code and a headless CLI, the review burden drops. If the same MCP server definition follows the plugin, setup drift drops. If the package has a version, rollback becomes easier to discuss. Nobody has to ask which pasted prompt is the latest truth.

The best version of this is not a bigger marketplace. It is a smaller gap between "what the agent can do" and "what the organization has approved it to do."

Governance has to be part of the object

The enterprise settings paragraph in GitHub's announcement is easy to skim past. It should not be.

GitHub says organizations can use enabledPlugins, extraKnownMarketplaces, and strictKnownMarketplaces in managed settings, and pair plugin distribution with MCP allowlists by URL, command, or name. That is the difference between agent adoption and agent sprawl.

A plugin marketplace without policy is just a faster way to install surprise tools. A plugin format with allowlists, team overrides, and namespaced platform behavior starts to look like something an actual company can live with.

This is the bit I would copy for any internal agent platform:

1. Package tools and instructions together.
2. Version the package.
3. Make platform-specific behavior explicit.
4. Let admins approve plugins and MCP servers separately.
5. Treat installation as an operational decision, not a vibes decision.

The model still needs judgment. The package will not save a bad prompt or a careless workflow. But it makes the boundaries inspectable, and inspectable beats impressive almost every time.