Mit den neuen Agent Plugins ist die Begriffslandschaft rund um KI-Werkzeuge um eine Ebene reicher geworden – und um eine Verwechslungsquelle. Denn der Name führt in die Irre: Ein „Agent Plugin" ist kein Plugin für einen Agenten. Es ist ein Plugin für die Umgebung, in der Agenten laufen. Zeit, die Schachteln einmal sauber ineinanderzustellen.

Die Hierarchie: Vier Ebenen, klar getrennt

flowchart TD
  subgraph HOST["Host / Agent-Client · Claude Code, Copilot CLI, VS Code"]
    subgraph PLUGIN["Plugin · das installierbare Paket"]
      A["Custom Agents<br/><i>Rollen mit Auftrag</i>"]
      S["Skills<br/><i>einzelne Fähigkeiten</i>"]
      M["MCP-Server<br/><i>Zugänge zu Systemen</i>"]
      H["Hooks & Commands<br/><i>Automatisierung</i>"]
    end
  end
  A -. nutzen .-> S
  A -. greifen zu über .-> M
  style PLUGIN stroke:#cc171a,stroke-width:2.5px

Der Host ist die Laufzeitumgebung – das Programm, das Sie starten. Er stellt das Sprachmodell, die Werkzeugschleife und die Sicherheitsmechanik. Selbst tut er fachlich nichts; er führt aus, was ihm Agenten, Skills und Server bereitstellen.

Der Custom Agent ist eine Rolle: eine Markdown-Datei, die beschreibt, wer der Agent ist, was er erreichen soll und welche Werkzeuge er benutzen darf – etwa ein Redaktions-Agent, der recherchiert und Entwürfe ins CMS legt. Wichtig: Ein Agent kann in seiner Definition bereits eigene MCP-Server mitbringen. Er ist damit selbst schon ein kleines Bündel – die erste von zwei Verpackungsebenen.

Der Skill ist eine einzelne Fähigkeit mit klarem Ein- und Ausgabeprofil – wiederverwendbar, testbar, ohne Wissen über den größeren Zusammenhang. Die Abgrenzung zum Agenten haben wir ausführlich in KI-Agenten vs. Skills beschrieben; sie gilt unverändert.

Der MCP-Server ist die kontrollierte Brücke zu echten Systemen – CMS, Zeiterfassung, interne APIs. Er entscheidet, welche Endpunkte ein Agent überhaupt zu sehen bekommt. Details dazu im Beitrag über eigene MCP-Server mit .NET.

Das Plugin schließlich ist die äußere Schachtel: die zweite Verpackungsebene, die Agenten, Skills, MCP-Server und Hooks zu einem versionierten, installierbaren Paket zusammenfasst – verteilt über Marketplaces, im einfachsten Fall ein Git-Repository.

Die Eselsbrücke

Wenn Sie sich nur einen Satz merken wollen: Skills sind Fähigkeiten, Agenten sind Rollen, MCP-Server sind Zugänge, Plugins sind Pakete – und der Host ist die Bühne, auf der alles läuft. Ein „Agent Plugin" erweitert die Bühne, nicht den Schauspieler.

Wann brauchen Sie was?

Ihre Situation Baustein Warum
Eine wiederkehrende Aufgabe sauber lösen Skill Fester Ablauf, testbar – keine Agenten-Architektur nötig
Mehrstufiges Ziel mit Entscheidungsspielraum Custom Agent Rolle mit Auftrag und bewusst kleinem Werkzeugkasten
Zugriff auf interne Systeme (CMS, API, Tools) MCP-Server Kontrollierter Zugang mit minimalen Rechten
Alles an Team oder mehrere Rechner verteilen Plugin Löst kein Fach-, sondern ein Verteilungsproblem: Versionierung, Onboarding, zentrale Kontrolle

Die häufigste Verwechslung im Alltag wird bleiben, dass „Agent" auf zwei Ebenen auftaucht: als Komponente im Plugin und als Adjektiv am Plugin. Im Zweifel hilft die Frage: Wird hier eine Rolle beschrieben – oder etwas verpackt?

Fazit

Die gute Nachricht hinter der Begriffsflut: Die Architektur wird nicht komplizierter, sondern ordentlicher. Jede Ebene hat genau eine Aufgabe, und die Pakete sind erstmals über Werkzeuggrenzen hinweg kompatibel. Wer die Schachteln kennt, kann gezielt klein anfangen – ein Skill, ein Server – und später verlustfrei zum verteilbaren Plugin wachsen.

Sie möchten klären, welche dieser Bausteine Ihr Vorhaben wirklich braucht? Genau solche Architektur-Entscheidungen sind unser Alltag – mehr dazu auf unseren Seiten KI-Agenten für Unternehmen und MCP-Integrationen für Unternehmen.