6 Min. Lesezeit
Amazon Bedrock AgentCore ist Ende April 2026 generell verfügbar geworden. Das CLI-basierte Tooling bringt CDK-Integration, A/B-Testing für Agenten-Versionen und eine Governance-Schicht für die Produktionseinführung von KI-Agenten auf AWS. Für Enterprise-Teams die Agentic-AI-Workloads aus der Evaluationsphase in produktionsreife Deployments überführen wollen, ist das die erste nennenswerte Infrastrukturschicht auf AWS-Seite.
Das Wichtigste in Kürze
- CDK-Integration für Infrastructure-as-Code: AgentCore-Agenten werden über AWS CDK definiert, versioniert und deployed. Das ermöglicht dieselben GitOps-Workflows die für Lambda, ECS und andere AWS-Services etabliert sind – Agenten als reproduzierbare, auditierbare Artefakte.
- A/B-Testing zwischen Agenten-Versionen: Traffic-Splitting zwischen Agenten-Varianten ermöglicht kontrollierte Rollouts. Statt „neu deployed = alle Nutzer betroffen“ kann Traffic schrittweise umgeleitet werden – mit Rollback-Option wenn Metriken abweichen.
- Observability-Layer integriert: AgentCore schreibt Execution-Traces, Latenz- und Error-Metriken direkt in CloudWatch. Für Compliance-Anforderungen relevante Audit-Logs werden automatisch geschrieben.
- Modell-agnostisch auf AWS-Ebene: AgentCore funktioniert mit allen Bedrock-Modellen – Anthropic Claude, Amazon Titan, Llama-Varianten. Der Wechsel des zugrunde liegenden Modells erfordert keine Änderung der Agent-Architektur.
VerwandtAmazon S3 Files in GA: NFS-Mount für ML-Pipelines und EKS / Kubernetes 1.36 Haru: cgroup-v1 entfernt, DRA stable
Was AgentCore konkret löst
Was ist Amazon Bedrock AgentCore? AgentCore ist ein Managed-Service von AWS der den Betrieb von KI-Agenten in Produktionsumgebungen standardisiert. Es kombiniert eine Runtime-Infrastruktur für Agenten-Execution, eine CDK-basierte Deployment-Pipeline und einen Observability-Layer – vergleichbar mit dem was AWS App Runner für containerisierte Anwendungen macht, aber spezialisiert auf die Besonderheiten von Agentic-AI-Workloads.
Das Grundproblem das AgentCore adressiert: KI-Agenten sind keine klassischen Microservices. Sie haben nicht-deterministische Ausführungspfade, variablen Tool-Aufruf-Kontext und Zustandsprobleme die bei strikter Stateless-Architektur entstehen. Standard-Deployment-Tooling für containerisierte Applikationen funktioniert für Agenten nur mit erheblichem Custom-Code.
AgentCore bündelt die häufigsten Workarounds: Session-State-Management, Retry-Logik für Tool-Calls, strukturiertes Logging von Reasoning-Steps, Integration mit AWS IAM für Tool-Berechtigungen. Was Teams bisher selbst implementiert haben, kommt jetzt als Managed-Layer.
CDK-Integration: Agenten als Code-Artefakt
Die CDK-Integration ist der relevanteste Teil für Enterprise-Teams. Ein AgentCore-Agent wird als CDK-Construct definiert. Das Construct beschreibt Modell-Auswahl, Tool-Konfiguration, Session-Policy und Permissions – alles als Code, alles versioniert, alles in denselben CI/CD-Pipelines deployt wie andere Infrastructure-as-Code.
In der Praxis bedeutet das: ein Agenten-Deployment ist ein Pull-Request mit Review, Test und Approval – kein manueller Console-Klick. Das ist für Enterprise-Compliance-Anforderungen (Change-Management, Audit-Trail) der entscheidende Schritt von Proof-of-Concept zu produktionsreifem Deployment.
Deployment-Workflow mit AgentCore CDK
- Agent-Definition als CDK-Construct (Modell, Tools, Session-Policy)
- Deployment via cdk deploy – identischer Workflow wie Lambda oder ECS
- A/B-Test-Konfiguration: Traffic-Split zwischen altem und neuem Agenten
- Monitoring via CloudWatch-Dashboard (Latenz, Error-Rate, Tool-Call-Frequenz)
- Rollback via CDK-Rollback oder Traffic-Split auf 0% neue Version
„Für Enterprise-Teams die Agentic-AI-Workloads aus der Evaluationsphase in produktionsreife Deployments überführen wollen, ist das die erste nennenswerte Infrastrukturschicht auf AWS-Seite.“
A/B-Testing für Agenten – was das in der Praxis bedeutet
A/B-Testing für KI-Agenten ist komplexer als für klassische Webanwendungen. Eine neue Agenten-Version hat möglicherweise andere Reasoning-Pfade, ruft Tools häufiger oder seltener auf und produziert andere Output-Strukturen. Ob das besser oder schlechter ist, lässt sich nicht mit reinen Latenzmessungen beantworten.
AgentCore integriert ein Evaluation-Framework das neben technischen Metriken auch Output-Quality-Scores trackt. AWS hat dafür LLM-as-Judge-Mechanismen eingebaut – ein Evaluator-Modell bewertet automatisch ob die Agenten-Antworten die definierten Qualitätskriterien erfüllen. Für Teams die A/B-Tests zwischen Modell-Versionen oder Prompt-Varianten machen, ist das die fehlende Feedback-Schleife.
Die Einschränkung: LLM-as-Judge ist kein perfekter Evaluator. Für Domänen mit sehr spezifischen Fachlichkeits-Anforderungen (medizinische Dokumentation, rechtliche Analysen) müssen Teams eigene Evaluationskriterien definieren und kalibrieren. AgentCore stellt den Mechanismus bereit – die Qualitätsdefinition bleibt beim Team.
AgentCore löst
- CDK-basiertes Agenten-Deployment als Code
- A/B-Testing mit Traffic-Split und Evaluation
- Session-State-Management out-of-the-box
- CloudWatch-Integration für Observability
- IAM-basierte Tool-Berechtigungen
Weiterhin manuell
- Prompt-Engineering und Agenten-Design
- Domain-spezifische Evaluationskriterien
- Multi-Cloud-Agenten-Orchestrierung
- Cross-Provider Tool-Registries
- DSGVO-spezifische Datenverarbeitungs-Compliance
Für DACH-Enterprise-Teams ist AgentCore der nächste Schritt nach dem Evaluation-Stadium. Wer bisher mit Bedrock-Agenten experimentiert hat und jetzt produktive Workloads plant, bekommt mit AgentCore die Deployment-Infrastruktur die sonst selbst gebaut werden musste. Der Reifepunkt für Agentic AI in AWS-Enterprise-Umgebungen verschiebt sich damit deutlich nach vorn.
Quellen: AWS-Dokumentation Bedrock AgentCore GA (April 2026), AWS Blog re:Invent 2025 Announcements.
Häufige Fragen
Ist AgentCore nur für Bedrock-Modelle oder auch für externe Modelle nutzbar?
AgentCore ist primär auf Bedrock-Modelle ausgerichtet. Custom-Modelle die über SageMaker bereitgestellt werden, können über einen Bedrock-Custom-Model-Layer integriert werden. Externe Modelle außerhalb AWS – GPT-4o, Gemini, eigengehostete Open-Source-Modelle – sind nicht direkt integrierbar. Für Multi-Provider-Agenten-Orchestrierung sind aktuell andere Frameworks wie LangChain oder LlamaIndex flexibler.
Was kostet AgentCore im Vergleich zu selbst-gebauter Agent-Infrastruktur?
AgentCore berechnet einen Aufschlag auf die Modell-Kosten für die Managed-Runtime. Konkrete Preistabellen sind in der AWS-Pricing-Dokumentation verfügbar. Der Vergleich mit selbst-gebauter Infrastruktur hängt stark vom Entwicklungsaufwand ab: Wer Session-Management, Observability und Deployment-Pipelines selbst entwickelt, investiert typischerweise mehrere Sprint-Zyklen. AgentCore amortisiert sich schnell bei Teams die keine dedizierte ML-Ops-Kapazität haben.
Wie verhält sich AgentCore bei DSGVO-Anforderungen für EU-Daten?
AgentCore läuft in eu-central-1 (Frankfurt) und eu-west-1 (Irland). Daten verlassen bei korrekt konfigurierter Region-Pinning die EU nicht. Execution-Traces und Session-Daten werden in CloudWatch in derselben Region gespeichert. Für Branchen mit besonderen Anforderungen (Finanzdienstleistungen, Gesundheit) empfiehlt sich ein Datenschutz-Review der spezifischen Agenten-Anwendungsfälle da Agenten-Interaktionsdaten als personenbezogene Daten eingestuft werden können.
Kann AgentCore mit Multi-Agenten-Architekturen umgehen?
Ja. AgentCore unterstützt Supervisor-Agent-zu-Worker-Agent-Kommunikation. Ein Orchestrator-Agent kann Sub-Agenten über definierte Schnittstellen aufrufen. Jeder Agenten-Schritt wird separat geloggt und trackt – was für Debugging von Multi-Agenten-Workflows erheblich hilft. Die Komplexität von Multi-Agenten-Koordination steigt aber weiterhin exponentiell mit der Anzahl der beteiligten Agenten.
Mehr aus dem MBF Media Netzwerk
Foto: Pexels
Quelle Titelbild: Wikimedia Commons / Rene Schwietzke from Jena, Germany (CC BY 2.0)
