AWS beschreibt den Migrationspfad von AgentCore, während Kunden agentische Workloads in die Produktion überführen

AWS skizziert, wie Teams experimentelle Agenten mit Amazon Bedrock AgentCore in die Produktion überführen können, und nutzt dafür zwei Machine-Learning-Blogbeiträge, um sowohl einen gestuften Migrationspfad als auch einen bereits produktiv laufenden Enterprise-Workflow zu zeigen.

Der erste Leitfaden migriert einen LangGraph-Kundensupport-Agenten auf AgentCore Runtime, Gateway und Memory, bevor optional die Planungs-Schleife mit Strands Agents neu aufgebaut wird. Der zweite beschreibt eine automatisierte Architektur-Dokumentations-Pipeline für einen globalen Interdealer-Broker, die .NET-Code analysiert, Diagramme erzeugt und durchsuchbare Dokumentation über Amazon Bedrock Knowledge Bases und AWS CodePipeline veröffentlicht.

Zusammen betrachtet präsentieren die Beiträge AgentCore weniger als ein einzelnes Agenten-Framework denn als operative Schicht um Agenten, die mit unterschiedlichen Frameworks und Modellen gebaut wurden. Die Botschaft richtet sich an Teams, die funktionierende Prototypen haben, aber weiterhin für Session-Isolation, dauerhaften Zustand, Tool-Authentifizierung, Infrastruktur-Patching, Beobachtbarkeit und Skalierung der Bereitstellung verantwortlich sind.

AWS’ gestufter Weg vom Prototyp zum gehosteten Agenten

Der Migrationsleitfaden beginnt mit einem bestehenden LangGraph-Agenten, der Kundennachrichten klassifiziert, verärgerte Kunden eskaliert und Tools verwendet, um Bestellungen nachzuschlagen, Rücksendungen zu bearbeiten und häufig gestellte Fragen zu durchsuchen. Seine Modellaufrufe laufen bereits über Amazon Bedrock, doch AWS betont, dass dies die umliegenden Produktionsaufgaben nicht löst.

In der ersten Stufe bleibt der Graph des Agenten unverändert. AgentCore Runtime hostet den Prozess, Gateway übernimmt ausgewählte Tool-Verbindungen und Memory speichert den Gesprächszustand über Turns, Prozesse und Tage hinweg. AWS sagt, dass diese Stufe mehrere operative Aufgaben entfernt, ohne zu ändern, wie der Agent entscheidet, was zu tun ist.

Eine zweite Stufe ersetzt die selbst geschriebene Routing-Schleife durch modellgesteuerte Planung mithilfe von Strands Agents. Teams können nach der ersten Stufe aufhören, wenn sie verwaltetes Hosting, Tools und Zustand beibehalten möchten und dabei ihre bestehende Orchestrierung bewahren wollen. AWS beschreibt außerdem eine dritte AgentCore-Harness-Stufe, aber der Beitrag dokumentiert diese Stufe, statt sie im Beispiel umzusetzen.

Der Unterschied ist für Entwickler wichtig. Runtime ersetzt nicht automatisch die Schlussfolgerungslogik einer Anwendung. Es stellt die Umgebung bereit, in der diese Logik ausgeführt wird. Die Wahl eines autonomeren Planungsmodells ist eine separate architektonische Entscheidung, und AWS stellt den gestuften Ansatz als Möglichkeit dar, diese Änderungen voneinander zu trennen.

Die operativen Aufgaben, auf die AgentCore abzielt

AWS ordnet die AgentCore-Dienste den Aufgaben zu, die sich typischerweise um Produktionsagenten herum ansammeln. Runtime übernimmt verwaltete Rechenleistung, Session-Isolation und Skalierung auf AWS-Infrastruktur. Teams können die Laufzeit mit einer Virtual Private Cloud verbinden, obwohl AWS sagt, dass Netzwerkdesign, Edge-Schutz, Autorisierung, IAM-Richtlinien, Web-Application-Firewall-Regeln und Secret-Rotation in der Verantwortung des Kunden bleiben.

Gateway verwaltet den Zugriff auf Tools und ruft Ziele wie AWS Lambda unter einer eigenen Ausführungsrolle auf. Das Beispiel im Leitfaden signiert Aufrufe mit AWS-IAM-Anmeldedaten statt mit Tokens von Drittanbietern. AgentCore umfasst außerdem eine Identitätsfunktion, um Anmeldedaten zu vermitteln und OAuth-Zugriffstokens zu erneuern, wenn ein Agent im Namen eines Benutzers eine API aufrufen muss, auch wenn diese Funktion im Leitfaden nicht verwendet wird.

Memory adressiert die Begrenzung, Gesprächszustand in einem prozesslokalen Dictionary zu halten. Dieser Ansatz kann fehlschlagen, wenn ein Prozess neu startet oder wenn mehrere Replikate auf dieselbe Unterhaltung zugreifen müssen. AWS sagt, dass sein Beispiel den Checkpoint-Speicher in AgentCore Memory verlagert, damit Zustände über Turns, Prozesse und Tage hinweg erhalten bleiben können.

Beobachtbarkeit ist ein weiterer Bereich, den AWS hervorhebt. Logs, Metriken und Traces von Runtime werden an Amazon CloudWatch gesendet, ohne dass der Kunde die zugrunde liegende Pipeline konfigurieren muss. Allerdings deutet der Leitfaden nicht an, dass AgentCore alle Betriebsaufgaben eliminiert. Die Abhängigkeitsverwaltung bleibt vor der späteren Harness-Stufe in der Verantwortung des Kunden, und AWS-verwaltete Infrastruktur beseitigt nicht die Notwendigkeit von Sicherheitsentscheidungen auf Anwendungsebene.

Ein Produktionsbeispiel jenseits des Kundensupports

Der zweite AWS-Beitrag wendet AgentCore auf eine andere Art von Workload an: Architektur-Dokumentation. Laut AWS betreibt ein globaler Interdealer-Broker das System seit dem ersten Quartal 2026 produktiv, um die Dokumentation für seine elektronische Handelsplattform zu pflegen. Der Kunde wird im Beitrag nicht genannt, sodass sich die Adoptionsbehauptung anhand der vorliegenden Belege nicht unabhängig überprüfen lässt.

Der Workflow beginnt, wenn Codeänderungen in ein AWS-CodeCommit-Repository gelangen. AWS CodeBuild holt den .NET-Code ab, paketiert ihn und ruft einen auf AgentCore gehosteten Strands-Agenten auf. Der Agent konzentriert sich auf Produktionscode und schließt Tests, Build-Artefakte und generierte Dateien aus; anschließend analysiert er Interfaces, abstrakte Klassen, Implementierungen und Abhängigkeiten.

Der Agent erzeugt Mermaid-Diagramm-Syntax, validiert die Diagramme, konvertiert sie in SVG und kann bei Validierungsfehlern iterativ nachbessern. Die resultierenden SVG-Dateien, die Mermaid-Quelldateien und Metadaten werden in Amazon S3 gespeichert. Amazon Bedrock Knowledge Bases nimmt diese Artefakte anschließend auf und verwendet Amazon Titan Text Embeddings v2, um semantische Suche und retrieval-augmented Generation zu unterstützen.

Entwickler und Stakeholder können die entstehende Dokumentation in natürlicher Sprache abfragen, auch nach Serviceabläufen oder bestimmten Klassen. AWS beschreibt die iterative Verfeinerung und Selbstkorrektur als Zuverlässigkeitsvorteil gegenüber einer einmaligen Generierung, doch bleibt dies eine AWS-Darstellung der Lösung und kein unabhängig berichteter Benchmark.

Belege, Behauptungen und Grenzen

Beide Quellen sind von AWS verfasste technische Beiträge, daher werden Produktfähigkeiten, Architekturskizzen und Implementierungsschritte durch den Anbieter kontrolliert. Sie sind nützlich, um zu verstehen, wie AWS den Einsatz von AgentCore erwartet, belegen aber keine unabhängigen Leistungsverglichen gegenüber anderen Agentenplattformen.

Der Migrationsbeitrag liefert ungewöhnlich konkrete Implementierungsdetails. AWS berichtet, dass in seinem fest verdrahteten Beispiel 45 Zeilen im Agenten geändert, 22 Zeilen unterstützender Code hinzugefügt und 85 Zeilen unverändert gelassen wurden. Diese Zahlen beschreiben genau dieses Beispiel; sie sollten nicht als allgemeine Migrationsschätzung für Produktionssysteme mit anderen Zustandsmodellen, Tools, Sicherheitskontrollen oder Netzwerkarchitekturen verstanden werden.

Der Beitrag zur Architektur-Dokumentation liefert eine Behauptung über den Produktionseinsatz, aber keinen Kundennamen, kein Workload-Volumen, keine Genauigkeitsmessung, keine Kostendaten und keine Fehlerrate. Er quantifiziert auch nicht, wie viel manuelle Dokumentationsarbeit entfiel. Käufer, die den Ansatz bewerten, werden Belege aus ihren eigenen Repositories und Deployment-Pipelines benötigen, bevor sie ähnliche Ergebnisse annehmen.

Auch die technischen Voraussetzungen sind relevant. Der Leitfaden erfordert ein AWS-Konto mit Zugriff auf Amazon-Bedrock-Modelle, Python 3.12, AWS-CLI-Anmeldedaten, die in der Lage sind, AgentCore-, Lambda-, Amazon-S3- und IAM-Ressourcen zu erstellen, sowie aktivierte CloudWatch Transaction Search, um Traces anzuzeigen. Diese Anforderungen verankern die Migration klar innerhalb von AWS’ Grenzen für Sicherheit, Berechtigungen und regionale Modellverfügbarkeit.

Was AgentCore für Entwickler und Unternehmen bedeutet

Für Engineering-Teams ist der klarste Nutzen die Trennung von Verantwortlichkeiten. Ein Team kann einen bestehenden LangGraph-Workflow beibehalten und gleichzeitig Hosting, Tool-Vermittlung und dauerhaften Zustand an verwaltete Dienste auslagern. Das verringert den Umfang einer Infrastrukturmigration und ermöglicht es dem Team, das Verhalten gegen eine aufgezeichnete Baseline zu vergleichen.

Für Teams, die ohnehin einen Agenten neu schreiben, bietet die Strands-basierte Planungsstufe einen anderen Kompromiss. Modellgesteuerte Planung kann selbst geschriebene Routing-Logik reduzieren, aber auch zusätzliche Variabilität bei der Tool-Auswahl und Ausführung einführen. Der AWS-Leitfaden macht den wichtigen Punkt, dass der Wechsel zu Runtime diesen Kompromiss nicht erzwingt.

Unternehmenskunden sollten sich auf die Grenzen konzentrieren, die AgentCore bestehen lässt. IAM, VPC-Konfiguration, WAF-Regeln, Secrets und Autorisierungsrichtlinien müssen weiterhin entworfen und verwaltet werden. Amazon Bedrock Guardrails kann schädliche Inhalte filtern, die Verankerung an Quelldokumenten prüfen und Prompt-Injection-Versuche blockieren, so AWS, aber diese Kontrollen ersetzen weder Anwendungstests noch workflowspezifische Genehmigungsregeln.

Das Beispiel der Architektur-Dokumentation zeigt auch, wo AgentCore operativ passen kann: nicht nur im dialogorientierten Support, sondern auch in ereignisgesteuerten Pipelines, die Code prüfen, Tools aufrufen, Artefakte erzeugen, Ausgaben validieren und sie für die Suche veröffentlichen. Das erweitert die relevante Käufergruppe auf Plattform-Engineering, Entwicklerproduktivität, Compliance und Architektur-Teams.

Worauf man als Nächstes achten sollte

Die nächsten Signale werden unabhängige Messungen der Betriebskosten, Latenz, Skalierungsverhalten und Fehlerbehandlung von AgentCore über größere Workloads hinweg sein. Das AWS-Beispiel etabliert ein Migrationsmuster, keinen universellen Produktions-Benchmark.

Teams sollten auch beobachten, wie AgentCore mit Modellanbietern außerhalb von AWS, externen Identitätssystemen und vorhandenen Observability-Stacks integriert wird. Der Leitfaden sagt, die Plattform unterstütze jedes Framework und jedes Modell, doch der demonstrierte Weg stützt sich stark auf AWS-Dienste, IAM, Lambda, CloudWatch, S3 und Bedrock.

Schließlich wird der Nachweis der Adoption wichtig sein. Die nicht namentlich genannte Broker-Bereitstellung ist ein nützlicher Referenzpunkt, aber mehr identifizierbare Kundenfallstudien, Workload-Metriken und Sicherheitsbewertungen würden es erleichtern zu beurteilen, ob AgentCore den Betriebsaufwand reduziert oder ihn vor allem innerhalb der AWS-Plattform verlagert.

Creati.ai-Perspektive

AWS liefert ein glaubwürdiges Infrastrukturargument: Einen Agenten produktionsreif zu machen, bedeutet weit mehr als nur ein Modell auszuwählen oder eine Tool-Schleife zu schreiben. Die gestufte Migration ist besonders praktisch, weil sie Hosting- und State-Management-Änderungen von der deutlich folgenschwereren Entscheidung trennt, ein Modell die Planung steuern zu lassen.

Die Belege stammen jedoch fast ausschließlich von AWS selbst. Die Bedeutung von AgentCore wird davon abhängen, ob Teams geringeren Betriebsaufwand nachweisen können, ohne Kontrolle über Identität, Netzwerke, Zuverlässigkeit und Kosten abzugeben. Vorläufig zeigen die Beiträge ein klares AWS-Bereitstellungsmuster und einen frühen Produktionsverweis, aber keinen eindeutigen Marktvorteil.