Agent Plugins: der neue offene Standard für KI-Agent-Erweiterungen

Was Agent Plugins wirklich ist

Ich baue Integrationen beruflich, daher ist meine erste Reaktion auf jeden neuen Standard, zu prüfen, wie viel davon echte Spezifikation und wie viel Pressemitteilung ist. Dieser hier ist größtenteils Spezifikation.

Agent Plugins beschreibt sich selbst als einen offenen, anbieterneutralen Standard zum Verpacken wiederverwendbarer Komponenten, die KI-Agenten erweitern. In der Praxis wird nur eine Sache standardisiert: die Form des Ordners. Wo das Manifest liegt, welche Felder es enthalten darf, wo ein Client nach Skills suchen soll und wo er nach der MCP-Server-Konfiguration suchen soll. Alles andere, einschließlich Installation, Marktplätze, Berechtigungen und die gesamte Nutzererfahrung, bleibt Sache jedes einzelnen Clients.

Das kleinste Plugin, das überhaupt etwas tut, besteht aus drei Dateien:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

Und das Manifest kann zwei Zeilen umfassen:

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

Das war's. $schema und name sind die einzigen Pflichtfelder. Alles andere, version, description, author, homepage, repository, license, keywords, extensions, ist optional.

Das Problem, das damit gelöst wird, ist unspektakulär und real. Jeder Agent-Client hat sein eigenes Plugin-Format entwickelt, sodass dieselbe Skill für jeden Client neu angeordnet werden musste, und ein für einen Client gebautes Paket musste erst angepasst werden, bevor ein anderer es laden konnte. Wer schon einmal dieselbe SKILL.md in vier verschiedenen Repo-Strukturen gepflegt hat, kennt die Form dieses Schmerzes bereits. Es ist dieselbe Zersplitterung, die es vor ein paar Jahren mühsam machte, über ChatGPT-Plugins und GPTs und Actions nachzudenken, nur dass es jetzt mehr Clients gibt.

Was in ein Plugin gehört, und was nicht

Version 1 definiert genau zwei Komponententypen. Skills und MCP-Server. Das ist bewusst eine kleine Zahl und die interessanteste Designentscheidung im gesamten Dokument.

Beide liegen an festen Orten, die das Manifest nicht überschreiben darf. Skills liegen in skills/, jeweils ein Unterverzeichnis pro Skill, das eine SKILL.md enthält. Die MCP-Konfiguration liegt in mcp.json im Wurzelverzeichnis. Die Spezifikation legt ausdrücklich fest, dass ein Client nicht tiefer rekursieren darf, um weitere Skills zu suchen, und keine MCP-Konfiguration akzeptieren darf, die inline in plugin.json deklariert ist.

Für das Format von SKILL.md selbst gibt die Spezifikation die Verantwortung vollständig ab: Skills müssen der Agent-Skills-Spezifikation entsprechen, die weiterhin die maßgebliche Quelle für das Frontmatter und die Struktur von scripts/, references/ und assets/ bleibt. Agent Plugins sagt nur, wo man sie findet.

Hier ist, was mitreist und was nicht:

Alles, was ein Client zusätzlich hinzufügen möchte, kommt in einen Reverse-Domain-Namespace, entweder als Schlüssel unter extensions im Manifest oder als Verzeichnis oberster Ebene namens com.example.client/. Andere Clients sind verpflichtet, Namespaces zu ignorieren, die sie nicht implementieren, ohne den Inhalt auch nur zu validieren. Das ist eine kleine Regel mit großer Konsequenz: Ein Plugin kann clientspezifische Extras enthalten und trotzdem überall sonst sauber laden.

Die MCP-Seite hat mehr Biss, als ich erwartet hatte. Drei Transportarten werden anerkannt, stdio, streamable-http und das veraltete sse, und ein konformer Client muss mindestens eine der ersten beiden unterstützen. Remote-Endpunkte müssen HTTPS verwenden, außer der Host ist Loopback. Jeder stdio-Subprozess erhält die Umgebungsvariablen PLUGIN_ROOT und PLUGIN_DATA, und ${PLUGIN_ROOT} sowie ${PLUGIN_DATA} werden innerhalb von args, env und cwd expandiert, sonst nirgendwo. Die Pfadeingrenzung wird durchgängig erzwungen, sodass ein command wie ../bin/server ungültig ist und nicht nur davon abgeraten wird.

Fehlerisolation ist der Teil, auf den ich mich in der Produktion tatsächlich verlassen würde. Ein defekter MCP-Eintrag deaktiviert diesen Server, nicht das Plugin. Eine fehlerhafte SKILL.md überspringt diese Skill, nicht den Ordner. Ein Plugin, das die Schema-Validierung des Manifests nicht besteht, wird jedoch komplett abgelehnt, und keine seiner Komponenten läuft. Diese Grenzen werden einzeln aufgeführt, was ein gutes Zeichen dafür ist, dass Leute daran geschrieben haben, die so etwas schon ausgeliefert haben. Wer schon einmal eine halb geladene MCP-Integration debuggt hat, weiß diese Präzision zu schätzen.

Welche Teile deiner Erweiterung tatsächlich mitreisen

Statt die Aufteilung noch einmal zu beschreiben, hier dieselbe Information zum selbst Ausprobieren. Wähle eine Komponente und sieh, ob sie einen Wechsel zwischen Clients übersteht.

Wer wirklich dahintersteht

Standards leben oder sterben mit ihrer Governance, daher ist das der Abschnitt, den ich zuerst lese.

Das Technical Steering Committee besteht aus fünf Personen, jede als Individuum mit einer angegebenen Zugehörigkeit benannt, statt als Sitz eines Unternehmens:

Vercels Ankündigung nennt eine etwas breitere Gruppe und führt Amazon Web Services, Anysphere, GitHub, Microsoft, OpenAI und Vercel als gemeinsame Entwickler des Standards auf.

Die Charta enthält drei Klauseln, die es wert sind, zweimal gelesen zu werden. Kein einzelner Anbieter darf die Mehrheit der Core-Maintainer-Sitze kontrollieren. Alle Governance-Rollen werden von Einzelpersonen besetzt, und es sind keine Sitze für Unternehmen reserviert. Und Name, Logos, Domains und GitHub-Organisationen werden treuhänderisch von einer neutralen, vom Komitee bestimmten Institution gehalten, wobei kein Anbieter die exklusive Kontrolle über die Projektidentität beanspruchen darf.

Die Belege stützen das. Das Repository wurde bei vercel-labs/open-plugin-spec inkubiert und liegt jetzt unter einer separaten Organisation namens agentplugins, wobei der Spezifikationstext unter CC-BY-4.0 und der Code unter Apache 2.0 stehen. Sollte der Neutralitätsanspruch jemals nicht mehr gelten, bedeutet die Lizenzierung, dass das Ganze forkbar bleibt statt vereinnahmt zu werden. Das ist ungefähr dasselbe Playbook, das die Branche bei der Arbeit am agentic commerce protocol verfolgt hat, und es ist ein besseres Zeichen als eine Konsortiums-Pressemitteilung ohne Repository dahinter.

Die Anthropic-förmige Leerstelle

Anthropic taucht nicht auf der Maintainer-Liste auf, und Claude Code gehört nicht zu den von Vercel genannten Launch-Clients. Das ist es wert, kurz innezuhalten, denn Claude Code ist der Ort, an dem derzeit ein sehr großer Anteil des tatsächlichen Plugin-Schreibens stattfindet, und weil Agent Skills dort ihren Anfang nahm.

Die Formate sind ähnlich, aber nicht kompatibel. Anthropics dokumentierte Plugin-Struktur legt das Manifest unter .claude-plugin/plugin.json und die MCP-Konfiguration unter .mcp.json ab, beides versteckte Pfade, während Agent Plugins ein sichtbares plugin.json und mcp.json im Wurzelverzeichnis verwendet. Claude Code liefert außerdem Komponententypen aus, die der Standard überhaupt nicht abdeckt, und dieselbe Form taucht erneut im Cowork-Plugin-Format und in den IDE-Plugins auf.

Das sind Unterschiede im Dateipfad, also die am leichtesten zu behebende Art von Inkompatibilität überhaupt. Ein Plugin könnte schon heute beide Manifeste ohne großes Drama mitführen. Aber bis jemand diese Arbeit erledigt, pflegt ein Autor, der beide Ökosysteme bedienen will, weiterhin zwei Strukturen, und genau das ist das Problem, das der Standard eigentlich beseitigen sollte. Ich würde die Abwesenheit nicht als Ablehnung lesen, und es gibt in keine Richtung eine öffentliche Aussage. Ich würde sie als unfertig lesen.

Es lohnt sich anzumerken, dass sich dasselbe Muster auch anderswo abspielt. Atlassian liefert Rovo-Agent-Skills, ServiceNow liefert eigene Agent-Skills, und Freshworks liefert eine vorgefertigte Skills-Bibliothek. Keines davon fällt in den Geltungsbereich einer auf Coding-Agenten ausgerichteten Spezifikation, aber es ist dieselbe Idee, auf fünf verschiedene Arten verpackt, was zeigt, wie früh das alles noch ist.

Was Version 1.0.0 bewusst offenlässt

Das ist der Abschnitt, den ich mir von einem Sicherheitsprüfer gelesen wünschen würde, bevor irgendjemand irgendetwas installiert.

Die Maintainer sind erfrischend offen, was die Lücken angeht. Ein eigenes future considerations-Dokument listet als Dinge auf, die v1.0.0 nicht definiert:

• Ein Vertrauensmodell, Berechtigungssystem oder Sandboxing. Keine Capability-Deklarationen, keine Zustimmungs-Flows, keine abgestuften Vertrauensstufen.
• Herkunftsverifizierung. Keine Signaturprüfung, keine Attestierung, die ein veröffentlichtes Plugin mit seinem Quell-Repository verknüpft.
• Umgang mit Geheimnissen. Die Spezifikation verbietet Zugangsdaten in env und in HTTP-headers, bietet aber keine portable Alternative.
• Enterprise-Kontrollen. Keine Allowlists, keine Blocklists, keine organisationsweiten Registries, keine zentral verwalteten Policy-Overrides.
• Audit-Trails. Kein standardisiertes Event-Schema für Installation, Aktivierung, Update oder Deinstallation.
• Abhängigkeitsauflösung. Plugins können keine Abhängigkeiten zu anderen Plugins deklarieren.

Die Spezifikation enthält durchaus echte Sicherheitsregeln, wo sie kann: Pfade müssen innerhalb des Plugin-Wurzelverzeichnisses bleiben, Nicht-Loopback-MCP-Endpunkte müssen HTTPS verwenden, konfigurierte Header dürfen nicht ohne explizite Nutzerautorisierung über eine Weiterleitung zu einem anderen Origin weitergereicht werden, und Clients dürfen beim Laden eines Plugins kein Schema über das Netzwerk abrufen. Das ist alles sinnvoll. Es dreht sich aber auch ausschließlich um das Paket, nicht darum, was dieses Paket anschließend tun darf.

Die ehrliche Lesart lautet also so. Agent Plugins löst die Distribution. Es löst nicht das Vertrauen. Ein MCP-Server innerhalb eines Plugins kann einen beliebigen Prozess mit deiner Umgebung starten, und der Standard sagt nichts darüber aus, ob das erlaubt sein sollte. Ob das in Ordnung ist, hängt vollständig davon ab, in welchem Client man es installiert und welche Berechtigungskontrollen dieser Client zufällig mitbringt. Bei Claude Code bedeutet das Admin-Kontrollen und settings.json; anderswo bedeutet es, was der jeweilige Anbieter entschieden hat.

Was das bedeutet, wenn du KI-Agenten kaufst, statt sie selbst zu bauen

Die meisten Leser eines Artikels über eine Plugin-Spezifikation sind Entwickler. Aber der Effekt zweiter Ordnung trifft jeden, der KI-Agenten für eine Geschäftsfunktion evaluiert, und Support ist der klarste Fall.

Das Versprechen eines portablen Plugin-Formats lautet, dass deine Erweiterung nicht Geisel eines einzelnen Anbieters ist. Das stimmt, und es ist ein guter Grund, Clients zu bevorzugen, die es unterstützen. Es ist aber auch enger, als es klingt, denn Portabilität des Pakets ist nicht dasselbe wie Portabilität des Ergebnisses. Dass deine SKILL.md sauber zwischen zwei Clients wandert, bedeutet nicht, dass sich der Agent in beiden gleich verhält, dieselben Tool-Berechtigungen hat oder denselben Anteil an Tickets löst. Diese letzte Zahl ist es, die das Projekt finanziert, und daran wird ein KI-Agent für den Kundenservice tatsächlich gemessen.

Ich erlebe dieselbe Argumentation ständig in Build-versus-Buy-Gesprächen. Eine Engineering-Leitung, mit der wir zusammengearbeitet haben, brachte die Rechnung besser auf den Punkt, als ich es könnte:

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

Das ist eine Engineering-Leitung, die eine Wissensdatenbank mit über 300 Artikeln in Confluence und Telegram betreibt und sich fürs Kaufen statt fürs Selbstbauen entschieden hat. Ein Standard senkt die Kosten, Bausteine zusammenzusetzen. Er tut nichts gegen die laufenden Kosten, das Ergebnis zu besitzen, und genau da werden diese Projekte tatsächlich teuer.

Die drei Fragen, die ich jedem Anbieter stellen würde, Standard hin oder her:

1. Kann ich exportieren, was ich ihm beigebracht habe? Prompts, Regeln, Eskalationslogik. Lautet die Antwort Nein, ändert ein portables Plugin-Format nichts an deinem Lock-in.
2. Wer entscheidet, was er berühren darf? Da v1 kein Berechtigungsmodell definiert, ist das eine Antwort, die sich pro Client unterscheidet, und man sollte sie schriftlich einholen, bevor irgendetwas eine produktive Warteschlange erreicht. Für regulierte Teams fließt das direkt in die Datenschutzprüfung ein.
3. Kann ich ihn vor dem Livegang gegen meine eigene Historie testen? Eine Simulation gegen von jemandem geschriebene Szenarien ist nicht dasselbe wie ein Trockenlauf über die eigenen vergangenen Tickets.

Bei dieser dritten Frage würde ich keine Kompromisse eingehen. Wir haben schon erlebt, wie ein selbstsicher klingender Bot still und leise falsche Antworten gibt, und genau deshalb wird jeder Rollout bei eesel zuerst gegen historische Tickets simuliert, statt einfach eingeschaltet und beobachtet zu werden.

eesel ausprobieren für Support, der sich in das einklinkt, was du schon nutzt

eesel greift dieselbe Idee auf, die Agent Plugins verfolgt, dich dort abzuholen, wo du bereits arbeitest, und wendet sie auf das Helpdesk an. Es verbindet sich mit Zendesk, Freshdesk und Gorgias, dazu Slack, Confluence und dem Rest deiner internen Wissensdatenbank, und entwirft dann Antworten oder löst Tickets basierend auf dem, was es dort lernt.

Das Unterscheidungsmerkmal ist die dritte Frage von oben. Bevor eesel auch nur ein einziges live geschaltetes Ticket beantwortet, lässt du es über deine eigene Ticket-Historie laufen und siehst, was es gesagt hätte, bei welchen Tickets und mit welcher Konfidenz. Danach wählst du aus, welche Ticket-Arten es berühren darf. Es ist kostenlos zum Ausprobieren, und die Einrichtung dauert Minuten statt eines Quartals.

Wie es weitergeht

Mein Eindruck nach einem Tag mit der Spezifikation: Das Format ist klein genug, um schnell übernommen zu werden, die Governance ist stärker als bei den meisten Standards in ihrer ersten Version, und die Sicherheitsgeschichte ist eine bewusste Lücke mit angehängter Roadmap. Eine minimale Spezifikation, die tatsächlich erscheint, schlägt eine umfassende, die sich noch streitet, und Agent Plugins ist eindeutig ersteres.

Zwei Dinge würde ich beobachten. Ob Anthropic sich annähert, denn die Lücke besteht im Grunde aus zwei Dateipfaden und einem Ökosystem voll zusätzlicher Komponententypen. Und ob v1.1 ein Berechtigungsmodell liefert, bevor jemand ein Plugin ausliefert, das alle sich wünschen lässt, es hätte schon eines gegeben.

Wer gerade KI-Agent-Tools auswählt, egal ob es ein Coding-Agent wie Cursor oder eine agentische CLI ist, sollte Agent-Plugins-Unterstützung als leicht positives Signal für die Haltung eines Anbieters zu Lock-in behandeln. Und dann die Antworten dieses Anbieters zu Berechtigungen und Tests als das behandeln, was die Sache tatsächlich entscheidet.