abhinavbhatia
Sheet 02 / 05 — Blogs← Archive

Plugins vs agents: what changed in August 2026

On 6 August 2026 the major AI tool vendors agreed one way to package agent tools and instructions. This post explains the basics, shows what Agent Plugins 1.0 changed with one running example, and answers the question partners ask most: should I still build an agent?

· 13 min read · ~19 min listen· Agents · Plugins · MCP

On 6 August 2026, a group of companies including Amazon, Microsoft, OpenAI, Cursor and Vercel released Agent Plugins 1.0. It is an open standard that sets one way to package the things that make an AI agent useful: its instructions and its tools.

That sounds like a small thing to agree on, but it changes how every software company gets its product into AI tools. In this post I start with the basic terms, then compare how packaging worked before and after August, and finish with the question partners ask me most: where do agents still fit?

What do you need to know first?

You need six terms to follow this post. Each one builds on the one before.

Model. A large language model (LLM) reads text and predicts the text that should come next. Gemini, GPT and Claude are models. On its own, a model can only write a reply; it cannot look anything up or take an action in another system.

Agent. An agent is a model running in a loop so that it can plan and act. Give it a goal, and it breaks the task into steps, carries them out and checks the result. Copilot in VS Code, Cursor, Codex and Gemini Enterprise all run agents.

Tool. A tool is one action the agent can ask for, such as “search invoices” or “send an email”. In practice it is a function with a name, a description and an input schema (a description of the inputs it expects). The agent reads the description to decide when to call it.

MCP server. MCP stands for Model Context Protocol, the standard way to offer tools to an agent. An MCP server is a small service that lists its tools and explains how to call them. Any agent that supports MCP can use it, so you only build it once.

Skill. A skill is a set of written instructions for doing one task well. It is a folder containing a SKILL.md file, which says what the task is, when to use it and the steps to follow. The folder can also hold scripts and reference documents. Put simply, a tool is what the agent can do, and a skill is how to get a task done with those tools.

Plugin. A plugin is a folder that bundles skills and MCP server settings so they can be installed in one go. This is the layer that was standardised in August.

The diagram below shows how the six fit together:

WHO ASKS WHO THINKS WHAT IT IS GIVEN WHERE WORK RUNS User asks for a job Agent plans, acts, checks Model reads and writes text loop: plan → act → check → repeat PLUGIN = ONE FOLDER Skill (SKILL.md) how to do one job: steps, rules, templates MCP server offers the tools: list_invoices send_reminder Acme API your product 1 2 1 reads steps · 2 calls tools Model thinks. Tool acts. Skill says how. MCP server offers tools. Plugin carries both.

the six building blocks: a user asks an agent, the agent's model thinks, a skill says how, an MCP server offers the tools, and a plugin is the folder that carries the skill and the MCP config

What does this look like for a real product?

I will use one example for the rest of this post.

Acme is a company that sells invoicing software. Its customers ask: “Can my AI assistant find unpaid invoices older than 30 days and send a reminder?”

To make that work, Acme needs three things:

  1. Tools, so the agent can reach the product: list_invoices, get_customer and send_reminder, offered through an MCP server.
  2. A skill, so the agent follows Acme’s business rules: check the due date, skip customers on a payment plan, and use the polite template first, moving to the firm template only after 60 days.
  3. An agent that understands the user’s request, loads the skill and calls the tools in the right order.

Here is how one request flows through them:

User you Agent Gemini Enterprise Skill SKILL.md Acme MCP server the tools Acme system invoices DB 1 chase unpaid 2 load the skill 3 steps + rules 4 list_invoices(status=unpaid) 5 read invoices 6 get_customer(id) 7 send_reminder(id, polite) x14 8 send emails 9 sent 14, skipped 3 Solid = a call. Dashed = an answer coming back. The agent is the only thing that decides.

one request end to end: the agent loads the skill, then calls Acme's tools through the MCP server, then reports back

Notice who owns what. Acme builds the tools and the skill, but the agent belongs to another vendor: Gemini Enterprise, Copilot or Cursor. That split matters, and I come back to it later.

Before August: one product, five packages

MCP and skills already existed before August. The problem was packaging. Every AI tool had its own folder layout, its own file names and its own configuration format.

So for its tools and skill to work in five AI tools, Acme had to package them five times:

WHAT ACME BUILT WHAT ACME HAD TO SHIP, PER AI TOOL Acme 1 MCP server 1 skill 1 set of rules VS Code / Copilot .vscode/mcp.json + copilot-instructions.md Cursor .cursor/mcp.json + .cursor/rules/ Claude Code .mcp.json + .claude-plugin/ + CLAUDE.md Gemini Enterprise a whole A2A or ADK agent, hosted by Acme Codex ~/.codex/config.toml + AGENTS.md 5 packages · 3+ config formats · a fix in one copy is missing from the other four

before August 2026: the same Acme tools and skill had to be packaged again for every AI tool, each with its own files and format

Even the same settings were written differently. Here is the same Acme MCP server set up for three tools:

// VS Code: .vscode/mcp.json  (top-level key is "servers")
{ "servers": { "acme": { "type": "stdio", "command": "npx", "args": ["acme-mcp"] } } }
// Cursor: .cursor/mcp.json  (top-level key is "mcpServers")
{ "mcpServers": { "acme": { "command": "npx", "args": ["acme-mcp"] } } }
# Codex: ~/.codex/config.toml  (not even JSON)
[mcp_servers.acme]
command = "npx"
args = ["acme-mcp"]

It is the same server, yet it needs three formats, and that copying repeats for every tool and every skill.

Here is what that cost Acme in practice:

  • Five copies to maintain. One change to the reminder steps meant five edits.
  • Configuration drift. Drift is when copies that should match slowly stop matching. A bug fixed in the Cursor package could be missed in the Copilot one, so two customers got different behaviour from the same product.
  • Forced choices. Most teams supported one or two AI tools and left the rest, so customers on other tools had no integration at all.
  • Inconsistent onboarding. Every AI tool had a different installation guide.

What about Gemini Enterprise before August?

The Gemini Enterprise row in the diagram above is different from the others. Gemini Enterprise did not ask Acme for one more configuration file. In practice, it asked for a complete agent.

Google’s public release notes show what a partner could use before August:

  • Agents: supported. Since November 2025, an admin could register an agent built with ADK (Agent Development Kit, Google’s open framework for building agents) and hosted on Vertex AI Agent Engine, or any agent that implements A2A (Agent2Agent, an open protocol for agents to talk to each other). Since December 2025, partners could also offer A2A agents through Google Cloud Marketplace, in Preview.
  • MCP servers: only recently. Custom MCP server data stores arrived in April 2026 but were turned off by default. An organization policy administrator had to remove a constraint first.
  • Skills: not available to most customers. Creating skills in the Gemini Enterprise web app became possible in June 2026, but only for allowlisted projects.
BEFORE AUGUST: AGENTS EASY, TOOLS AND SKILLS HARD Nov 2025 register ADK + A2A agents Dec 2025 Marketplace A2A agents (Preview) Apr 2026 custom MCP server, off by default Jun 2026 skills, for allowlist only AUGUST 2026 6 Aug Agent Plugins 1.0 7 Aug custom MCP GA 13 Aug custom skills GA 17 Aug A2A agents GA Before August, the practical way in was a whole agent. In August, the open path opened too.

Gemini Enterprise before August 2026: agents could be registered from November 2025, while custom MCP servers and skills arrived later with limits, and all three became generally available in August 2026

So for Acme, the realistic way into Gemini Enterprise was the boxed approach: build the collections agent, host it and register it, even if Acme only needed to offer three tools and one procedure. That takes more effort, and Acme then owns a whole agent, including the model calls, hosting, testing and cost.

In the same month as Agent Plugins, all three became generally available. I come back to what that means for Acme later in the post.

After August: one folder, many tools

Agent Plugins 1.0 fixes the packaging problem. A plugin is a single folder with fixed file names, and the same folder loads in every AI tool that supports the standard:

WHAT ACME BUILDS WHERE IT WORKS acme-invoices/ ├─ plugin.json ├─ skills/ │ └─ chase-unpaid-invoices/ │ └─ SKILL.md └─ mcp.json one package, one format VS Code same folder GitHub Copilot same folder Cursor same folder ChatGPT & Codex same folder Kiro same folder OpenHands, and more same folder 1 package · 1 format · fix the skill once and every AI tool gets the fix

after August 2026: one Agent Plugin folder, loaded as-is by every AI tool that supports the standard

At the time of writing, the official list of compatible clients includes VS Code, GitHub Copilot, Cursor, ChatGPT and Codex, Kiro, and open-source agents such as OpenHands.

What is inside a plugin?

A plugin has four parts, and only one of them is required:

PART WHAT IT HOLDS WHO READS IT plugin.json required name, version, description every client skills/ optional one folder per job, each with SKILL.md clients that load skills mcp.json optional which MCP servers to start, how clients that speak MCP com.vendor.app/ optional extra features for one AI tool only that tool Blue = the portable core. Dashed = vendor extra: other tools simply ignore it.

the anatomy of an Agent Plugin: three portable parts every client understands, plus an optional folder only one client reads

The manifest, plugin.json, is the label on the folder: it says which plugin this is. Only $schema and name are required:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "acme-invoices",
  "version": "1.0.0",
  "description": "Find and chase unpaid Acme invoices."
}

The MCP configuration, mcp.json, is written once, in a single format:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "acme": { "type": "stdio", "command": "npx", "args": ["acme-mcp"] }
  }
}

The skill itself is a plain Markdown file, skills/chase-unpaid-invoices/SKILL.md:

---
name: chase-unpaid-invoices
description: Find unpaid invoices older than 30 days and send the right reminder.
---

1. Call list_invoices with status "unpaid".
2. Keep only invoices more than 30 days past the due date.
3. Skip customers who are on a payment plan.
4. Use the polite template up to 60 days. Use the firm template after 60 days.
5. Report how many reminders were sent and who was skipped, and why.

Features that only one AI tool supports go in a folder named after that vendor, for example com.example.client/. That tool reads it and every other tool ignores it, so you keep a single package and can still use a tool’s own features where they exist.

For Acme, this is what changes:

  • Before: one package per AI tool. Now: one package.
  • Before: a different configuration format in each tool. Now: one plugin.json and one mcp.json.
  • Before: fix a bug in every copy. Now: fix one file.
  • Before: support only the one or two tools you had time for. Now: reach every tool that supports the standard.

What does the standard not cover?

This is the part people often miss. Version 1.0 is deliberately narrow; the specification calls it a “small interoperability floor”, meaning the minimum that every tool agrees on. It standardises the package and nothing around it.

BUILT BY EACH VENDOR · DIFFERENT IN EVERY AI TOOL Install and updates not in the spec Store and discovery not in the spec Permissions and approval not in the spec Security and sandbox not in the spec Login and OAuth not in the spec AGENT PLUGINS 1.0 · THE SHARED FLOOR folder layout fixed names plugin.json who it is skills/ SKILL.md format mcp.json tool servers The package is the same everywhere. Trust, stores and sign-in are still decided by each vendor.

what Agent Plugins 1.0 standardises, the shared floor, and what it leaves for each vendor to build on top

These things are still left to each vendor:

  • Installation and updates. How a user finds and installs a plugin.
  • Marketplaces. There is no shared marketplace; each vendor runs its own.
  • Permissions and security. What a plugin is allowed to do, and who approves it.
  • Authentication. The standard defines no portable sign-in or OAuth fields, and it says that secrets must not be stored in the configuration. Each tool handles sign-in in its own way.

So Acme builds the package once, but it still has to be listed in each marketplace and still has to test sign-in in each tool. One honest gap: the standard solves packaging, but trust is still an open problem for now.

Where do agents fit now?

The question I hear most often from partners is: “If plugins are the new standard, should I still build an agent?”

The answer depends on two things: which part does the thinking, and how much of your logic you are willing to show. There are two ways to bring a product to an agent.

OPEN · AS A PLUGIN BOXED · AS AN A2A AGENT Host agent does the thinking Gemini Enterprise, Copilot, Codex ACME PLUGIN, INSIDE THE HOST Skill plain text: anyone can read MCP server tools only Acme API You share: your tools + your steps Host agent does the routing e.g. Gemini Enterprise Acme collections agent own model + own logic late-payment scoring stays inside the host never sees how task result only You share: only the answer

two ways to bring a product to an agent: open, as a plugin the host agent runs, or boxed, as your own agent the host calls over A2A

Option 1: Open, as a plugin. You give your tools and skills to another vendor’s agent. Gemini Enterprise, Copilot or Codex does the thinking, and your product carries out the actions through MCP.

This is the quickest way to reach users. However, a skill is a Markdown file. If Acme ships its reminder rules as a skill, anyone who installs the plugin can read them. The tools stay behind your MCP server, but the business logic is in plain text.

Option 2: Boxed, as an agent. You build and host your own agent with your own logic. Other agents talk to it through the A2A (Agent2Agent) protocol. The calling agent sends a task and gets a result back, with no view of how that result was produced.

What the calling agent does see is the boxed agent’s Agent Card: a small JSON file that names the agent, says where to reach it and lists what it can do. An illustrative card for Acme’s collections agent, using the fields of the A2A specification, looks like this:

{
  "protocolVersion": "0.3.0",
  "name": "Acme collections agent",
  "description": "Finds overdue invoices and chases them using Acme's own rules.",
  "url": "https://agents.acme.example/a2a/v1",
  "preferredTransport": "JSONRPC",
  "version": "1.0.0",
  "capabilities": { "streaming": true },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    { "id": "chase-overdue", "name": "Chase overdue invoices",
      "description": "Sends the right reminder to each overdue customer.", "tags": ["invoices"] }
  ]
}

The card says what the agent does, never how. The A2A specification defines every field.

Suppose Acme has a scoring model that predicts which customers will pay late, and that model is the reason customers buy Acme. Acme should not put that logic in a SKILL.md. It should keep it inside its own “collections agent” and share only the result.

Here are the two side by side:

Open: plugin Boxed: agent over A2A Who does the thinking The host agent Your agent What you share Tools + skills as plain text Only the result What you run An MCP server Model, logic, hosting Who owns answer quality Shared with the host You Effort Lower Higher Use it when Your value is data + actions Your value is your logic Most partners will end up with both. Decide per use case, based on what is your IP.

open plugin versus boxed agent, side by side: who thinks, what you share, what you run, who owns quality, effort, and when to use each

My view: you don’t have to pick one. Most partners will use both. Package common tasks as a plugin so every AI tool can use your product, and keep the logic that sets you apart inside an agent. Decide for each use case, based on where your intellectual property (IP) sits.

How does this map to Gemini Enterprise?

I work with partners on Google Cloud, so the next question is usually: “How does this map to Gemini Enterprise?” Everything below comes from Google’s public documentation, linked at the end.

Gemini Enterprise already has every building block described in this post. Gemini, the agent inside Gemini Enterprise, is the host agent: it receives a request, picks the right skills and tools, and carries out the task.

Gemini, the agent in Gemini Enterprise takes the request, picks the skills and tools, does the work Tools Ready-made connectors Custom MCP server Company tools registry Skills Built-in skills library Custom skills (GA, Aug 2026) Company skills registry Agents Third-party SaaS agents A2A agents you register Marketplace A2A agents Marketplace agents: Preview OPEN PATH: your MCP server + your skills, Gemini thinks BOXED PATH: your A2A agent Not yet: installing one Agent Plugins folder. Today a customer adds skills and MCP servers separately.

how the building blocks map to Gemini Enterprise: Gemini is the host agent, connectors and custom MCP servers are the tools, the skills library and registry are the skills, and A2A agents are the boxed path

Tools. Gemini Enterprise comes with ready-made connectors (built-in links to common systems) such as Salesforce, ServiceNow, Jira, Confluence, Slack, BigQuery and Databricks. Where no ready-made connector exists, an admin can add your MCP server as a custom MCP server data store, which has been generally available since 7 August 2026. The documentation sets two requirements worth knowing early. The server must use the Streamable HTTP transport (the older SSE transport is not supported), and it must present a TLS certificate issued by a public certificate authority. Teams can also publish tools for the whole organisation in a tools registry.

Skills. Gemini ships with a library of skills. Since 13 August 2026, users can also create, upload and share their own custom skills (generally available, turned on by an admin). Teams can publish skills to a shared company skills registry.

Agents. An admin can register an A2A agent hosted anywhere (generally available since 17 August 2026), or add a partner’s A2A agent bought through Google Cloud Marketplace (still in Preview). Users then reach it in the Gemini Enterprise web app.

So the two patterns map across directly:

  • Open path for Acme: publish the Acme MCP server so customers can add it as a custom MCP server, and provide the reminder steps as a skill they publish to their company registry. Gemini does the thinking. Acme also gets every ready-made connector without extra integration work, for example to check the customer’s account in Salesforce before sending a reminder.
  • Boxed path for Acme: run the collections agent on Acme’s own infrastructure, offer it over A2A and list it on Google Cloud Marketplace. The customer’s admin adds it, and Gemini hands the task to it. The scoring logic never leaves Acme.

One honest gap: Gemini Enterprise is not on the Agent Plugins compatible-clients list today. It already supports both things a plugin carries, skills and MCP servers, but a customer adds them separately rather than installing a single plugin.json folder. I will update this post if Gemini Enterprise adds native plugin installation.

Where is the industry heading?

Based on my reading and my conversations with partners, three trends are clear.

LAYER STATUS Distribution where users get it: each vendor's own store still open Package Agent Plugins 1.0: Amazon, Cursor, Microsoft, OpenAI, Vercel agreed Aug 2026 Know-how Agent Skills: SKILL.md, one folder per job settled Protocols MCP (agent ↔ tools) · A2A (agent ↔ agent) settled Build up from the bottom. The fight has moved to the top layer.

the agent stack in October 2026: protocols and formats are settled, packaging was agreed in August, and distribution is where vendors now compete

1. MCP and skills have become the standard in practice. Nobody is seriously debating any more how to connect tools or write agent instructions. MCP is now governed by the Linux Foundation’s Agentic AI Foundation, whose members include Google, Microsoft, OpenAI, AWS and Anthropic. Agent Plugins builds on MCP and skills without changing either.

2. Competition has moved up the stack. Now that packaging is shared, vendors will compete on what the standard leaves out: marketplaces, trust, permissions and user experience. Expect every platform to present its own marketplace as the default place to install from.

3. The list of signatories is worth a look. The Technical Steering Committee is currently Amazon, Cursor, Microsoft, OpenAI and Vercel. Anthropic created both MCP and Agent Skills but is not on that list. Nor is Google, even though it is a platinum member of the Agentic AI Foundation that governs MCP. The standard is open to anyone who wants to take part, so this may change. For now, the packaging standard is being shaped by the vendors whose AI tools developers use every day.

What I would do now

If you are a software company bringing your product to AI tools, this is what I would do:

  1. Build an MCP server first. The plugin depends on it, and your own agent can reuse it later.
  2. Write skills for your three most common tasks. Keep them short, and test them in two different AI tools to check that they really are portable.
  3. Package them as a single Agent Plugin. Stop maintaining one copy per tool.
  4. Work out where your IP is. If a skill would give away what makes you different, move that logic behind your own agent and offer it over A2A.
  5. Don’t wait for a shared marketplace. List your plugin in the marketplaces your customers already use.

What did we learn?

  • A tool is what an agent can do, a skill is how to get a task done, an MCP server offers the tools, and a plugin is the folder that carries skills and MCP settings together.
  • Before August 2026, the same tools and skill had to be packaged once per AI tool, in a different format each time.
  • Agent Plugins 1.0 sets one folder with fixed file names that every compatible AI tool loads as it is, but it leaves installation, marketplaces, permissions and sign-in to each vendor.
  • The open path ships tools and skills to another vendor’s agent, while the boxed path keeps the logic that sets you apart inside your own agent behind A2A.
  • Gemini Enterprise already has every building block (connectors, custom MCP servers, skills and A2A agents), although it is not yet on the list of compatible plugin clients.

What comes next?

Skills are the part of a plugin that carries your know-how, so they deserve a closer look. In Production-ready agents, Part 4: Skills I go one level deeper: what belongs in a SKILL.md, how an agent decides to load one, and how to write one that works reliably.

Sources

Opinions are my own. Every fact in this post comes from the public documentation linked above.