AWS Agent Registry: KI-Agenten finden ihre Tools zur Laufzeit selbst

Das Problem mit fest verdrahteten Tools

Laut AWS funktionieren fest eingebundene Tools bei einer Handvoll problemlos, beginnen bei einigen Dutzend zu leiden und sind darüber hinaus kaum noch beherrschbar. Unternehmenssysteme können Hunderte interner APIs für Preise, Support, Bestellungen, Lagerbestand und Kundendaten bereitstellen. In solchen Systemen verbrauche das Modell, so AWS, womöglich mehr Tokens darauf, Toolnamen auseinanderzuhalten, als darauf, die Anfrage des Nutzers zu durchdenken.

Außerdem erfordert jede neue Fähigkeit eine Codeänderung im Orchestrator, ein erneutes Deployment und einen abgestimmten Release über mehrere Teams hinweg, die lieber in ihrem eigenen Takt ausliefern würden. AWS beschreibt dies als Muster aus Enterprise-SaaS-Projekten, in denen große interne API-Landschaften für agentische Anwendungen geöffnet werden.

Die vorgeschlagene Alternative: Der Agent entdeckt relevante Tools zur Laufzeit. Die AWS Agent Registry ist ein verwalteter Dienst zum Katalogisieren und Auffinden von Model-Context-Protocol-Servern (MCP), Agenten und Agent Skills. Herausgeber registrieren protokollspezifische Deskriptoren und durchsuchbare Beschreibungen. Ein Orchestrator kann freigegebene, auffindbare Einträge durchsuchen und anhand des zurückgelieferten Endpunkts und der Deskriptorinhalte einen Client aufbauen.

Discover, Instantiate, Execute

Im Beispiel verfügt der Orchestrator-Agent über keinerlei eingebautes Wissen über Tools oder Agenten. Die Schleife läuft in drei Schritten ab.

• Discover: Der Orchestrator sendet eine Anfrage in natürlicher Sprache an die Data Plane der Registry. Die Ergebnisse enthalten Identität, Name, Beschreibung, Typ, Status und Version des Eintrags sowie Protokolldeskriptoren wie MCP-Server-Metadaten oder eine A2A Agent Card. Zugangsdaten für den Aufruf sind nicht enthalten.
• Instantiate: Für jeden zurückgelieferten Eintrag baut der Orchestrator anhand des Deskriptortyps einen Client auf. Der MCP-Deskriptor verweist auf einen Endpunkt des Amazon Bedrock AgentCore Gateway, das Cognito-OAuth-Zugriffstoken holt der Orchestrator separat ab. A2A-Einträge enthalten eine Agent Card, deren URL einen AgentCore-Runtime-Endpunkt bezeichnet. Dieser wird über den boto3-Data-Plane-Client mit den AWS-Zugangsdaten des Aufrufers angesprochen.
• Execute: Es wird ein kurzlebiger innerer Agent nur mit den entdeckten Tools erzeugt, das Large Language Model wählt die passenden aus, und das Ergebnis wird für den Nutzer zusammengeführt. Anschließend werden der innere Agent und seine Clients abgebaut, und die nächste Anfrage startet mit einer frischen Suche und einem neuen Tool-Satz.

AWS betont, dass die Suche in der Registry Verbindungsmetadaten liefert, aber kein Authentifizierungsmaterial. Die Anwendung muss Zugangsdaten über einen separaten, vertrauenswürdigen Konfigurationsweg beziehen.

Referenzarchitektur und Freigabe-Workflow

Das Beispiel stellt einen MCP-Server für das Bestellmanagement über AgentCore Gateway bereit, dazu zwei A2A-Agenten (Pricing und Customer Support) auf der AgentCore Runtime, eine Registry und einen Orchestrator. Die Architektur nutzt außerdem Amazon Bedrock, Amazon Cognito, AWS Lambda und AWS Secrets Manager. Aktuell konfiguriert das Beispiel ein Anthropic-Claude-Sonnet-Modell über eine regionsübergreifende Modell-ID.

Governance ist fest im Katalog verankert. Bei deaktivierter automatischer Freigabe muss ein neuer Eintrag von DRAFT über PENDING_APPROVAL nach APPROVED wechseln. Die Aktionen zum Einreichen und zum Aktualisieren des Status sind per IAM autorisiert, sodass sich Berechtigungen für Herausgeber und Freigebende trennen lassen. Nur freigegebene Einträge liefert die auffindbare Data Plane zurück.

Einträge verwenden das Feld recordType: MCP-Server tragen "MCP", A2A-basierte Agenten "AGENT". Die Protokollmetadaten liegen im Objekt descriptors unter mcpServer oder a2aAgentCard. AWS rät, Beschreibungen in nutzernaher Sprache zu verfassen, die eine Fähigkeit von benachbarten Einträgen abgrenzt, und die Suchqualität mit repräsentativen Anfragen zu prüfen. Der Beitrag gehe nicht davon aus, dass ein wachsender Katalog automatisch das Ranking verbessert.

Demo-Szenarien und Bedeutung

Drei Demos testen die Schleife. Die erste ist ein reiner MCP-Aufruf zum Bestellstatus. Die zweite verkettet MCP und A2A für Preise und Rabatte. Die dritte prüft einen rein semantischen Treffer bei mehrdeutiger Absicht, Rückgabe und Erstattung, wobei diese Begriffe im Namen des gefundenen A2A-Agenten nicht vorkommen.

Für Teams mit großen internen API-Katalogen soll der Ansatz überflüssig machen, den Orchestrator für jede neue Fähigkeit zu ändern und neu zu deployen. Laut AWS sind neue Integrationen nach Registrierung und Freigabe nutzbar. Der Beispielcode, darunter Deployment-Skript, Orchestrator, Hilfsmodule und Cleanup-Skript, ist im AWS-Beitrag verlinkt.