AI-Agent-Framework auswählen: Praxisvergleich

Ein Tool-Schema mit strict=true kann laut offizieller Dokumentation zur strukturierten Tool-Ausgabe exakt an ein vorgegebenes JSON-Schema gebunden werden. Das zeigt bereits die wichtigste Auswahlregel: AI-Agent-Frameworks sollten nicht nach dem größten Funktionsumfang ausgewählt werden, sondern danach, ob sie Tool-Aufrufe, Zustände und Fehler kontrollierbar machen.

Symptom: Ihr PoC funktioniert, aber niemand weiß, wie ein fehlgeschlagener Tool-Aufruf, eine ausstehende Genehmigung oder ein abgebrochener Prozess fortgesetzt wird.
Schnellste Lösung: Bestimmen Sie zuerst die Prozesssicherheit und Zustandskomplexität. Wählen Sie danach zwischen leichtgewichtigem SDK, Workflow-Framework und Multi-Agent-Framework.

Zielgruppe dieser Auswahlentscheidung

Dieser Vergleich richtet sich an Sie, wenn Sie bereits ein konkretes AI-Agent-Projekt planen und nicht mehr nur die Fähigkeiten einzelner Modelle testen. Besonders relevant ist der Artikel für:

• Entwickler, die einen Agenten mit Datenbanken, APIs, Dateisystemen oder internen Diensten verbinden;
• technische Verantwortliche, die einen funktionierenden PoC in einen dauerhaft betreibbaren Dienst überführen möchten;
• Teams, die wegen zu schwerer Framework-Abstraktionen, instabiler Tool-Aufrufe oder fehlender Wiederherstellung bereits nacharbeiten mussten.

Die zentrale Frage lautet deshalb nicht „Welches Framework ist das beste?“, sondern: Welche Kontrollschicht brauchen Sie für genau diesen Prozess?

Braucht Ihr Projekt überhaupt ein AI-Agent-Framework?

Bevor Sie Frameworks vergleichen, sollten Sie das Vorhaben in eine von vier Kategorien einordnen.

Kategorie 1: einzelne Modellantwort

Ein Nutzer stellt eine Frage, das Modell erzeugt eine Antwort, und es gibt keinen externen Seiteneffekt. Dafür benötigen Sie in der Regel kein Agent-Framework. Eine API-Anbindung, Prompt-Verwaltung, Eingabevalidierung und Fehlerbehandlung im Anwendungscode reichen aus.

Kategorie 2: Assistent mit festem Tool-Aufruf

Der Assistent ruft beispielsweise eine Suchfunktion oder eine interne Datenbankabfrage auf. Auch hier genügt oft ein leichtgewichtiges SDK. Wichtig sind ein klares Tool-Schema, serverseitige Parameterprüfung und eine eindeutige Trennung zwischen Modellentscheidung und tatsächlicher Tool-Ausführung.

Die Dokumentation zu Function Calling und strukturierten Ausgaben beschreibt, wie Schema-gebundene Argumente die Validierung von Werkzeugparametern unterstützen. Das ersetzt jedoch keine Berechtigungsprüfung auf Ihrer Serverseite.

Kategorie 3: zustandsbehafteter Workflow

Sobald ein Prozess mehrere Schritte, Wartezustände, Freigaben oder Verzweigungen enthält, verändert sich die Auswahl. Ein Beispiel:

1. Anfrage aufnehmen;
2. Kundendaten aus einem internen System lesen;
3. eine Änderung vorschlagen;
4. menschliche Freigabe abwarten;
5. Änderung durchführen;
6. Ergebnis protokollieren.

Dieser Ablauf ist nicht nur eine Folge von Modellaufrufen. Er benötigt Zustandsverwaltung, Wiederaufnahme und nachvollziehbare Übergänge. Hier ist ein Workflow-Framework häufig sinnvoller als eine lose Sammlung von Agent-Schleifen.

Kategorie 4: autonomer oder Multi-Agent-Prozess

Mehrere spezialisierte Agenten können sinnvoll sein, wenn Recherche, Prüfung, Planung und Ausführung unterschiedliche Berechtigungen, Werkzeuge oder Qualitätskriterien benötigen. Die Aufteilung muss jedoch fachlich begründet sein. Mehr Agenten bedeuten zusätzliche Übergaben, weitere Zustände, mehr Protokollierungsbedarf und eine größere Fehlerfläche.

Erfahrung: Wenn Sie den gesamten Prozess noch nicht als überprüfbare Zustandsfolge beschreiben können, ist ein Multi-Agent-Framework meistens zu früh. Modellautonomie sollte erst dort eingesetzt werden, wo deterministische Regeln allein nicht ausreichen.

Welche Framework-Klasse passt zu Ihrem Prozess?

Im ersten Halbjahr sollten Sie nicht zehn Frameworks parallel evaluieren. Reduzieren Sie die Auswahl zunächst auf höchstens zwei Kandidaten und ordnen Sie diese einer Architekturklasse zu.

Architekturklasse	Geeignet für	Typische Vorteile	Typische Risiken
Leichtgewichtiges SDK	Kurze Agent-Schleifen mit wenigen Tools	Wenig Abstraktion, schnelle Tests, gute Kontrolle im Anwendungscode	Zustände, Wiederaufnahme und Observability müssen Sie selbst bauen
Workflow-Framework	Verzweigte, länger laufende oder genehmigungspflichtige Prozesse	Checkpoints, Routing, Wiederaufnahme und definierte Übergänge	Höhere Lernkosten, zusätzlicher Laufzeit- und Betriebsaufwand
Multi-Agent-Framework	Klar getrennte Rollen mit eigenen Aufgaben und Grenzen	Delegation, Spezialisierung und parallele Arbeit	Mehr Latenz, schwierige Übergaben, schwerere Fehleranalyse

Die passende Klasse ergibt sich aus vier Bedingungen:

• Hohe Prozessdeterministik und niedrige Zustandskomplexität: Beginnen Sie mit einem SDK.
• Mehrere feste Schritte, Freigaben oder Wiederaufnahme nach Fehlern: Prüfen Sie ein Workflow-Framework.
• Unterschiedliche Rollen, Werkzeuge und Berechtigungen: Testen Sie einen Multi-Agent-Ansatz.
• Unklare Prozesslogik: Bauen Sie zunächst eine kleine deterministische Version. Ein Framework würde die Unklarheit nur verdecken.

Ein Framework, das Konfiguration, Code und visuelle Diagramme kombiniert, kann produktiv sein. Entscheidend ist aber, ob Ihr Team die erzeugte Ausführungslogik lesen, testen und im Incident-Fall verändern kann. Eine visuelle Darstellung ist kein Ersatz für nachvollziehbare Zustandsübergänge.

Entwicklungskosten und Abstraktionsniveau

Die Entwicklungsanforderung wird häufig unterschätzt. Ein leichtgewichtiges SDK wirkt zunächst einfach, kann aber später viel Eigenarbeit verursachen. Sie müssen unter Umständen selbst implementieren:

• Sitzungs- und Zustandsverwaltung;
• Retry-Regeln und Timeout-Kontrolle;
• Werkzeugregister und Berechtigungsprüfung;
• Tracing für einzelne Modell- und Tool-Schritte;
• Wiederaufnahme nach Prozessabbrüchen;
• Versionierung laufender Aufgaben.

Ein Workflow-Framework nimmt Ihnen Teile dieser Arbeit ab, verlangt dafür aber ein neues mentales Modell. Ihr Team muss Zustandsobjekte, Knoten, Übergänge, Checkpoints und Ausführungsereignisse verstehen. Wenn die Entwickler hauptsächlich mit klassischen Webdiensten arbeiten, kann eine stark graphische oder konfigurationslastige Abstraktion die Fehlersuche verlangsamen.

Bewerten Sie daher nicht nur die Einstiegsgeschwindigkeit. Prüfen Sie den gesamten Lebenszyklus:

1. Wie wird ein neuer Tool-Aufruf implementiert?
2. Wie wird ein ungültiger Parameter zurückgewiesen?
3. Wie testen Sie einen einzelnen Zustandsübergang?
4. Wie reproduzieren Sie einen Fehler aus der Produktion?
5. Wie ändern Sie eine laufende Aufgabe, ohne alte Zustände unbrauchbar zu machen?

Ein guter Kandidat passt zu Ihrer vorhandenen Sprache, Testpraxis und Betriebsumgebung. Wenn Ihr Team Type- oder Schema-Validierung bereits konsequent einsetzt, sollte das Framework diese Arbeitsweise unterstützen statt eine parallele Konfigurationssprache einzuführen.

Werkzeugaufrufe brauchen klare Kontrollgrenzen

Die Qualität eines AI Agent Frameworks zeigt sich nicht daran, wie viele Tools sich registrieren lassen. Sie zeigt sich daran, wie sicher ein Werkzeug aufgerufen, abgelehnt, wiederholt und nach einem Fehler behandelt wird.

Für jedes Tool sollten Sie mindestens diese Eigenschaften prüfen:

Parameterschema: Sind Pflichtfelder, Datentypen, Wertebereiche und Abhängigkeiten maschinenprüfbar? Freie Textparameter sind für externe Seiteneffekte riskanter als eng begrenzte Strukturen.

Timeouts: Was geschieht, wenn ein internes System nicht antwortet? Ein Agent darf nicht unbegrenzt auf einen Dienst warten oder denselben Vorgang unkontrolliert wiederholen.

Retries: Wiederholungen müssen vom Seiteneffekt abhängen. Eine fehlgeschlagene Leseabfrage kann oft wiederholt werden. Eine Zahlungs-, Lösch- oder Bestelloperation benötigt dagegen Idempotenzschlüssel und eine sichere Statusabfrage.

Genehmigungen: Sensible Werkzeuge sollten eine menschliche Freigabe anfordern können. Die Dokumentation zu Human-in-the-Loop-Abläufen beschreibt ein Muster, bei dem ein Lauf pausiert, eine Entscheidung entgegennimmt und anschließend fortgesetzt wird.

Protokollierung: Speichern Sie mindestens Agent-ID, Aufgaben-ID, Tool-Name, validierte Argumente, Ergebnisstatus, Fehlerklasse und Zeitstempel. Vollständige Eingaben können personenbezogene Daten enthalten und müssen deshalb nach DSGVO-Grundsätzen minimiert und geschützt werden. Eine passende interne Referenz ist die Datenschutzerklärung von Kvmjet, wenn Sie die Verarbeitung Ihrer Testdaten für die Umgebung planen.

Berechtigungsgrenzen: Ein Tool darf nicht allein deshalb verfügbar sein, weil der Agent es aufrufen kann. Definieren Sie getrennte Rollen für Lesen, Schreiben, Freigeben und Administrieren.

Bei steigender Tool-Anzahl wird die Auswahlgenauigkeit nur ein Teil des Problems. Ebenso wichtig ist die Frage, ob Ihr System einen falschen Aufruf erkennt. Ein Agent, der ein unbekanntes Tool ablehnt und einen überprüfbaren Fehler zurückgibt, ist im Produktionsbetrieb wertvoller als ein Agent, der viele Werkzeuge kennt, aber ungültige Aktionen stillschweigend ausführt.

Erweiterbarkeit entscheidet über die langfristige Architektur

Viele Frameworks werben mit Plugins, Adaptern oder Middleware. Für die Auswahl reicht diese Aussage nicht aus. Sie müssen prüfen, ob Erweiterungen tatsächlich über stabile Schnittstellen möglich sind.

Bewerten Sie fünf Ebenen:

• Modellwechsel: Können Sie den Modellanbieter ändern, ohne Prompt- und Zustandslogik neu zu schreiben?
• Speicheradapter: Lassen sich kurzfristiger Laufzustand, langfristige Wissensdaten und Sitzungsdaten getrennt behandeln?
• Tool-Registry: Können interne und externe Werkzeuge einheitlich registriert, versioniert und berechtigt werden?
• Workflow-Komposition: Können Sie einen geprüften Teilprozess in einen größeren Ablauf einbauen?
• Middleware: Lassen sich Logging, Redaction, Rate Limits und Policy-Prüfungen zentral einschieben?

Eine Schnittstelle ist nur dann real, wenn Sie sie in einem kleinen Prototypen verwenden können, ohne den Framework-Kern zu verändern. Prüfen Sie deshalb nicht nur die API-Referenz, sondern auch Wartungshinweise, Migrationsanleitungen und Beispiele für eigene Komponenten.

Besonders kritisch ist die Zustandsabstraktion. Wenn der Framework-Zustand nicht exportierbar oder versionierbar ist, kann ein späterer Wechsel teuer werden. Ein Persistenzkonzept mit Checkpoints zeigt, welche Informationen für die Wiederaufnahme eines laufenden Threads gespeichert werden müssen. Für Ihre Entscheidung ist dabei weniger der Produktname wichtig als die konkrete Frage: Können Sie einen alten Zustand nach einem Schemawechsel weiterhin interpretieren?

Produktionsumgebung benötigt einen Wiederherstellungsplan

Eine Demo beweist, dass der Agent einen erfolgreichen Pfad absolvieren kann. Sie beweist nicht, dass die Anwendung einen abgebrochenen Lauf sicher fortsetzt.

Vor dem Deployment sollten Sie mindestens diese Fehlerfälle simulieren:

1. Das Modell liefert ungültige Tool-Argumente.
2. Ein Tool antwortet erst nach dem Timeout.
3. Der Tool-Aufruf wird ausgeführt, aber die Antwort geht verloren.
4. Die Verbindung bricht während eines mehrstufigen Prozesses ab.
5. Eine menschliche Freigabe bleibt über längere Zeit offen.
6. Zwei Worker bearbeiten dieselbe Aufgabe gleichzeitig.
7. Ein Berechtigungswechsel macht einen bereits geplanten Tool-Aufruf unzulässig.

Ein Workflow-Framework kann bei Checkpoints und Unterbrechungen Vorteile bieten. Die Dokumentation zu Unterbrechungen und Wiederaufnahme beschreibt beispielsweise das Speichern eines Zustands, bevor auf externe Eingaben gewartet wird. Das allein genügt jedoch nicht. Sie benötigen zusätzlich eine belastbare Datenbank, eine Aufgaben-ID, eine Queue-Strategie und Regeln für doppelte Ausführung.

Ein produktionsfähiger Agent benötigt daher mindestens:

• persistente Zustände statt flüchtiger Prozessvariablen;
• getrennte Warteschlangen für neue, laufende und blockierte Aufgaben;
• begrenzte Nebenläufigkeit pro Nutzer, Mandant oder Tool;
• eindeutige Idempotenzschlüssel für schreibende Operationen;
• Metriken für Fehlerraten, Wartezeiten und Wiederholungen;
• Traces, die Modellentscheidung und tatsächliche Tool-Ausführung unterscheiden;
• eine manuelle Übernahme für sensible oder nicht automatisch lösbare Fälle.

Frameworks mit Flows oder ereignisgesteuerten Abläufen können diese Anforderungen strukturieren. Die offizielle Dokumentation zu Flows und Zustandsverwaltung ist ein Beispiel dafür, wie strukturierte Abläufe, Zustände und menschliche Freigaben in einer gemeinsamen Architektur gedacht werden. Ob das zu Ihrem System passt, müssen Sie anhand Ihres eigenen Fehlerfalls prüfen.

Mit welchem Test entscheiden Sie zwischen zwei Kandidaten?

Nehmen Sie nicht die schönste Demo, sondern einen kleinen Fehlerprozess aus Ihrem tatsächlichen Projekt. Ein brauchbarer Test kann so aussehen:

1. Definieren Sie eine Aufgabe mit einem Seiteneffekt.
   Beispiel: Ein interner Datensatz soll nach Prüfung aktualisiert werden.

2. Begrenzen Sie den Agenten auf zwei oder drei Werkzeuge.
   Damit erkennen Sie, ob das Problem aus der Tool-Auswahl oder aus der Prozesslogik entsteht.

3. Erzwingen Sie eine menschliche Freigabe.
   Prüfen Sie, ob der Lauf pausiert, der Zustand gespeichert und nach der Entscheidung fortgesetzt wird.

4. Simulieren Sie einen verlorenen Tool-Aufruf.
   Das Tool soll die Aktion ausführen, aber keine erfolgreiche Antwort an den Agenten zurückgeben. Ihr System muss jetzt den Ausführungsstatus prüfen, statt blind zu wiederholen.

5. Starten Sie den Worker während des Prozesses neu.
   Nach dem Neustart darf die Aufgabe weder verloren gehen noch automatisch doppelt ausgeführt werden.

6. Prüfen Sie das Audit-Protokoll.
   Sie sollten nachvollziehen können, wer oder was den Aufruf ausgelöst, genehmigt, ausgeführt und beendet hat.

7. Bewerten Sie die Änderbarkeit.
   Ändern Sie ein Tool-Schema und prüfen Sie, ob laufende Aufgaben weiterhin lesbar bleiben.

Für diesen Test reicht ein kleiner Dienst. Sie brauchen weder eine vollständige Plattform noch eine große Agentenlandschaft. Entscheidend ist, dass beide Kandidaten dieselbe Aufgabe unter denselben Fehlerbedingungen ausführen.

Eine konkrete Auswahlmatrix für Ihre Entscheidung

Nutzen Sie die folgende Reihenfolge, statt Eigenschaften isoliert zu bewerten:

• Wenn der Prozess in festen Schritten beschrieben werden kann, starten Sie ohne Multi-Agent-Abstraktion.
• Wenn nur ein Modellaufruf und wenige sichere Tools erforderlich sind, bevorzugen Sie ein SDK.
• Wenn Wartezustände, Checkpoints oder Verzweigungen notwendig sind, bevorzugen Sie ein Workflow-Framework.
• Wenn Rollen eigene Werkzeuge und Berechtigungen besitzen, prüfen Sie Multi-Agent-Orchestrierung.
• Wenn Tool-Aufrufe nicht vollständig protokolliert werden können, stoppen Sie die Auswahl und beheben zuerst die Governance-Lücke.
• Wenn der Framework-Zustand nicht exportiert oder migriert werden kann, verlangen Sie einen belastbaren Ausstiegsplan.
• Wenn das Team die Abstraktion nicht in Unit- und Integrationstests abbilden kann, wählen Sie die einfachere Architektur.

Prüfliste vor der Entscheidung

• [ ] Ist der Prozess ohne Framework als deterministischer Ablauf beschrieben?
• [ ] Sind alle Tool-Parameter serverseitig validiert?
• [ ] Gibt es getrennte Leserechte, Schreibrechte und Freigaberechte?
• [ ] Sind Timeout, Retry und Idempotenz pro Tool definiert?
• [ ] Kann ein Lauf nach einer Unterbrechung fortgesetzt werden?
• [ ] Wird der Zustand dauerhaft gespeichert und versioniert?
• [ ] Können Sie doppelte Ausführung erkennen und verhindern?
• [ ] Sind Modellaufrufe, Tool-Aufrufe und menschliche Entscheidungen getrennt sichtbar?
• [ ] Kann ein Worker neu gestartet werden, ohne Aufgaben zu verlieren?
• [ ] Ist eine manuelle Übernahme für blockierte Aufgaben vorgesehen?
• [ ] Können Sie das Modell oder den Speicheradapter austauschen?
• [ ] Haben Sie denselben Fehlerfall mit höchstens zwei Kandidaten getestet?

Wenn Sie mehr als zwei zentrale Punkte nicht beantworten können, sollten Sie noch kein Framework für den langfristigen Betrieb festlegen. Bauen Sie zunächst den kleinsten reproduzierbaren Prozess und ergänzen Sie nur die Kontrolle, die der Prozess tatsächlich benötigt.

Die Rolle der Ausführungsumgebung

Ein Agent mit persistenter Zustandsverwaltung, Worker-Prozessen, Queue-Verbrauchern und Tracing benötigt eine stabilere Umgebung als ein einzelnes lokales Skript. Für einen zeitlich begrenzten PoC kann eine lokale Entwicklungsumgebung ausreichend sein. Für kontinuierliche Tests benötigen Sie dagegen reproduzierbare Zugänge, klare SSH- oder Remote-Desktop-Regeln, getrennte Geheimnisse und eine Umgebung, die auch außerhalb Ihrer lokalen Sitzung erreichbar bleibt.

Wenn Sie eine temporäre Mac-basierte Entwicklungsumgebung für Tests, CI/CD oder laufende Agent-Prozesse benötigen, sollten Sie vorab die Anforderungen an Laufzeit, Netzwerkzugriff und Datenverarbeitung festhalten. Für organisatorische Fragen können Sie das Kvmjet-Hilfezentrum prüfen; bei einem konkreten Testaufbau sollten Sie die Umgebung erst nach dem oben beschriebenen Fehlerlauf auswählen.

Eine selbst verwaltete Maschine kann für langfristige, konstante Lasten wirtschaftlicher sein. Eine gemietete Umgebung ist dagegen interessant, wenn Sie nur für Evaluierung, Migration oder einen begrenzten Release-Zeitraum zusätzliche Kapazität benötigen. Entscheidend bleiben Datenstandort, Zugriffskontrolle, Wiederholbarkeit und die Möglichkeit, die Testumgebung nach Abschluss wieder zu entfernen.

Fazit zur vernünftigen Auswahl

Wählen Sie ein leichtgewichtiges SDK, wenn Ihr Agent wenige Werkzeuge nutzt, kurze Läufe ausführt und der Zustand problemlos im Anwendungscode kontrolliert werden kann.

Wählen Sie ein Workflow-Framework, wenn Aufgaben warten, verzweigen, genehmigt oder nach einem Fehler fortgesetzt werden müssen. Für viele ernsthafte Produktionsprojekte ist dies der ausgewogenste Ausgangspunkt, weil Kontrolle und Agentenfähigkeiten kombiniert werden können.

Wählen Sie ein Multi-Agent-Framework erst dann, wenn die fachliche Trennung zwischen Agenten eindeutig ist und unterschiedliche Rollen tatsächlich eigene Werkzeuge, Daten oder Berechtigungen benötigen. Für einen einzelnen Recherche-, Support- oder Datenverarbeitungsprozess ist diese Architektur häufig unnötig schwer.

Falls Sie derzeit nur mit einem lokalen Skript, einer ungesicherten Prompt-Schleife oder einer gemeinsam genutzten Entwicklungsmaschine arbeiten, liegen die Schwächen meist bei fehlender Zustandswiederherstellung, nicht nachvollziehbaren Tool-Aufrufen und unklaren Berechtigungen. Ein Kvmjet-Testsystem kann dafür sinnvoll sein, wenn Sie eine zeitlich begrenzte, reproduzierbare Umgebung für Fehlerläufe, CI/CD oder Dauerbetriebstests benötigen. Für dauerhaft hohe Last, spezielle physische Schnittstellen oder langfristig konstante Nutzung sollten Sie dagegen den Kauf und den Eigenbetrieb einer passenden Maschine gegenrechnen.

Beginnen Sie daher mit einem einzigen realen Fehlerfall, testen Sie höchstens zwei Kandidaten und entscheiden Sie erst danach über die größere Architektur. Prüfen Sie ergänzend die verfügbaren Mac-Umgebungen von Kvmjet, wenn Ihr nächster Schritt eine kontrollierte Agent-Validierung unter realen Betriebsbedingungen ist.

Häufige Fragen zur Framework-Auswahl

Braucht jedes AI-Agent-Projekt ein Framework?

Nein. Wenn ein Modell eine einzelne Antwort erzeugt oder eine fest definierte Folge von Funktionen ausführt, reichen meist ein SDK, normale Anwendungscode-Strukturen und eigene Validierung. Ein Framework wird erst sinnvoll, wenn Zustände über mehrere Schritte erhalten bleiben, Tools dynamisch gewählt werden, Genehmigungen erforderlich sind oder fehlgeschlagene Aufgaben später fortgesetzt werden müssen.

Wann ist ein leichtgewichtiges Agent-SDK besser als ein Workflow-Framework?

Ein leichtgewichtiges Agent-SDK passt zu kurzen, gut begrenzten Interaktionen mit wenigen Werkzeugen und geringer Zustandskomplexität. Ein Workflow-Framework ist die bessere Wahl, sobald Abläufe verzweigen, Wartezeiten enthalten, wiederaufgenommen werden müssen oder mehrere Rollen für Überwachung, Freigabe und Fehlerbehandlung beteiligt sind.

Ab wann lohnt sich ein Multi-Agent-Framework?

Ein Multi-Agent-Framework lohnt sich nicht allein wegen mehrerer Prompts. Es wird interessant, wenn Aufgaben fachlich klar getrennt sind, Agenten unterschiedliche Werkzeuge oder Berechtigungen benötigen und die Übergaben messbar besser funktionieren als ein zentraler Agent. Ohne solche Grenzen erhöhen mehrere Agenten vor allem Kosten, Latenz und Fehlersuche.

Was muss vor dem Deployment eines Agent-Frameworks geprüft werden?

Prüfen Sie mindestens Schema-Validierung, Berechtigungsgrenzen, Timeout- und Retry-Verhalten, Protokollierung, Zustandswiederherstellung, Nebenläufigkeit und manuelle Übernahme. Führen Sie außerdem einen absichtlich fehlschlagenden Werkzeugaufruf aus. Ein erfolgreicher Demo-Lauf beweist nicht, dass der Prozess nach Netzwerkfehlern oder menschlicher Freigabe sicher fortgesetzt werden kann.