Agenten brauchen Case Management, nicht nur Tools

Agenten brauchen Case Management, sobald sie mehr tun als eine Demo abarbeiten. AWS beschreibt in Amazon Quick Automate, wie Workflows mit tausenden oder Millionen Vorgängen erst dann steuerbar werden, wenn jeder Vorgang als persistenter Case mit Status, Historie und Ausnahmebehandlung geführt wird.

Was neu sichtbar wird

AWS positioniert Quick Automate als Kombination aus AI-Agenten, deterministischer Workflow-Orchestrierung und nativer Case-Verwaltung. Jeder Vorgang kann einen Lebenszyklus von Erstellung über Verarbeitung bis Auflösung durchlaufen. Dazu gehören Status-Updates, parallele Ausführung, Aktivitätsprotokolle, Versionierung, granulare Zugriffe, Exception Handling und Human-in-the-loop-Schritte.

Google zeigt parallel bei Managed Agents in der Gemini API eine andere Seite derselben Entwicklung: Agenten sollen länger laufende Aufgaben im Hintergrund ausführen, Remote-MCP-Server anbinden, eigene Funktionen nutzen und Credentials über Interaktionen hinweg auffrischen können. Das macht Agenten produktiver, erhöht aber die Anforderungen an Kontrollpunkte, Wiederaufnahme und Zuständigkeit.

Warum Tools allein nicht reichen

Der AWS-Beitrag zu MCP-Tool-Design benennt zwei typische Fehlerquellen: Kontext-Bloat und Verwirrung. Wenn zu viele Tools, unklare Beschreibungen oder ungeeignete Rückgaben im Kontext landen, ruft ein Agent falsche Tools auf, setzt Parameter falsch oder produziert teure Wiederholungen. Das ist kein reines Entwicklerproblem, sondern ein Betriebsproblem.

Für CIOs heißt das: Der Agent ist nicht der Prozess. Der Prozess braucht einen Owner, definierte Zustände, Eskalationsregeln, Protokolle, Review-Punkte und Kostenlogik. Sonst skaliert nicht Automatisierung, sondern Intransparenz.

DACH-Perspektive

DACH-Unternehmen sollten Agentenprojekte nicht nur über Modellqualität bewerten. Entscheidend ist, ob ein Vorgang revisionsfähig nachvollziehbar bleibt: Wer hat den Case ausgelöst? Welche Tools wurden genutzt? Wo durfte ein Mensch eingreifen? Welche Daten verließen welchen Kontext? Und welcher Fehlerzustand stoppt den Lauf?

Der pragmatische Startpunkt ist ein einzelner Prozess mit hohem Volumen, aber begrenztem Risiko: Ticket-Klassifikation, Rechnungsprüfung oder Angebotsvorbereitung. Definieren Sie zuerst Case-Status, HITL-Gates, Tool-Katalog und Logging. Erst danach lohnt sich die Frage, welches Modell den nächsten Schritt ausführt.