Skip to content

root / tags / packaging

#packaging

2 fiches

AI Coding Agents & Skills Auto-verified translation

Agent Plugins package your skills, tools, and more

**Google** announcement of **August 6, 2026**: Google joins as **Core Maintainer** of the **Agent Plugins 1.0.0** specification, an open, *vendor-neutral* packaging format for distributing **Agent Skills** and **MCP servers** together. ⭐ **The governance fact outweighs the technical fact**: the specification was published by a **TSC** whose Core Maintainers come from **Amazon, Cursor, Microsoft, OpenAI, and Vercel** — Google joins them, represented by **Kevin Hou** (Senior Staff Engineer, Google DeepMind). ⚠️ **Anthropic does not appear on this list**, even though the two packaged building blocks (**Agent Skills** and **MCP**) originate from Anthropic: the packaging layer for Anthropic's two formats is being standardized without Anthropic being named among the maintainers. **The diagnosis** is stated in one sentence: *« The core problem isn't the components. It's the manifest. »* A skill is portable, an MCP server is portable; **the box they are put in is not**, and each client had to invent it for itself — hence the forks, the copies of identical components, and their drift. **The format comes down to one constraint**: *« A plugin is a directory. That's the whole idea, and the restraint is the point. »* A `plugin.json` with **two useful lines** (`$schema` + `name`), skills in `skills/` in the Agent Skills specification format, servers declared in `mcp.json` **with an explicit `type` on each entry** (stdio, Streamable HTTP, or legacy HTTP+SSE) — no more transport inferred from the shape of the configuration object. ⭐ **The strength of the design lies in what the manifest cannot do**: it **can neither relocate components nor declare them inline**, so there is no discovery path to configure and no precedence order to learn. Operational corollary: **components fail independently** — an `mcp.json` server that fails to start does not take the plugin's skills down with it; the client skips the entry, continues, and reports the failure. **The accepted escape hatch** is the **reverse-domain** directory (`com.example.client/`), an extension space belonging entirely to one client (hooks, agents, commands) that others ignore: *« the portable core stays small because the non-portable parts have somewhere legitimate to go »*. **A rare section worth commending** — ***« Not Every skill should be a Plugin »*** : a single MCP server to a single client, `mcp.json` is enough; a single skill needs no plugin. The format is only justified for components **that belong together and must travel together**. ⚠️ **What v1 explicitly excludes** — and this is the point to remember before deployment: **no installation mechanism, no distribution protocol, no permissions model, no sandboxing requirement, no trust or provenance verification, no UX** — listed under *future considerations*, not passed over in silence. The whole fits into a **four-layer, independently adoptable stack**: **discover** (Agentic Resource Discovery), **describe** (AI Catalog, which would register the `application/agent-plugins+json` type), **package** (Agent Plugins), **execute** (MCP + Agent Skills). Two Google products already ship: **Agents CLI** (skills for agent building, evaluation, deployment, observability, publishing — usable from Antigravity, Gemini CLI, Claude Code, or Cursor) and **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).

#Agent Plugins#Agent Plugins 1.0.0#open specification

Trois signataires · répartis sur trois entités Google — ce qui dit déjà quelque chose de la portée interne de l'annonce :

Architecture & Construction Auto-verified translation

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

Analysis by Janakiram MSV (The New Stack, July 20, 2026) of the **architectural convergence** of the three hyperscalers' enterprise agent platforms: in nine months, **Amazon Bedrock AgentCore**, **Microsoft Foundry**, and **Gemini Enterprise Agent Platform** have converged on the **same six primitives** — runtime, memory, tool gateway, identity, observability, governance — under different brand names. What was a fragmented collection of libraries 18 months ago is becoming a distinct **platform layer**. The thesis: this convergence replays the **2011-2016 PaaS inflection**, where **Cloud Foundry** and **Heroku** unified VMs, load balancers, queues, and secret stores around a portable **application contract** — except that here **no equivalent contract yet exists**, and **no open source project has claimed it**. Consequence: an enterprise cannot **move an agent from one cloud to another** (session state, traces, and identity all end up with a single provider; migrating means rebuilding everything). The author proposes a **line-by-line mapping** of the Cloud Foundry contract onto agents, sets out three design principles (package the agent as **one deployable unit**, **attach** capabilities rather than embedding providers, integrate the **operational** layer into the abstraction), points to what open protocols (MCP, A2A, OpenTelemetry) leave out of scope — the **lifecycle** — and delivers three due diligence questions: **governance** (neutral foundation vs. vendor), **packaging** (the same artifact on two clouds without rewriting), **state** (exportable memory). Verdict: whoever ends up owning the **agent control plane** will define *what an agent is*.

#Enterprise agent platforms#architectural convergence#portability

Janakiram MSV