Suraj Khaitan

Posted on Oct 2

Agent Plugins 1.0: Are Skills and MCP Servers Finally Becoming One Portable Package?

#ai #architecture #agents #agentskills

Agent Plugins 1.0 is a real, published, vendor-neutral standard for bundling Agent Skills and MCP server configuration in one directory. But commands, hooks, permissions, credentials, distribution, and governance are not suddenly universal. Here is what became portable, what remains client-specific, and how I would package agent capability for an enterprise without confusing a common folder layout with a common security model.

Research and product status checked October 2, 2026. Agent Plugins 1.0.0 is the current published release; 1.1.0 is a working draft.

The Package Works. The Behavior Changes.

Imagine a platform team builds an internal incident-response plugin.

It contains a skill that teaches an agent how to triage an alert, an MCP server that queries the observability platform, a command that starts the workflow, and a hook that blocks production changes unless an incident ticket is present.

The team installs the package in GitHub Copilot. It works.

Then another group asks to use it in Codex. A third uses Cursor. A fourth runs Claude Code. The package looks portable: Markdown, JSON, scripts, and one directory. Yet each client discovers different files, supports different transports, applies different permission prompts, expands different variables, and has its own marketplace and policy system.

So what exactly moved?

Until recently, the honest answer was: the repository moved, but the plugin did not. Authors duplicated manifests, rearranged directories, translated MCP configuration, and maintained client-specific installation instructions around the same underlying capability.

Agent Plugins 1.0 is the first serious attempt to define a common package boundary above two standards that already have cross-client traction: Agent Skills and the Model Context Protocol.

It is deliberately smaller than the plugin systems vendors already ship. That is not a flaw. It is the reason the standard has a chance of working.

Agent Plugins 1.0 makes the package structure portable, not the complete agent runtime. Skills and MCP configuration can travel together; commands, hooks, credentials, permissions, distribution, and governance still belong to the client.

That distinction is the whole article.

TL;DR

Agent Plugins 1.0 is real and published. It is an open, vendor-neutral specification with a plugin.json manifest, fixed component locations, JSON Schemas, client conformance rules, and a multi-vendor Technical Steering Committee.
The portable core has exactly two component types. Skills live under skills/; MCP server definitions live in mcp.json. Commands, hooks, agents, rules, LSP servers, and automations are explicitly outside the v1 portable contract.
A package can still carry client-specific features. Reverse-domain namespaces such as com.github.copilot/ let one directory include Copilot-specific commands or hooks without breaking other clients. Other clients ignore namespaces they do not implement.
Conformance is incremental. A client may conform while supporting only skills or only MCP. An MCP-capable client may support only one of stdio or Streamable HTTP. "Compatible" does not mean every component behaves identically everywhere.
The spec standardizes loading, not distribution. Marketplaces, registries, installation, updates, caches, enablement, user experience, and dependency resolution remain outside v1.
The spec does not provide a portable trust model. It defines path containment and safe configuration rules, but not signatures, publisher verification, permission declarations, approval UX, sandboxing, secrets, enterprise allowlists, or audit event schemas.
This is still a major architectural shift. Skills provide procedural knowledge. MCP provides external capability. Agent Plugins gives those pieces one versioned deployment unit that clients can inspect and load consistently.
Enterprises should treat plugins as executable supply chain. Use an approved registry, immutable versions, provenance, static validation, malware and secret scanning, capability review, sandboxing, scoped credentials, runtime policy, and audit telemetry.

Three Standards, Three Different Jobs

Skills, MCP, and Agent Plugins are related, but they are not interchangeable.

Layer	Core question	Portable artifact	What it does not decide
Agent Skills	What should the agent know how to do?	`SKILL.md`, scripts, references, assets	How external tools connect or how a package is installed
MCP	How does an agent communicate with tools and data?	Protocol messages between client and server	How a client discovers a packaged server configuration
Agent Plugins	How are reusable components shipped together?	`plugin.json`, `skills/`, `mcp.json`	The client's complete runtime, policy, marketplace, or UX

An Agent Skill is procedural competence. It can explain the sequence for investigating latency, include a query template, and bundle a deterministic script for parsing traces.

An MCP server is capability. It can expose search_logs, get_trace, or create_incident as tools backed by a real system.

An Agent Plugin is the package boundary. It says: these skills and these MCP connections belong to one versioned capability owned by one publisher.

That pairing matters because a tool schema rarely contains enough operational judgment to use the tool well. Giving an agent delete_deployment does not teach it when deletion is appropriate, which evidence to collect first, or what rollback path the company expects. A skill can carry that procedure. Conversely, a skill that says "query the incident platform" is incomplete if every user must manually configure the integration.

Skills describe the workflow. MCP exposes the action surface. The plugin ships them together.

This is the consolidation the ecosystem needed.

It is not, however, one universal extension API. The model, context strategy, tool approval flow, sandbox, identity, and client lifecycle remain outside the package contract.

What Agent Plugins 1.0 Actually Standardizes

The standard is intentionally filesystem-first. A conformant plugin is a directory with one required manifest and optional components in fixed locations:

incident-response/
|-- plugin.json
|-- skills/
|   `-- investigate-incident/
|       |-- SKILL.md
|       |-- scripts/
|       |   `-- normalize-alert.py
|       `-- references/
|           `-- severity-policy.md
|-- mcp.json
|-- com.github.copilot/
|   |-- commands/
|   `-- hooks/
|       `-- hooks.json
|-- LICENSE
`-- CHANGELOG.md

Only three paths in that example belong to the portable core:

plugin.json
skills/
mcp.json

The com.github.copilot/ directory is a client extension. It can make the package more useful in Copilot, but it has no portable meaning under Agent Plugins 1.0.

The manifest is small on purpose

A minimal manifest is almost boring:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "incident-response"
}

The schema is closed. The only permitted top-level fields are:

$schema
name
version
description
author
homepage
repository
license
keywords
extensions

You cannot add commands, hooks, agents, mcpServers, or arbitrary component paths at the top level and still call it a conformant Agent Plugins 1.0 manifest. Unknown fields are reported and ignored. Client-specific manifest data belongs under a reverse-domain key inside extensions.

That closed shape does two useful things.

First, it gives clients one unambiguous format detector. The canonical $schema value is not decorative editor metadata; it selects the versioned interpretation contract.

Second, it stops every client experiment from silently becoming part of the supposed portable standard. Extensions can evolve, but they must identify their owner.

Fixed locations remove translation

Skills are immediate child directories under skills/, each with a valid SKILL.md:

---
name: investigate-incident
description: Investigate production alerts using the approved triage sequence. Use when an alert, outage, elevated error rate, or latency regression is reported.
---

1. Confirm the affected service, environment, and time window.
2. Read references/severity-policy.md before assigning severity.
3. Gather logs and traces before proposing a mutation.
4. Require human approval before remediation in production.

The skill itself follows the separate Agent Skills specification. Agent Plugins defines where to find it in a package and what to do if it is invalid.

MCP servers live in one root mcp.json file:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "incident-api": {
      "type": "streamable-http",
      "url": "https://incident.example.com/mcp"
    },
    "local-alert-parser": {
      "type": "stdio",
      "command": "./bin/alert-parser",
      "args": ["--data", "${PLUGIN_DATA}/alerts"],
      "cwd": "${PLUGIN_ROOT}"
    }
  }
}

The format makes transport explicit. Version 1.0 defines:

stdio for a local process;
streamable-http for the current remote MCP transport; and
sse for the deprecated HTTP+SSE transport, which clients may omit.

It also standardizes ${PLUGIN_ROOT} for immutable packaged content and ${PLUGIN_DATA} for writable state that survives plugin updates. This solves a surprisingly important portability problem: installed paths vary, while caches, generated files, virtual environments, and downloaded dependencies should not be written into a versioned package directory.

Failure is isolated

The loading rules are designed for partial usefulness.

A fatal manifest error rejects the plugin.
A malformed top-level mcp.json disables MCP for that plugin but does not invalidate its skills.
One invalid MCP server entry does not disable valid sibling servers.
One invalid skill is skipped without removing other skills.
A server that fails to start, authenticate, or complete the handshake does not prevent independent components from loading.

That is production-minded design. A broken optional integration should be visible, but it should not erase unrelated capability.

Portable Does Not Mean Identical

The word "portable" attracts more promises than the specification makes.

Agent Plugins defines a common interoperability floor. A conformant client must load a plugin from a directory, validate the manifest, ignore unknown extension namespaces, discover the component types it supports, and enforce the relevant failure and path rules.

It does not have to support both portable component types.

A skills-only client can conform. An MCP-capable client can support stdio but not Streamable HTTP, or the reverse. Clients can expose skills differently, choose different base environments for local servers, and apply different consent and sandbox policies.

So portability has several layers:

Portability layer	Agent Plugins 1.0 status	Remaining variability
Package identity	Standardized	Registry coordinates and publisher identity are client-owned
Skill location and format	Standardized through Agent Skills	Triggering, presentation, allowed tools, and model behavior vary
MCP configuration	Standardized	Supported transports, authentication, approvals, and runtime isolation vary
Writable plugin state	Standardized through `PLUGIN_DATA`	Storage location, quota, backup, and deletion policy vary
Commands, hooks, agents, rules	Not portable in v1	Defined through client extensions or legacy formats
Distribution and updates	Not standardized	Git, marketplaces, registries, caches, and update policy vary
Security and governance	Not standardized	Trust, signatures, permissions, sandboxing, secrets, and audit remain client-owned

This means "write once, run everywhere" is too strong.

The more accurate promise is:

Package the common capability once, then let compatible clients load the subset they implement without repackaging the portable core.

That is less catchy. It is also genuinely useful.

The project's compatible-client catalog already includes products such as VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, Kiro, Hermes Agent, OpenClaw, Grok Bot, NanoClaw, and OpenHands. The catalog requires support to be available and verifiable, not merely announced.

But even that list should not be read as a feature-equivalence matrix. Check the component and transport support you need, the client version that provides it, and the policy behavior on the surface where the plugin will run.

Commands and Hooks Can Share the Package, Not the Contract

This is the point most summaries will get wrong.

Agent Plugins 1.0 does not standardize commands, hooks, custom agents, rules, LSP servers, or automations. The specification explicitly says these formats remain too client-specific for a stable portable contract.

It does provide a disciplined place for them.

Client-specific manifest data uses extensions:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "incident-response",
  "version": "1.0.0",
  "extensions": {
    "com.github.copilot": {
      "automations": {
        "paths": ["./incident-automations/"]
      }
    }
  }
}

Client-specific files use a top-level directory with the same reverse-domain namespace:

incident-response/
|-- plugin.json
|-- skills/
|-- mcp.json
|-- com.github.copilot/
|   |-- agents/
|   |-- commands/
|   |-- rules/
|   `-- hooks/
`-- com.example.other-client/
    `-- ...

VS Code and Copilot read the com.github.copilot namespace for their own agents, commands, rules, hooks, and related configuration. A client that does not implement that namespace ignores it without validating its contents.

This is a smart compromise. It allows one distributable directory to contain a portable center and richer client-specific edges. It prevents those edges from masquerading as universal behavior.

The cost is extension drift. A package may accumulate several near-duplicate commands, hook definitions, and agent profiles. Authors still need a source-of-truth strategy, compatibility tests, and a clear statement of what degrades on each client.

One package is possible.

One behavior is not guaranteed.

One Package Across Three Different Clients

The easiest way to understand the standard is to follow one artifact through different levels of support.

Return to the incident-response package. It contains:

one portable incident-triage skill;
one remote Streamable HTTP MCP server;
one local stdio parser;
a Copilot-specific /incident command; and
a Copilot-specific pre-mutation hook.

Assume the package itself is valid. What happens when three clients load the same directory?

Client A supports the full core and the Copilot namespace

This client validates plugin.json, discovers the skill, reads mcp.json, and connects both MCP servers. It also understands com.github.copilot, so the command and hook appear.

The user gets the richest experience:

/incident
  |
  v
investigate-incident skill
  |
  +--> local parser
  +--> remote incident API
  `--> pre-mutation hook before a production action

Even here, the package has not defined the whole control path. The client decides when to ask for tool approval, whether the local parser is sandboxed, which identity reaches the remote server, and how a denied hook affects the session. The downstream incident service still decides whether the caller may update a production incident.

Client B supports skills and MCP but not the Copilot namespace

This client loads the same portable skill and the same two MCP definitions. It ignores com.github.copilot/ without treating the package as invalid.

The slash command does not appear. The hook does not run.

The capability is still usable if the user asks, "Investigate this production alert." The skill can trigger from its description, guide the workflow, and call the available MCP tools. But the user experience and one enforcement layer have changed.

That missing hook must be visible in the support matrix. If it was the only mechanism preventing an unapproved mutation, the package was never safely portable. A security boundary that exists only in one ignored namespace is a client-specific guarantee, not a property of the plugin.

The correct design is to enforce production authorization in the downstream service for every client, then use the hook as an additional local control where supported.

Client C supports skills but not MCP

This client can still conform to Agent Plugins 1.0. It validates the manifest, discovers the skill, and ignores the unsupported MCP component type.

The triage procedure and bundled reference material remain useful. The agent can explain the approved sequence, normalize user-provided alert data with a bundled script if its runtime allows it, and produce a checklist for a human operator.

It cannot assume that search_logs or create_incident exists. A well-authored skill should distinguish required capabilities from optional acceleration:

If the incident-api MCP tools are available, use them to gather evidence.
Otherwise, ask the user for the alert, log, and trace exports needed for triage.
Never claim that a production incident was updated unless the tool result confirms it.

This is graceful degradation. It is not feature parity.

The compatibility profile belongs in the release

The plugin version alone does not communicate these differences. I would publish a tested compatibility profile beside every enterprise plugin release:

Client profile	Skill	Remote MCP	Local MCP	Command	Hook	Supported outcome
Full Copilot profile	Yes	Yes	Yes	Yes	Yes	Guided triage and governed updates
Portable core profile	Yes	Yes	Yes	No	No	Guided triage; runtime policy required separately
Skills-only profile	Yes	No	No	No	No	Procedure and evidence checklist only

Tested client names and minimum versions should replace those generic profile labels in a real release.

This is the operational meaning of partial conformance: one artifact can remain valid while its effective capability changes. Teams need to approve the package-client combination, not only the package in isolation.

The Standard Does Not Govern the Plugin

There are two different meanings of governance here.

The standard itself has an open governance model. Its Technical Steering Committee includes individual maintainers affiliated with Amazon, Cursor, Microsoft, OpenAI, and Vercel. The charter requires public decisions, vendor neutrality, and no single vendor controlling a majority of Core Maintainer seats.

That is governance of the specification.

It is not governance of installed plugins.

Agent Plugins 1.0 does not define:

trusted publishers or package signatures;
a universal registry or marketplace;
installation allowlists or blocklists;
permission declarations;
user consent and approval flows;
process or network sandbox requirements;
portable secret references;
OAuth configuration;
plugin dependency resolution;
standardized install and runtime audit events; or
a required validation and test harness.

The project's own future-considerations document names these gaps directly. They are not hidden limitations. They are intentionally deferred work.

This boundary matters because a package format cannot authorize an action.

plugin.json identifies a package. It does not prove who published it.

mcp.json tells a client how to connect. It does not decide whether that server should receive a credential.

A skill may recommend human approval. It cannot enforce approval.

Path containment prevents a package-declared path from escaping its root. It does not sandbox a process after launch.

Governance remains a runtime and organizational responsibility.

A Plugin Is an Executable Supply-Chain Unit

The package looks like documentation plus configuration. Treating it as harmless content would be a serious mistake.

Skills can steer the agent

A SKILL.md file enters model context as instructions. It can influence tool choice, data access, command execution, and the interpretation of user intent. Bundled scripts may execute with the permissions available to the agent runtime.

A malicious skill does not need an exploit if the host willingly follows its instructions.

Review the Markdown, scripts, references, generated commands, network destinations, and update path. Scan for prompt injection and dangerous behavior, but do not pretend static scanning can prove semantic safety. Test the skill against adversarial inputs and consequential tools.

Local MCP servers are code execution

A stdio MCP entry starts a process on the user's machine. The MCP security guidance is blunt: without consent and sandboxing, a malicious local server can execute arbitrary code with client privileges, read sensitive files, exfiltrate data, or destroy local state.

The Agent Plugins schema improves the configuration surface. It requires command to be one executable token, separates arguments, constrains package-relative paths, and reserves known variables. Those are worthwhile controls.

They are not a sandbox.

The process still needs an OS boundary, filesystem restrictions, network policy, scoped credentials, resource limits, and runtime telemetry appropriate to its risk.

Remote MCP moves the trust boundary

A Streamable HTTP server avoids launching local code, but introduces a remote service, authentication flow, network destination, data processor, and changing tool surface.

Agent Plugins 1.0 deliberately provides no portable OAuth or credential-reference fields. Literal headers and environment values are visible package data and must not carry secrets. Authentication discovery, user interaction, credential storage, and authorization remain client-managed.

That is the correct separation. A package should not smuggle a production token inside portable configuration. But enterprises still need to decide which identity reaches the server, which scopes it receives, how tokens are rotated, and whether each downstream operation performs resource-level authorization.

Updates change reviewed behavior

A plugin is versioned, but the specification does not prescribe immutable resolution or update policy. A marketplace may auto-update. A Git reference may move. An external package manager may resolve a different transitive dependency tomorrow.

For production use, pin the exact plugin artifact and every executable dependency. Record a digest. Require review for updates. Re-run validation and behavioral tests before promotion.

"Approved last month" is not a property of a package name. It is a property of a specific artifact and its resolved dependencies.

The Enterprise Architecture I Would Deploy

I would use Agent Plugins as a deployment format inside a larger control plane, not as the control plane itself.

Author repository
    |
    v
Schema + policy + security + behavior validation
    |
    v
Signed, immutable artifact + provenance + inventory
    |
    v
Approved enterprise catalog
    |
    +-------------------+-------------------+
    |                   |                   |
    v                   v                   v
VS Code / Copilot    Codex / ChatGPT     Other conformant clients
    |                   |                   |
    +-------------------+-------------------+
                        |
                        v
             Client runtime enforcement
      approvals, sandbox, identity, network, audit

1. Keep a portable core

Put only genuinely cross-client behavior in the core:

standards-compliant skills;
deterministic scripts with declared runtime requirements;
portable MCP configuration;
metadata, license, changelog, and support information.

Avoid writing a "portable" skill that secretly assumes one client's proprietary tools, path variables, or approval commands. If a requirement is client-specific, say so in the skill's compatibility metadata or move it into the relevant namespace.

2. Isolate client extensions

Use one reverse-domain namespace per client family. Generate duplicated artifacts from a shared source where practical, but test the generated output in the real client.

Do not let a Copilot hook become an undocumented security dependency for Codex users who never load it. The portable workflow must state which controls are advisory and which are enforced by a client extension.

For consequential workflows, publish a support matrix:

Capability	Portable core	Copilot extension	Other clients
Triage procedure	Yes	Yes	Yes
Observability MCP	Yes	Yes	Depends on transport support
`/incident` command	No	Yes	Client-specific entry point
Pre-mutation ticket hook	No	Yes	Requires equivalent local policy
Production approval	No	Runtime policy	Runtime policy

3. Validate structure before behavior

CI should fail on:

an unsupported or mismatched schema version;
an invalid plugin name;
unknown manifest fields;
malformed SKILL.md frontmatter;
a skill name that does not match its directory;
invalid MCP transport fields;
path traversal, unsafe symlinks, or missing packaged files;
literal credentials or suspicious secret patterns;
undeclared binaries or executable files; and
generated client extensions that differ from their source.

Then run behavior tests. Schema validity proves the package can load. It does not prove the skill triggers correctly, the server exposes the intended tools, or the workflow is safe.

4. Promote immutable artifacts

Build once. Produce an inventory of every file, executable, dependency, skill, server, endpoint, and extension. Attach a cryptographic digest, provenance, vulnerability results, and approval record.

Promote the same bytes from development to approved catalog. Do not rebuild separately for production if you want the review to mean anything.

Agent Plugins uses a directory as its logical unit, not a mandated archive format. Your distribution system can still create a deterministic archive or content-addressed artifact around that directory.

5. Enforce policy in the client and downstream service

The enterprise catalog answers: may this package be installed?

The client answers: may this process start, connect, read, write, or call a tool in this session?

The downstream service answers: may this authenticated principal perform this operation on this resource?

Keep those decisions separate.

GitHub and VS Code already expose examples of the needed outer layer: managed marketplaces, forced plugin enablement or disablement, MCP allowlists and denylists, managed-only hooks, plugin-only customization, sandbox controls, tool approval policy, network filtering, and telemetry. Claude Code has its own marketplace trust, managed plugin, permission, sandbox, and observability controls.

Those controls are not part of Agent Plugins 1.0. That is precisely why architecture must not stop at the manifest.

6. Collect evidence at runtime

Record at least:

plugin name, version, digest, publisher, and source;
install, update, enable, disable, and uninstall events;
loaded skills and client extensions;
MCP server start, connection, authentication, and failure events;
tool name, actor, target, approval decision, and outcome;
sandbox and network policy applied to local processes;
credential identity and scope, without logging the secret; and
policy denials, bypass attempts, crashes, and update drift.

The specification standardizes some failure behavior, not the audit schema. Build or adopt a client telemetry contract that your security and operations teams can actually query.

How to Test Whether a Plugin Is Really Portable

Do not test portability by copying the directory and checking whether an icon appears.

Test the capability across clients.

Package tests

Validate plugin.json and mcp.json against the exact 1.0.0 schemas.
Validate every skill against the Agent Skills specification.
Resolve every packaged path and reject escapes through symlinks or platform-specific filesystem behavior.
Verify that no portable file depends on an undeclared client namespace.
Generate a stable file inventory and digest.

Client matrix tests

For every supported client and version, verify:

the manifest is recognized as Agent Plugins 1.0 rather than a legacy format;
valid skills are discovered and invalid ones fail visibly;
each required MCP transport loads;
${PLUGIN_ROOT} and ${PLUGIN_DATA} resolve correctly on Windows, macOS, and Linux where supported;
independent components survive one server failure;
unsupported extensions are ignored rather than misinterpreted;
commands and hooks appear only where documented; and
disable and uninstall stop processes and handle persistent data as expected.

Behavioral tests

Use an evaluation set that measures more than final answers:

Did the correct skill trigger?
Did the agent follow the procedure before calling a tool?
Did it choose the read-only operation before mutation?
Did a missing MCP server degrade cleanly?
Did the runtime request approval at the expected boundary?
Did the downstream service reject an unauthorized action?
Did the trace identify the package and version responsible?

A package can be structurally portable and behaviorally unreliable. Measure both.

A Practical 30-Day Adoption Plan

Week 1: Choose one bounded capability

Pick a workflow with useful read operations and reversible writes: issue triage, documentation lookup, test analysis, cost investigation, or deployment-status review.

Inventory the current skills, MCP configuration, scripts, commands, hooks, credentials, and policies. Separate portable behavior from client-specific convenience and enforcement.

Week 2: Build and validate the portable core

Create the root manifest, move skills into fixed locations, translate MCP definitions into the closed mcp.json format, and replace installation-path assumptions with PLUGIN_ROOT or PLUGIN_DATA where allowed.

Add schema validation, skill validation, path-containment checks, secret scanning, dependency pinning, and an artifact inventory to CI.

Week 3: Add client extensions and policy

Put commands, agents, rules, and hooks into explicit client namespaces. Document degraded behavior for clients that do not implement them.

Configure an approved catalog, version pinning, MCP policy, scoped identity, sandboxing, network restrictions, approval rules, and telemetry in one pilot client. Do not rely on skill instructions as an enforcement mechanism.

Week 4: Run the compatibility and failure matrix

Test at least two clients against the same artifact. Break one skill, one local server, one remote authentication flow, and one extension. Confirm the documented failure boundaries.

Review the evidence with platform engineering, security, and the workflow owner. Promote only the digest that passed. Define update ownership and a rollback path before expanding access.

Seven Questions to Ask Before You Publish

Which files are portable, and which are client-specific? If the answer is "the whole folder," the review is not finished.
What executes with user privileges? Include skill scripts, local MCP servers, hooks, binaries, installers, and transitive dependencies.
Where do credentials come from? They should be client-mediated, short-lived, scoped, and absent from the package.
What happens on a partially compatible client? Name the missing transport, extension, control, or user experience explicitly.
How is publisher and artifact identity verified? A repository URL and package name are not provenance.
Which controls are deterministic? Separate written guidance from approvals, sandbox rules, network policy, and downstream authorization.
Can you identify and revoke one exact version? If not, you do not yet have a governable deployment unit.

What Comes After 1.0

As of October 2, 2026, version 1.0.0 remains the published release and 1.1.0 is a working draft. The project also records possible future work around permissions, consent, provenance, signatures, secrets, enterprise policy, audit events, dependencies, testing, and validation.

None of that future work should be described as a current guarantee.

I would also resist expanding the portable core too quickly. Commands and hooks look similar across clients until their event semantics, tool names, approval models, and failure behavior matter. Standardizing the wrong abstraction would create compatibility theater: files load, but the same policy means different things.

The right threshold is demonstrated convergence across multiple implementations, not demand for a longer feature checklist.

Version 1 succeeds if it makes the stable center boring and dependable.

Final Take

Agent Plugins 1.0 is not the moment every agent client becomes one platform.

It is the moment the ecosystem gets a credible common deployment unit for the two extension formats that have already crossed vendor boundaries.

That is meaningful progress.

Before this standard, a team could write one skill and build one MCP server, yet still maintain several wrappers to ship them together. Now the portable center has a name, a manifest, fixed locations, versioned schemas, failure semantics, and a conformance contract.

The standard also draws an honest line around what has not converged. Commands, agents, hooks, rules, distribution, authentication, permissions, sandboxing, and enterprise governance remain different because the underlying clients remain different.

Do not hide that difference. Architect for it.

Build the shared capability once. Isolate client-specific behavior. Govern the artifact before installation. Enforce trust at runtime. Authorize every consequential action at the system that owns the resource.

Agent Plugins makes skills and MCP portable as a package. The client still decides how that package becomes power.

That is not universal plug-and-play.

It is a solid interoperability floor - and floors are how durable ecosystems begin.

Sources and Further Reading

I am **Suraj Khaitan, an AI and cloud engineer focused on production agents, Claude Code, MCP, RAG, and serverless architecture. I write practical deep dives for engineers who want to move past demos and build AI systems that are reliable, observable, secure, and economically sane.