AWS zeigt Multi-Agent-Musikpipeline auf Bedrock AgentCore Runtime Instances

Runtime Instances im Vergleich zu MicroVMs

Amazon Bedrock AgentCore bietet nun zwei Compute-Optionen zum Hosten von Agenten. Laut AWS sind MicroVMs die Serverless-Variante mit schnellen Kaltstarts, Session-Isolation und verbrauchsabhängiger Abrechnung. Runtime Instances sind die neue Option: von AWS verwaltete EC2-Infrastruktur für dauerhafte, langlaufende Agenten-Workflows.

Beide nutzen dieselben Runtime-APIs und unterstützen eigene Frameworks wie CrewAI, LangGraph, LlamaIndex und Strands Agents sowie MCP und A2A. Der Unterschied liegt im Compute-Modell. AWS nennt folgende Gegensätze:

• Sitzungsdauer: bis zu 8 Stunden bei MicroVM, bis zu 14 Tage bei Runtime Instances.
• Agenten pro Compute: ein Agent pro MicroVM, während eine EC2-Instanz mehrere Agenten hosten kann.
• GPU-Zugriff: bei MicroVM nicht unterstützt, bei Runtime Instances auf einer unterstützten Instanzfamilie verfügbar.
• Persistenz: bei MicroVM auf die Session begrenzt, bei Runtime Instances persistenter Speicher auf Amazon EBS.
• Preise: bei MicroVM verbrauchsabhängig. Runtime Instances laufen im Konto des Kunden, daher lassen sich AWS Savings Plans und On-Demand Capacity Reservations nutzen.

Teilen sich zwei Agent-Runtimes denselben Capacity Provider, lassen sie sich mit derselben runtimeSessionId aufrufen. Damit landen beide auf derselben EC2-Instanz, teilen sich ein Dateisystem und können gemeinsam an einer Aufgabe arbeiten.

Der Musik-Workflow mit drei Agenten

Die Beispiel-Pipeline nutzt drei spezialisierte Agenten, die jeweils einem anderen Team gehören.

• Kompositionsagent (Audio-AI-Team): verwandelt die Anfrage eines Produzenten mit Claude Sonnet 4.6 in ein musikalisches Briefing und rendert anschließend Audio mit ACE-Step, einem Open-Source-Foundation-Modell zur Musikgenerierung, auf der instanzeigenen GPU. Er ist als Container-Image in Amazon ECR verpackt.
• Auslieferungsagent (Audio-Engineering-Team): liest den gerenderten Track aus dem gemeinsamen Dateisystem und vermisst ihn. Danach fragt er Claude Sonnet 4.6 nach einer Auslieferungskette (EQ, Kompression, Limiting), und zwar auf Basis dieser Messwerte statt des Audios selbst. Echte Signalverarbeitung wendet die Kette an, das Ergebnis wird erneut gemessen, um zu bestätigen, dass das Auslieferungsziel erreicht wurde. Auch er ist ein Container-Image in Amazon ECR.
• Compliance-Agent (Release-Engineering-Team): misst die fertige Auslieferung unabhängig noch einmal nach, prüft sie gegen die Zielwerte, die der Auslieferungsagent angegeben hat, und gleicht sie auf harmonische Ähnlichkeit mit dem eigenen Backkatalog des Studios ab. Schlägt die Prüfung an, fordert er beim Kompositionsagenten Ersatz an und prüft erneut. Er wird als Zip-Datei auf Amazon S3 bereitgestellt.

Am Ende erhält der Produzent laut AWS eine abspielbare .wav-Datei und drei Berichte, die jede Entscheidung erläutern.

Was das Setup ermöglicht

AWS hebt mehrere Fähigkeiten hervor. Der Kompositionsagent führt ACE-Step direkt auf der NVIDIA L4 der Instanz aus und rendert 20 Sekunden Stereo-Audio mit 48 kHz in etwa 9 Sekunden. Das Modell und seine Abhängigkeiten liegen auf einem persistenten Volume, das einmal pro Session aufgebaut und von jedem Aufruf darin wiederverwendet wird, auch nach einem Stopp über Nacht.

Teams können unabhängig voneinander deployen: Das Audio-AI-Team kann ein neues Kompositions-Image ausrollen, ohne sich mit den beiden anderen Teams abzustimmen, deren Agenten unberührt weiterlaufen. Sessions können sich über Tage erstrecken. Ein Produzent kann am Montag an der Komposition arbeiten, die Session über Nacht stoppen und am Dienstag mit der Auslieferung fortfahren, da die Instanz automatisch in den Leerlauf geht und beim nächsten Aufruf wieder anläuft. Container-Images aus ECR und Code-Pakete aus S3 können zudem auf einem Capacity Provider nebeneinander bestehen.

Hinweise zur Umsetzung

Die Anleitung umfasst fünf Schritte: die Agenten definieren, einen Capacity Provider erstellen, der die GPU-Instanz und ihre persistenten Volumes bereitstellt, jeden Agenten als eigene Runtime deployen, sie mit einer gemeinsamen Session-ID aufrufen und eine neue Version eines Agenten ausrollen, ohne die anderen zu stören. Das vollständige Beispiel liegt im GitHub-Repository mit den AgentCore-Samples.

Zu den Voraussetzungen gehören ein AWS-Konto mit Berechtigung zum Anlegen von Infrastruktur, die AWS CLI, eine VPC mit mindestens einem Subnetz und einer Security Group, Bedrock-Modellzugriff auf Anthropic Claude Sonnet 4.6, Finch oder ein anderes OCI-kompatibles Container-Tool sowie Python 3.10+. Zudem verlangt AWS boto3 ab Version 1.36.0 oder botocore ab Version 1.43.72, da ältere Versionen create_capacity_provider nicht kennen und das Deploy-Skript fehlschlägt.

Jeder Agent im Beispiel ist eine mit Strands Agents gebaute Python-Anwendung. AWS weist auf zwei häufig falsch konfigurierte Details hin. Der Entrypoint-Parameter muss "context" heißen, weil das SDK anhand dieses Namens zuordnet und nur so die Session-ID gelesen werden kann. Außerdem sollte der Agent innerhalb des Handlers statt auf Modulebene erstellt werden, da ein Agent auf Modulebene von gleichzeitigen Anfragen geteilt wird und Strands reentrante Aufrufe ablehnt. Der Gesprächsverlauf wird über FileSessionManager auf dem Volume gespeichert, wodurch sich eine Session, die Tage später fortgesetzt wird, an frühere Entscheidungen erinnert.

Was das für Teams bedeutet, die Agenten bauen

Laut AWS eignen sich Serverless-Sessions mit einem Limit von wenigen Stunden nicht für kreative Workflows, in denen mehrere Agenten über Tage zusammenarbeiten und auf den Ergebnissen der anderen aufbauen. Runtime Instances zielen auf diesen Fall und bringen GPUs, persistente Volumes und die Ansiedlung mehrerer Agenten auf einer Instanz mit. Da die Instanzen im Konto des Kunden laufen, können bestehende Savings Plans und Kapazitätsreservierungen greifen. Die Musikpipeline dient als Referenz für Teams, in denen getrennte Gruppen ihre eigenen Agenten unabhängig ausliefern und dennoch einen gemeinsamen Zustand teilen wollen.