AWS veröffentlicht Leitfaden zum Aufbau von Strands Agents mit SageMaker-KI-Modellen und MLflow-Observability: SageMakerAIModel-Provider, Autolog-Tracing und A/B-Variantentests

Der AWS Machine Learning Blog hat einen umfangreichen technischen Leitfaden veröffentlicht, wie KI-Agenten mithilfe von drei Komponenten aufgebaut werden können: dem Open-Source Strands Agents SDK, Amazon SageMaker AI-Endpunkten für das Hosting von Modellen und SageMaker AI Serverless MLflow für Observability. Der Leitfaden ist relevant für Organisationen, die Agenten in die Produktion bringen möchten, aber aus betrieblichen oder regulatorischen Gründen nicht ausschließlich auf verwaltete Dienste wie Amazon Bedrock angewiesen sein können.

Was ist Strands Agents

Strands Agents ist ein “open source SDK that takes a model-driven approach to building and running AI agents in only a few lines of code”. Architektonisch kombiniert das Framework drei Komponenten:

• ein Sprachmodell (der LLM, der schlussfolgert),
• einen System-Prompt (Rollen- und Verhaltensdefinition),
• ein Toolset (Liste der Funktionen, die der Agent aufrufen kann).

Dieses minimalistische Muster ähnelt anderen Agenten-SDKs (LangChain, AutoGen, CrewAI), aber die model-driven-Philosophie — der Agent überlässt dem Modell Entscheidungen, anstatt sie in starre Workflows zu kodieren — ist ein charakteristisches Merkmal.

Warum SageMaker statt Bedrock

AWS nennt explizit vier Gründe, warum eine Organisation einen selbstverwalteten SageMaker-Endpunkt gegenüber dem verwalteten Bedrock-Dienst wählen würde:

• Infrastrukturkontrolle — über Compute-Instanzen, VPC-Netzwerke und Sicherheitseinstellungen;
• Modellflexibilität — Custom-Modelle, Fine-Tuned-Varianten, Open-Source-Modelle, die nicht unbedingt im Bedrock-Katalog vorhanden sind;
• Kostenprävisibilität — Reserved Instances und Spot Pricing ergeben einen Betriebskosten-Variationskoeffizienten mit niedrigerem Wert;
• Erweiterte MLOps — Model Registry, A/B-Testing, Versions-Management.

Das Strands SDK enthält einen SageMakerAIModel-Provider, der Agenten ermöglicht, Endpunkte zu nutzen, auf denen Modelle wie Qwen3 oder andere Open-Source-LLMs laufen.

MLflow als Observability-Schicht

Der wesentliche Mehrwert des Leitfadens ist die Integration mit SageMaker AI Serverless MLflow:

• automatische Erfassung von Ausführungs-Traces,
• Tool-Nutzungsmuster (welches Tool der Agent wann aufruft),
• Decision-Workflows (welcher Reasoning-Pfad zur finalen Aktion führte).

Die Aktivierung ist deklarativ — ein einziger mlflow.strands.autolog()-Aufruf im Code — ohne Custom-Instrumentierung. Damit werden zwei wichtige Ziele erreicht, die regulatorische Rahmenbedingungen zunehmend fordern:

• Verhaltensmonitoring von Agenten in der Produktion,
• Audit-Trails, die eine retrospektive Analyse von Entscheidungen ermöglichen.

Dies ist besonders relevant im Kontext des EU AI Acts, dessen Artikel 12 automatisches Logging und Artikel 72 Post-Market Monitoring fordern.

Implementierungs-Workflow: Fünf Schritte

AWS beschreibt einen fünfstufigen Workflow:

• Deploy von Foundation-Modellen über SageMaker JumpStart,
• Erstellen von Strands-Agenten mithilfe von SageMakerAIModel mit Referenz auf den deployte Endpunkt,
• Aktivieren des automatischen Loggings über mlflow.strands.autolog(),
• Deploy mehrerer Modellvarianten für paralleles A/B-Testing,
• Evaluierung von Agenten über das MLflow GenAI Evaluation Framework mit Custom Scorern.

Schritt 4 (A/B-Testing) ist besonders nützlich im Kontext der Produktionsentwicklung — anstatt riskanter “Big Bang”-Migrationen zu neuen Modellen können Organisationen den Traffic schrittweise auf die neue Variante verlagern und Unterschiede in Qualität und Kosten messen.

Hervorgehobene Anwendungsfälle

AWS empfiehlt diese Architektur für vier Workload-Typen:

• Konversationelle KI mit strengen Latenzanforderungen — wo ein gemeinsam genutzter verwalteter Dienst keine ausreichende Kontrolle über die p99-Latenz bietet,
• hochvolumige Anwendungen mit vorhersehbaren Kosten — wo der Pro-Token-Preis verwalteter Dienste zum dominierenden Kostenfaktor wird,
• compliance-sensible Deployments mit Anforderungen an die Datenresidenz — wo präzise Kontrolle über Datenspeicherort und Verschlüsselung erforderlich ist,
• Modell-Experimente — systematische A/B-Tests vor der vollständigen Migration.

Praktische Implikationen

Drei Dinge, die Teams, die bereits AWS nutzen, in Betracht ziehen sollten:

• MLflow-Integration ist mit geringem Overhead verbunden und kann in bestehende Agenten-Implementierungen ohne großes Refactoring eingeführt werden;
• SageMakerAIModel-Provider öffnet die Tür für regionale oder lokale Open-Source-Modelle, die nicht im Bedrock-Katalog vorhanden sind, was für europäische Organisationen relevant ist, die die Datenresidenz kontrollieren möchten;
• A/B-Testing von Agentenvarianten erfordert mehr als nur Deployment — definierte Qualitätsmetriken (Custom Scorer) und Traffic-Routing-Strategien sind erforderlich.

Der Leitfaden ist technisch dicht und richtet sich an Praktiker mit bereits vorhandener SageMaker-Erfahrung. Für Teams, die mit Agenten in der AWS-Umgebung beginnen, definiert er eine Standardarchitektur — eine Alternative zum verwalteten Bedrock-Dienst mit mehr Kontrolle, aber auch mehr Betriebsverantwortung.