AWS Agent Registry: Warum ein zentraler Agenten-Katalog Agenten-Chaos verhindert

Die Einführung von generativer KI in Unternehmen hat eine unerwartete Herausforderung mit sich gebracht: die unkontrollierte Vermehrung von KI-Agenten. In Gesprächen mit Führungskräften aus Lateinamerika wurde deutlich, wie schnell sich ein scheinbar harmloser Trend zu einem organisatorischen Albtraum entwickelt.

Vor zwei Wochen erzählte mir ein Freund in einem Telefonat: „Ich habe vier Teams, die parallel Agenten entwickeln. Vor zwei Monaten stellte ich fest, dass zwei davon dieselbe Aufgabe erledigen – und das Schlimmste: Keiner der Agenten hat dieselben Sicherheitsvorkehrungen.“

Diese Beobachtung ist kein Einzelfall. Ähnliche Gespräche führten zu vergleichbaren Ergebnissen. Die erste Welle der KI-Agenten entstand oft bereichsspezifisch, ohne zentrale Koordination. Doch jetzt wird klar: Ohne eine strukturierte Lösung droht die Zahl der Agenten von acht auf fünfzig oder mehr anzuwachsen.

Für Unternehmen, die noch am Anfang stehen, gibt es eine gute Nachricht: AWS hat bereits im April 2026 eine Lösung vorgestellt, die genau diese Probleme adressiert. Der AWS Agent Registry ist ein privater Katalog, in dem Agenten, MCP-Server, Skills und benutzerdefinierte Ressourcen organisiert werden können. Dabei kommt ein durchdachtes Genehmigungsverfahren zum Einsatz, das sicherstellt, dass nur geprüfte und freigegebene Komponenten genutzt werden.

Die versteckten Kosten doppelter Agenten

Die Vorstellung, dass Agenten-Duplikate lediglich zu redundantem Code führen, greift viel zu kurz. Die realen Folgen sind weitaus problematischer:

• Doppelte Kosten: Zwei separate Agenten können unterschiedliche Kostenmodelle nutzen, was zu unnötigen Ausgaben führt.
• Sicherheitslücken: Unterschiedliche Sicherheitsvorkehrungen erhöhen das Risiko von Datenlecks.
• Komplexität in der Verwaltung: Zwei Teams, die dieselbe Aufgabe erledigen, können zu widersprüchlichen Integrationen führen – etwa bei Jira-Tickets, die durch zwei separate Agenten bearbeitet werden.
• Verwirrung in Krisensituationen: Bei einem Produktionsausfall ist unklar, welcher Agent der „offizielle“ ist.

Ein Beispiel aus der Praxis verdeutlicht die Dimension des Problems:

• Das SRE-Team baut einen Incident-Triage-Agenten, der mit Jira verbunden ist.
• Das Customer-Lifecycle-Team entwickelt einen Onboarding-Agenten, der ebenfalls Jira nutzt – jedoch für andere Ticket-Typen.
• Das Billing-Team erstellt einen MCP-Server für Stripe, der interne Funktionen zur PII-Redaktion nutzt, die bereits vom Compliance-Team bereitgestellt wurden.
• Das Data-Team entwickelt eine Athena-Wrapper-Funktion, die das Analytics-Team nicht findet und daher neu implementiert – dabei öffnet es eine Sicherheitslücke, die der ursprüngliche Agent bereits geschlossen hatte.

Jede dieser Entscheidungen mag für sich genommen sinnvoll erscheinen. Doch in der Summe führen sie zu einem unübersichtlichen Geflecht aus Agenten, Integrationen und Sicherheitsrisiken. Und spätestens wenn das Problem sichtbar wird, bleibt nur noch die aufwendige Migration aller Agenten in ein zentrales System.

Die Frage ist nicht, ob ein Agenten-Katalog benötigt wird, sondern wann er eingeführt wird: wenn erst acht Agenten existieren oder wenn bereits fünfzig im Einsatz sind.

AWS Agent Registry: So funktioniert die zentrale Verwaltung in der Praxis

Der AWS Agent Registry ist nicht unter „Build“ oder „Test“ im AgentCore-Dashboard zu finden, sondern unter „Discover“. Diese Platzierung ist kein Zufall: AWS positioniert den Registry als Entdeckungsdienst, nicht als Entwicklungsplattform. Das deutet darauf hin, dass zukünftige Integrationen mit Runtime und Gateway automatisch erfolgen könnten – etwa indem eingesetzte Agenten sich selbst in den Registry eintragen. Aktuell ist dies jedoch noch nicht der Fall.

Was im Registry katalogisiert werden kann

• MCP-Server: Diese werden gegen das offizielle MCP-Schema validiert. Sie enthalten die Schnittstellen, die Client-Agenten benötigen.
• Agenten: Diese werden gegen das A2A AgentCard-Schema validiert. Es handelt sich um unternehmensinterne Agenten, die von anderen Agenten aufgerufen werden können.
• Skills: Wiederverwendbare Fähigkeiten wie Python-Pakete oder Bibliotheken mit Metadaten und Dokumentation.
• Benutzerdefinierte Ressourcen: JSON-basierte Einträge für Lambda-Funktionen, interne HTTPS-Endpunkte oder andere Komponenten, die nicht in die oben genannten Kategorien passen.

Jeder Eintrag durchläuft einen Genehmigungsprozess:

• Nur APPROVED-Einträge sind in Suchergebnissen sichtbar.
• REJECTED- und DEPRECATED-Einträge bleiben als Historie erhalten, sind aber für Nutzer unsichtbar.

Kosten und Verfügbarkeit

Während der Preview-Phase ist die Nutzung kostenlos. Bei der allgemeinen Verfügbarkeit (GA) wird eine Gebühr pro Net Records (aktive Einträge) erhoben. Löscht man einen Eintrag, verringert sich die Zählung. Die Kosten für EventBridge, SNS und IAM bleiben unverändert und liegen im Cent-Bereich pro Monat – selbst für Labore.

Der Registry ist in fünf Regionen verfügbar:

• us-east-1
• us-west-2
• ap-southeast-2
• ap-northeast-1
• eu-west-1

API-Oberfläche und Anforderungen

Die API ist in zwei Ebenen unterteilt:

Steuerungsebene (`bedrock-agentcore-control`):

• CreateRegistry
• CreateRegistryRecord
• SubmitRegistryRecordForApproval
• UpdateRegistryRecordStatus

Datenebene (`bedrock-agentcore`):

• SearchRegistryRecords
• MCP-Endpunkt (HTTP-basiert)

Für die Nutzung ist boto3 in Version ≥ 1.42.87 erforderlich. Ältere Versionen unterstützen die Methoden nicht. Auch die AWS CLI muss auf Version ≥ 2.34.28 aktualisiert sein. Ein einfacher Test wie aws bedrock-agentcore-control list-registries sollte funktionieren – andernfalls hilft ein Update mit aws --version.

Typische Fallstricke bei der ersten Nutzung

In den letzten Tagen habe ich ein vollständiges Laborumfeld mit Terraform, IAM und Claude Code aufgebaut, um den Registry zu testen. Dabei stießen wir auf zwölf echte Herausforderungen – davon elf durch die aktuelle API und eine durch die bevorstehende A2A-Spezifikation.

Einige dieser Fallstricke sind subtil:

• Vier davon führen dazu, dass der erste Aufruf von create_registry_record scheitert – ohne dass die Fehlermeldung sofort auf den Grund hinweist.
• Die Genehmigungslogik ist nicht immer intuitiv, insbesondere wenn mehrere Teams gleichzeitig Einträge einreichen.
• Die Validierung gegen MCP- oder A2A-Schemata kann unerwartete Fehler verursachen, wenn Metadaten unvollständig sind.

Wer diese Fallstricke kennt, spart sich wertvolle Zeit und vermeidet frustrierende Debugging-Sessions.

Fazit: Governance als strategische Entscheidung

Die Einführung eines zentralen Agenten-Katalogs ist keine technische Spielerei, sondern eine strategische Entscheidung. Unternehmen, die frühzeitig handeln, sparen nicht nur Zeit und Ressourcen, sondern vermeiden auch das Risiko, später eine aufwendige Migrationswelle starten zu müssen.

Der AWS Agent Registry bietet eine solide Grundlage, um die Agenten-Landschaft zu strukturieren. Doch wie bei jeder neuen Technologie gilt: Die beste Lösung nützt nichts, wenn sie nicht konsequent eingesetzt wird. Die Verantwortung liegt bei den Führungskräften, die Agenten-Governance von Anfang an als Priorität behandeln – nicht als nachträgliches Korrektiv.

Die Zukunft der KI-Agenten wird dezentral und vernetzt sein. Wer jetzt die Weichen stellt, ist für die kommenden Herausforderungen bestens gerüstet.