AWS nimmt den Agenten-Unterbau ab, der Haken bleibt

AWS hat zwei Dinge ausgeliefert, die ständig in einen Topf geworfen werden: das Agent Toolkit, das einem KI-Coding-Agenten 300 Services und 15.000 API-Aktionen in die Hand gibt und Bedrock AgentCore, die Betriebsplattform mit serverloser Laufzeit für Agenten in Produktion. Beide nehmen Wochen bis Monate an Plumbing-Arbeit ab. Der Preis steht nicht auf der Rechnung, er steht in der Architektur.

Das Wichtigste in Kürze

• Zwei Produkte, ein Missverständnis: Das Agent Toolkit verdrahtet deinen Entwickler-Agenten mit AWS, AgentCore betreibt die Agenten danach serverlos. Wer das verwechselt, evaluiert das falsche Werkzeug.
• Der Unterbau ist das eigentliche Angebot: Session-Isolation, Memory, Identity und Observability baut sonst jedes Team selbst. AgentCore bündelt das in modulare Bausteine und nimmt damit den langweiligsten Teil ab.
• Offen oben, gebunden unten: Frameworks wie LangGraph oder CrewAI bleiben portabel. Die Betriebsschicht darunter ist AWS. Genau dort entsteht die Bindung, die man später spürt.

Verwandt:Cursor Cloud-Agents: Coden, auch wenn der Laptop zu ist  /  Reserved Instances: Die Coverage-Quote, die nichts beweist

Zwei Werkzeuge, die ständig verwechselt werden

Die meiste Verwirrung in der ersten Architektur-Runde entsteht, weil zwei Releases denselben Vornamen tragen. Das eine heißt Agent Toolkit for AWS, das andere Amazon Bedrock AgentCore. Sie lösen unterschiedliche Probleme und gehören in verschiedene Phasen.

Was ist das Agent Toolkit for AWS? Ein Bündel aus einem MCP-Server, kuratierten Skills und Plugins, das KI-Coding-Agenten wie Claude Code, Cursor oder Codex einen sicheren, auditierbaren Zugang zu AWS gibt. Der MCP-Server deckt über 300 Services und mehr als 15.000 API-Aktionen ab, dazu kommen sandboxed ausgeführte Skripte und Echtzeit-Zugriff auf die aktuelle Doku.

Das Toolkit hilft also beim Bauen. Es gibt dem Agenten, der deinen Code schreibt, Hände für CloudWatch-Logs, CloudFormation-Status und Troubleshooting-Prozeduren. Bezahlt wird nichts extra, du trägst nur die AWS-Ressourcen, die der Agent tatsächlich anfasst.

AgentCore beginnt da, wo das Toolkit aufhört: bei der Laufzeit für den Betrieb. Wenn der Agent fertig gebaut ist und Nutzer-Sessions bedienen soll, läuft er hier, serverlos, mit isolierten Sessions und persistentem Gedächtnis. Beide Produkte zusammen ergeben eine Kette vom ersten Prompt bis zum Produktions-Traffic. Getrennt evaluiert ergeben sie Sinn. Vermischt führen sie zu einer Anforderungsliste, die nirgends sauber passt.

Was der Unterbau dem Entwickler abnimmt

Der ehrlichste Teil des Angebots ist der unsichtbare. Jedes Team, das einen Agenten in Produktion gebracht hat, kennt die Liste der Dinge, die niemand bauen will und trotzdem jeder bauen muss. AgentCore zerlegt genau diese Liste in modulare Bausteine. Die sieben, die den Alltag am stärksten prägen:

• Runtime: serverlose Umgebung mit niedriger Latenz und Session-Isolation, offen für jedes Framework.
• Memory: Kurzzeit-Kontext pro Session und langfristige Erkenntnisse über semantische Extraktion.
• Identity: sichere Zugriffe des Agenten auf AWS und auf Drittdienste wie GitHub, Salesforce oder Slack.
• Gateway: verwandelt bestehende APIs und Lambda-Funktionen in Werkzeuge, die der Agent über MCP nutzen kann.
• Observability: Schritt-für-Schritt-Sicht auf die Ausführung mit OpenTelemetry-Anbindung.
• Browser: verwaltete Browser-Instanzen für Web-Automatisierung im großen Maßstab.
• Code Interpreter: isolierte Umgebung für Code, den der Agent selbst erzeugt.

Wer das schon einmal eigenhändig gestellt hat, sieht den Wert sofort. Session-Management, Identitäts-Brokering und ein Memory-Layer, der nicht bei jedem Deploy bricht, kosten ein kleines Team schnell Wochen bis Monate. Diese Zeit fließt selten in das Produkt, fast immer in Klempnerei. Das Playbook für genau diese Klempnerei haben wir einmal zu oft selbst geschrieben.

Ein Beispiel macht den Unterschied greifbar. Das Gateway nimmt eine bestehende Lambda-Funktion oder eine interne REST-API und macht daraus ein Werkzeug, das der Agent über das Model Context Protocol aufruft. Vorher bedeutete das: für jede Funktion einen Adapter, eine Schema-Beschreibung und eine Auth-Schicht von Hand bauen. Jetzt ist es eine Registrierung. Das klingt nach einer Kleinigkeit und summiert sich über ein Dutzend Werkzeuge zu genau der Arbeit, die im Sprint-Planning niemand sehen will. Ähnlich greift Identity: Statt Schlüssel für GitHub oder Salesforce in Umgebungsvariablen zu parken, brokert die Komponente den Zugriff zur Laufzeit. Das ist weniger Code und weniger Angriffsfläche.

Wo die Rechnung steht: Bindung statt Gebühr

Der zweite Blick lohnt sich. AWS verkauft Offenheit und das stimmt sogar. AgentCore unterstützt CrewAI, LangGraph, LlamaIndex, Strands und eigene Frameworks. Dein Agenten-Code ist damit nicht eingemauert. Was du portieren könntest, ist die Logik.

Was du nicht portierst, ist die Betriebsschicht. Runtime, Gateway, Identity und Memory sind AWS-eigen. Sobald dein Agent darauf produktiv läuft, hängt die Art, wie er deployt, authentifiziert und beobachtet wird, an diesem Stack. Die Bindung sitzt eine Ebene tiefer als das Framework, genau in dem Teil, den du dir gerade hast abnehmen lassen.

Das ist kein Argument gegen AWS. Es ist das übliche Geschäft jeder Managed-Plattform. Die Frage ist nur, ob man die Bindung bewusst kauft oder sie als Nebenwirkung eines schnellen Prototyps einsammelt. Der Unterschied zwischen beidem ist ungefähr ein Audit weit.

Wann sich der Sprung lohnt

Für die Mehrheit der Teams, die heute einen ersten produktiven Agenten planen, ist der Tausch fair. Wer noch keine eigene Memory- und Identity-Schicht betreibt, gewinnt mehr Zeit, als er an Optionalität verliert. Der Vorsprung zählt, solange der Use-Case noch nicht bewiesen ist.

Anders sieht es aus, wenn Multi-Cloud bereits Vorgabe ist oder Datenresidenz und Souveränität hart reguliert sind. Dann wird die Betriebsschicht zur strategischen Entscheidung, die man nicht nebenbei trifft. In diesem Fall lohnt sich der Vergleich mit einem framework-eigenen Self-Hosting, bevor der erste Produktions-Agent auf AgentCore steht.

Praktisch heißt das: Prototyp auf dem Managed-Stack, Architektur-Entscheidung vor dem Produktiv-Rollout. Wer das Toolkit zum Bauen nutzt und die Laufzeit erst nach einer nüchternen Lock-in-Rechnung festlegt, bekommt das Beste aus beidem. Wer die Reihenfolge umdreht, lässt den Prototyp die Architektur diktieren. Das geht eine Weile gut und wird genau dann teuer, wenn man am wenigsten Zeit für eine Migration hat.

Häufige Fragen

Bildquelle: KI-generiert (Juli 2026)