AWS zeigt in einem aktuellen Architekturbeispiel, wie sich Multi-Agent-Systeme bauen lassen, ohne einem Sprachmodell die letzte Entscheidung über Buchungen, Zahlungen oder andere irreversible Aktionen zu überlassen. Der Kern ist einfach: Agenten schlagen vor, deterministischer Code prüft, und erst danach wird gehandelt.
Das klingt weniger spektakulär als ein vollständig autonomes System. Für produktive Software ist genau diese Trennung aber interessanter als die nächste Demo, in der ein Agent möglichst viele Schritte selbst übernimmt.
AgentCore denkt, Step Functions entscheidet über den Ablauf
Im Beispiel von AWS geht es um die Umbuchung von Fluggästen nach einer Annullierung. Für jeden betroffenen Passagier arbeiten zwei spezialisierte Agenten: Einer sucht alternative Verbindungen, der andere berechnet mögliche Entschädigungen.
Die Agenten laufen über Bedrock AgentCore. AgentCore übernimmt dabei den eigentlichen Agent Loop mit Modellaufrufen, Tool-Nutzung, Memory und Antwortgenerierung. Die Orchestrierung außerhalb des Agenten liegt dagegen in AWS Step Functions.
Das ist eine bewusste Architekturgrenze. Step Functions entscheidet, welcher Schritt als Nächstes kommt, wann parallelisiert wird, wann ein Ergebnis validiert werden muss und wann ein Mensch übernehmen soll.
AWS beschreibt den Unterschied selbst ziemlich klar: Multi-Agent-Kollaboration überlässt einem Supervisor-Agenten typischerweise die Entscheidung, welcher Sub-Agent oder welches Tool verwendet wird. In der gezeigten Architektur wird ein großer Teil dieser Kontrolle aus der Modellschicht herausgenommen.
Kein Agent schreibt direkt ins Buchungssystem
Der praktisch wichtigste Punkt ist nicht die Zahl der Agenten, sondern ihre Berechtigung.
Kein Agent-Task darf direkt eine Reservierung ändern oder eine Zahlung auslösen. Nach jedem Agentenergebnis folgt ein deterministischer Validierungsschritt. Bei einer Umbuchung wird zum Beispiel geprüft, ob die vorgeschlagene Verbindung tatsächlich buchbar ist und zu den geltenden Tarif- und Routingregeln passt.
Erst wenn diese Prüfung erfolgreich ist, kann ein nachgelagerter Task die Aktion durchführen.
Damit bekommt ein Halluzinationsfehler eine andere Bedeutung. Wenn ein Modell eine nicht existente Verbindung vorschlägt, ist das zunächst nur ein fehlerhafter Vorschlag. Der Fehler wird erst gefährlich, wenn derselbe Agent gleichzeitig die Berechtigung besitzt, diesen Vorschlag ungeprüft in einem produktiven System umzusetzen.
Diese Unterscheidung ist für SaaS-Anwendungen deutlich wichtiger als die Frage, ob ein Agent im Benchmark zwei Prozentpunkte besser abschneidet.
Deterministische Validierung ist kein klassischer Human-in-the-loop
Der übliche Sicherheitsmechanismus für Agenten lautet häufig: Vor kritischen Aktionen fragt das System einen Menschen.
Das skaliert nur begrenzt. Wenn ein Agent hundert oder tausend Fälle bearbeitet und jeder davon manuell bestätigt werden muss, verlagert sich der Aufwand lediglich vom Ausführen zum Freigeben.
AWS kombiniert deshalb drei Ebenen:
Automatisch akzeptierte Fälle, wenn Agentenvorschlag und deterministische Prüfung eindeutig sind.
Automatisch verworfene Vorschläge, wenn feste Regeln verletzt werden.
Menschliche Prüfung nur für die Fälle, die nach diesen beiden Schritten tatsächlich unklar bleiben.
Step Functions kann solche Freigaben per Callback offen halten, ohne dass während der Wartezeit ein Agent-Prozess weiterlaufen muss. Für lange Workflows ist das sauberer als ein dauerhaft laufender Worker, der auf eine Antwort wartet.
10.000 parallele Ausführungen sind möglich – aber nicht automatisch sinnvoll
AWS verwendet im Beispiel eine Distributed Map. Standardmäßig können dabei bis zu 10.000 Child Executions parallel laufen. Im Beispiel wird die Parallelität bewusst auf 1.000 begrenzt.
Das Detail ist wichtig. Agenten lassen sich technisch sehr schnell parallelisieren. Die angebundenen Systeme skalieren deshalb noch lange nicht im selben Tempo. Eine Buchungs-API, eine Datenbank oder ein Zahlungsprovider kann zum eigentlichen Bottleneck werden.
Ein produktiver Agentenworkflow braucht deshalb nicht nur Limits für Modellaufrufe, sondern auch Backpressure gegenüber den Systemen, auf die der Agent zugreift.
Der Audit-Trail liegt außerhalb des Modells
Ein weiterer Vorteil der Architektur ist die Nachvollziehbarkeit. Step Functions speichert die einzelnen Zustandsübergänge mit Ein- und Ausgaben. Damit lässt sich später rekonstruieren, welcher Vorschlag erzeugt wurde, welche Validierung bestanden oder fehlgeschlagen ist und an welcher Stelle ein Mensch eingegriffen hat.
Agent Traces sind weiterhin nützlich, um Modellverhalten zu analysieren. Für einen geschäftlichen Prozess reicht ein Reasoning-Trace aber nicht als alleinige Historie. Die eigentliche Prozesshistorie sollte in einem System liegen, dessen Zustände nicht vom Modell selbst kontrolliert werden.
Was davon für normale SaaS-Agenten übrig bleibt
Nicht jede Anwendung braucht Step Functions oder Bedrock AgentCore. Das Architekturprinzip ist davon unabhängig.
Ein Agent kann beispielsweise einen Rechnungsentwurf vorbereiten, ohne ihn verschicken zu dürfen. Ein zweiter, deterministischer Schritt prüft Empfänger, Betrag, Status und Geschäftsregeln. Erst danach wird die Nachricht gesendet.
Dasselbe gilt für Deployments, Datenbankänderungen oder das Anlegen externer Ressourcen. Der Agent darf planen und Vorschläge erzeugen. Die eigentliche Aktion läuft über einen klar begrenzten Pfad mit überprüfbaren Regeln.
Für mich ist das derzeit eine sinnvollere Richtung für produktive Agenten als immer mehr Berechtigungen direkt in den Agent Loop zu verschieben. Je mehr reale Systeme ein Agent verändern kann, desto wichtiger wird eine Schicht, die gerade nicht probabilistisch arbeitet.
Quellen: AWS Compute Blog, „Validating multi-agent decisions with Step Functions and Bedrock AgentCore“, 14. September 2026.