KI-Agenten erstellen mit Bedrock AgentCore: Was AWS übernimmt

Wer KI-Agenten erstellen und produktiv betreiben will, sollte Amazon Bedrock AgentCore dann in einem Pilotprojekt testen, wenn der Agent bereits funktioniert, die Infrastruktur darum herum aber allmählich zum zweiten Produkt wird. AWS führt aktuell 13 modulare Dienste und Funktionen auf. Sinnvoll sind diejenigen, die eine konkret benannte Betriebsaufgabe abnehmen. Die Verantwortung für das fachliche Verhalten des Agenten bleibt beim eigenen Team.

Am 30. Oktober 2026 mit der aktuellen AWS-Produktseite und Dokumentation abgeglichen. Die folgende Komponentenübersicht stammt aus der Entwicklerübersicht, auf die die AgentCore-Produktseite verweist. Welche Eigenentwicklungen die Komponenten ersetzen können, ist die technische Einordnung dieses Artikels.

KI-Agenten erstellen mit AWS: Was ist Bedrock AgentCore?

Mit AgentCore lassen sich ausgewählte Aufgaben beim produktiven Betrieb von Agenten an AWS übertragen. Ein Agent ist Software, die mithilfe eines Modells Aktionen auswählt, Tools aufruft und eine Aufgabe bearbeitet. Auch wenn diese Schleife lokal bereits Antworten liefert, bleibt viel Arbeit: Identitäten verwalten, Code ausführen, Zustand vorhalten, Zugriffe steuern und Fehler untersuchen.

Ein Konzertsaal veranschaulicht die Aufgabenteilung. Das Verhalten des Agenten ist die Aufführung. Runtime stellt die Bühne samt Infrastruktur bereit, Zugriffskontrollen regeln den Einlass, Memory bewahrt nützlichen Kontext auf und Observability hält fest, was passiert ist. Was die Aufführung erreichen soll und ob sie gelungen ist, entscheidet weiterhin das eigene Team.

AWS beschreibt AgentCore ausdrücklich mit „Any framework. Any model.“ Die Produktseite nennt LangChain, OpenAI Agents SDK, Claude Agent SDK, Strands SDK und eigene Frameworks. Das beschreibt den von AWS angegebenen Umfang der Plattform. Es ist keine Zusage, dass jede optionale Funktion dieselben Integrationen bietet oder eine Migration ohne Aufwand gelingt. AWS-Produktübersicht.

Auch bei der Verantwortung für die Agentenschleife gibt es unterschiedliche Wege. Mit Runtime wird eigener Agentencode bereitgestellt. Mit Harness wird der Agent per Konfiguration beschrieben und nutzt die von AWS verwaltete Schleife. Sie basiert auf Strands Agents, dem Open-Source-Agentenframework von AWS. Die Harness-Dokumentation grenzt diese Ansätze ausdrücklich voneinander ab. Wer als Entwicklungsverantwortlicher bereits funktionierenden Orchestrierungscode hat, sollte zuerst den Weg über Runtime prüfen.

Bedrock Agents oder AgentCore: Wo liegt der Unterschied?

Eine bestehende Anwendung auf Amazon Bedrock Agents muss nicht allein deshalb migriert werden, weil es AgentCore gibt. Laut AWS können bisherige Nutzer Bedrock Agents weiterverwenden. Anlass für die Prüfung von AgentCore ist eine konkrete Anforderung an Ausführung, Integration oder Betrieb. AWS-FAQ.

Die Unterscheidung ist inzwischen genauer als „verwaltete Agentenschleife oder Infrastruktur“. Auch AgentCore bietet mit Harness eine verwaltete Schleife. Entscheidend ist zunächst, ob der Orchestrierungscode in eigener Verantwortung bleiben soll. Daraus ergibt sich der passende Weg. Die Übersicht zur Architektur von KI-Agenten hilft bei dieser Entscheidung, damit die Wahl des Hostings nicht unbemerkt zum Umbau der gesamten Anwendung führt.

Die Komponenten von Bedrock AgentCore: Welche Arbeit nehmen sie ab?

Die Auswahl richtet sich nach der Arbeit, die das Team sonst selbst entwickeln und im Betrieb übernehmen müsste. AWS dokumentiert die Komponenten als modulare Funktionen, die zusammen oder unabhängig voneinander eingesetzt werden können. Die letzte Spalte zeigt, welche Verantwortung bei der Anwendung bleibt, auch wenn AWS den unterstützenden Dienst liefert.

Ein Supportassistent könnte sofort Runtime, Gateway und Identity benötigen. Memory kommt hinzu, sobald Kontext zu wiederkehrenden Nutzern nützlich wird. Payments ist überflüssig, wenn der Assistent nie den Zugang zu einer externen Ressource kauft. Registry wird interessant, wenn freigegebene Ressourcen innerhalb der Organisation schwer zu finden sind. Möglichst viele Komponenten einzusetzen, ist kein sinnvolles Einführungsziel.

Code Interpreter und Runtime erfüllen unterschiedliche Aufgaben. Runtime hostet den Agenten; Code Interpreter stellt eine Sandbox für Code bereit, den der Agent ausführt. Fehlt lediglich eine isolierte Codeausführung, hilft zunächst der Leitfaden zu Code-Sandboxes für KI-Agenten beim Vergleich. Dafür muss nicht gleich die Orchestrierung umziehen.

Welche Architekturentscheidungen bleiben beim eigenen Team?

Die entscheidende Grenze verläuft zwischen verwalteter Infrastruktur und fachlichen Befugnissen der Anwendung. In einem beispielhaften Supportablauf könnte der Agent eine Bestellung abrufen, ihren Status erklären und eine Aktion vorschlagen. AWS kann die Infrastruktur für Ausführung und Zugriff liefern. Die Anwendung muss aber feststellen, wem die Bestellung gehört und ob die vorgeschlagene Aktion erlaubt ist.

Bedrock AgentCore Runtime: Isolation klärt keine Sitzungszuordnung

Runtime kann die Ausführung isolieren, ohne zu wissen, welchem Kunden eine Sitzung gehört. AWS dokumentiert dedizierte microVM-Umgebungen für Sitzungen, die Rechenleistung, Arbeitsspeicher und Dateisystemressourcen voneinander trennen. Dieselbe Dokumentation stellt ausdrücklich klar: AgentCore erzwingt keine Zuordnung zwischen Sitzung und Nutzer. Diese Beziehung muss das Backend der aufrufenden Anwendung verwalten. Runtime-Sitzungen.

Beim Supportassistenten darf eine vom Browser übermittelte Sitzungskennung deshalb nicht als Nachweis gelten, dass die Sitzung dem Kunden gehört. Die Anfrage muss authentifiziert, die zulässige Sitzung im Backend ermittelt und der nachgelagerte Zugriff auf diesen Kunden begrenzt werden. Die Isolation der Infrastruktur und die Autorisierungsentscheidung der Anwendung sind getrennte Aufgaben.

Bedrock AgentCore Memory: Kontext gezielt aufbewahren

Memory übernimmt die Infrastruktur zur Kontextverwaltung. Welche Informationen dort hingehören, entscheidet das eigene Team. AWS unterstützt kurzfristigen Gesprächskontext und langfristige Informationen, die über Sitzungen hinweg erhalten bleiben. Memory-Dokumentation.

Sich zu merken, dass ein Kunde kurze Antworten bevorzugt, ist etwas anderes, als den verbindlichen Saldo einer Bestellung zu speichern. Für Geschäftsdaten muss die Anwendung die maßgebliche Quelle bleiben. Festzulegen ist, wie der Agent aktuelle Datensätze abruft, welche Informationen aus Gesprächen er behalten darf und was passiert, wenn eine gespeicherte Präferenz nicht mehr stimmt. Ein Speicherdienst nimmt diese Entscheidungen zur Datenmodellierung nicht ab.

Bedrock AgentCore und MCP: Gateway verbindet die Systeme

Gateway wird nützlich, wenn die Anbindung von Tools immer wieder dieselbe Entwicklungsarbeit verursacht. Das Model Context Protocol, kurz MCP, ist eine gemeinsame Schnittstelle, über die Tools für Agenten bereitgestellt werden. Gateway kann APIs und Funktionen von AWS Lambda als MCP-kompatible Tools verfügbar machen und vorhandene MCP-Server anbinden. Die aktuelle Dokumentation beschreibt außerdem das Routing zu anderen Agenten und Modellen. Gateway-Dokumentation.

Für einen Bestellassistenten empfiehlt sich zunächst eine eng begrenzte Operation, etwa die Abfrage des Lieferstatus, bevor ein allgemeines Tool für Datenbankabfragen freigegeben wird. Gateway kann den Aufruf weiterleiten. Die API legt weiterhin fest, was die Operation bedeutet, auf welche Datensätze sie zugreifen darf und ob eine Wiederholung auch eine Nebenwirkung erneut auslösen könnte.

Bedrock AgentCore Identity: Zugangsdaten brauchen fachliche Regeln

Identity verwaltet die handelnden Identitäten und ihre Zugangsdaten; Policy regelt die erlaubten Aktionen am Gateway. Identity stellt Workload-Identitäten und die Verwaltung von Zugangsdaten für AWS-Ressourcen und Dienste von Drittanbietern bereit, auch für Aktionen im Auftrag eines Nutzers. Identity-Dokumentation.

Policy prüft den Datenverkehr durch ein zugeordnetes AgentCore Gateway, bevor es den Zugriff auf Tools erlaubt. Diese Grenze ist entscheidend: Eine Gateway-Richtlinie gilt nicht automatisch für einen separaten direkten Netzwerkaufruf, den der Agent ausführen kann. Sensible Operationen müssen über den vorgesehenen Kontrollpunkt laufen; Umgehungswege sind einzuschränken. Policy-Dokumentation.

Eine Identität für den Kundensupport darf beispielsweise eine Bestellung lesen, aber keine Erstattung auslösen. Die Modellanweisungen sollten diesen Ablauf beschreiben. Die Tool- und Autorisierungsschichten müssen die Berechtigungen durchsetzen.

Bedrock AgentCore Observability: Traces zeigen den Ablauf, nicht den Erfolg

Observability hilft, das Verhalten nachzuvollziehen; Evaluations hilft bei seiner Bewertung. AgentCore bietet Ausführungsansichten und OpenTelemetry-kompatible Telemetrie – ein Standardformat für Traces und Metriken – sowie Dashboards auf Basis von Amazon CloudWatch. AWS unterscheidet zwischen integrierten Metriken und zusätzlichen Traces und fachlichen Metadaten, für deren Erfassung die Anwendung instrumentiert werden muss. Observability-Dokumentation.

Beim Supportassistenten sollte erfasst werden, ob die angeforderte Bestellabfrage abgeschlossen und eine Aktion genehmigt wurde. Ein technisch erfolgreicher Tool-Aufruf kann fachlich trotzdem die falsche Frage beantworten.

Evaluations bietet integrierte und benutzerdefinierte Bewertungen, darunter modellgestützte Beurteilungen. Dafür braucht es eigene repräsentative Testfälle und eine Prüfung von Fehlern mit erheblichen Folgen. Die Evaluations-Dokumentation nennt unterstützte Frameworks und Instrumentierungswege. Der gewählte Weg muss geprüft werden; die breite Kompatibilitätsaussage zur Plattform lässt sich nicht pauschal auf jede Funktion übertragen.

Welche Grenzen beeinflussen die Architektur?

Die Lebensdauer der Rechenressourcen ist von der Lebensdauer des benötigten Zustands zu trennen. Laut aktueller AWS-Dokumentation zum Lebenszyklus beträgt der standardmäßige Leerlauf-Timeout 15 Minuten, die maximale Laufzeit der microVM-Rechenumgebung 8 Stunden. Die Alternative Instances nutzt verwaltete Kapazität von Amazon Elastic Compute Cloud im eigenen Konto. Sie erlaubt eine konfigurierte Laufzeit von bis zu 14 Tagen, abhängig von den Einstellungen des Kapazitätsanbieters. Lebenszykluseinstellungen, Instances.

Eine logische Sitzung kann auf neu bereitgestellten Rechenressourcen fortgesetzt werden. Standardmäßig sind der Zustand im Arbeitsspeicher und der Zustand im lokalen Dateisystem an den Lebenszyklus der Rechenressourcen gebunden. Ein konfigurierter Sitzungsspeicher kann Dateisystemdaten über Stopps und Wiederaufnahmen hinweg erhalten. Was eine Unterbrechung überstehen muss, ist ausdrücklich einzuplanen. Sitzungslebenszyklus und Speicherung.

Vor der Festlegung auf einen Funktionsumfang ist die AWS-Matrix zur Verfügbarkeit nach Region zu prüfen. Für eine Anwendung, die an eine bestimmte Region gebunden ist, reicht „bei AWS verfügbar“ nicht aus.

Wann lohnt sich AWS AgentCore?

Ein Einsatz lohnt sich, wenn eine konkret benannte Betriebslücke die Bereitstellung blockiert und die passende verwaltete Komponente die Anforderungen erfüllt. Maßgeblich sind die Isolation der Ausführung, autorisierte Tool-Zugriffe, die Erhaltung von Zustand, die Möglichkeiten zur Fehlerdiagnose und der Aufwand, all das selbst zu betreiben.

Für Entwickler bietet sich ein Pilotprojekt an, wenn die Agentenlogik bereits funktioniert, aber Hosting oder Tool-Anbindung fehlen. Die bestehende Schleife auf Runtime weiterzuverwenden, hält den Versuch überschaubarer, als gleichzeitig das Framework und die Bereitstellungsplattform zu wechseln.

Für Betriebsverantwortliche wird AgentCore interessanter, wenn jeder Agent dieselbe Verwaltung von Zugangsdaten, Durchsetzung von Zugriffsregeln und Untersuchung von Störungen benötigt. Dafür eignet sich ein Ablauf, an dem diese Aufgaben demonstriert werden können – einschließlich eines Fehlers, der sich diagnostizieren lassen muss.

Für technische Entscheider zählt, welche wiederkehrenden Aufgaben wegfallen und welcher neue Integrationsaufwand bleibt. Für AWS-Konfiguration, Berechtigungskonzept, Anwendungsverhalten und Bereitschaftsdienst braucht es weiterhin klar benannte Verantwortliche.

Abwarten ist sinnvoll, wenn der vorhandene Stack die nötigen Kontrollen bereits bietet und kein konkretes Problem zu lösen ist. Eine Migration bräuchte dann einen anderen Anlass, etwa eine Funktion, die der eigene Stack nicht bereitstellen kann. Kein Handlungsbedarf besteht bei einem festen Ablauf bekannter Operationen, für den kein Agent die jeweils nächste Aktion auswählen muss.

Wenn die Kosten den Ausschlag geben, helfen die AWS-Preise für AgentCore zusammen mit dem Preisleitfaden zu Amazon Bedrock auf dieser Website.

Das erste Pilotprojekt mit der AWS-CLI

Ausgangspunkt ist die codebasierte AWS-Vorlage, ergänzt um eine repräsentative fachliche Operation. Dieser Ablauf folgt dem aktuellen Runtime-Schnellstart und dem vollständigen CLI-Leitfaden. Er ist aus der Dokumentation abgeleitet; ein Deployment wurde für diesen Artikel nicht getestet.

Der vollständige Leitfaden setzt Node.js 20.12 oder neuer, npm, Python 3.10 oder neuer, den Python-Abhängigkeitsmanager uv, konfigurierte AWS-Zugangsdaten, Berechtigungen für das Deployment und Modellzugriff voraus. Die Vorlage verwendet CodeZip, daher ist Docker nicht erforderlich.

1. 1

   Installieren und Projekt anlegen

   Dafür ein AWS-Entwicklungskonto oder eine Entwicklungsumgebung verwenden.

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   Die Vorlage enthält eine Runtime mit dem Namen agent und eine AgentCore-Memory-Ressource. Beide sollten in der erzeugten Konfiguration geprüft werden.

2. 2

   Lokal testen

   cd MyProject
   agentcore dev --mode browser

   Den Agenten im lokalen Inspector ausprobieren. Anschließend den Server beenden, bevor es im selben Terminal weitergeht.

3. 3

   Build erstellen, bereitstellen und aufrufen

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   Das Deployment stellt AWS-Ressourcen über das AWS Cloud Development Kit, kurz CDK, bereit.

4. 4

   Prüfen und anschließend aufräumen

   agentcore logs runtime
   agentcore traces runtime list

   Im Verzeichnis dieses Pilotprojekts entfernen die folgenden Befehle dessen Ressourcen und bauen den bereitgestellten Stack ab:

   agentcore remove all --yes
   agentcore deploy --yes

Bevor produktive Anfragen hinzukommen, wird die Begrüßung durch eine klar begrenzte Aufgabe ersetzt, etwa das Abrufen einer Testbestellung. Die empfohlenen Abnahmekriterien beziehen sich auf die Anwendung: Sie liefert die richtigen Daten, weist unberechtigte Zugriffe ab, macht fehlgeschlagene Tool-Aufrufe im Trace sichtbar und lässt nachvollziehen, wie die Wiederaufnahme nach einer Unterbrechung funktioniert. Das sind Entscheidungskriterien für das Pilotprojekt, keine Leistungszusagen von AWS.

Wo die Erwartungen zu hoch sind

Eine verwaltete Ausführungsumgebung belegt noch nicht, dass ein Agent fachlich richtig entscheidet. Hosting, Tracing, Bewertung und die Durchsetzung von Richtlinien lösen unterschiedliche Probleme. Eine sinnvolle Aufgabe auszuwählen, zulässige Aktionen festzulegen und Fehler zu untersuchen, bleibt in eigener Verantwortung.

Auch „Any framework“ bedeutet nicht, dass Integrationsarbeit entfällt. Die Flexibilität der Plattform entbindet nicht davon, Abhängigkeiten, Authentifizierung, Instrumentierung und die Schnittstellenverträge jedes eingesetzten Dienstes zu prüfen.

Ebenso wenig beweist der Einsatz sämtlicher Komponenten, dass eine Anwendung produktionsreif ist. Ein Supportassistent mit rein lesendem Zugriff wird nicht besser, weil er Zahlungsbefugnisse oder einen unnötigen Browser erhält. Zusätzliche Funktionen sind dann sinnvoll, wenn eine konkrete Aufgabe sie verlangt. Die damit erweiterten Befugnisse müssen Teil der Prüfung sein.

Der nächste konkrete Schritt

Eine bestehende Agentenaufgabe auswählen und festhalten, welche Betriebsaufgabe sie verzögert. Im Pilotprojekt nur die AgentCore-Funktionen einsetzen, die diesen Engpass beseitigen. Anschließend Bereitstellung, Fehlerbehandlung und den verbleibenden Verantwortungsaufwand mit dem vorhandenen Stack vergleichen. Der Ausbau folgt, wenn die Ergebnisse dafür sprechen.

Praktische Leitfäden zur Entwicklung und zum Betrieb von KI-Systemen gibt es im Newsletter.