KI-Agenten orchestrieren: Zuständigkeiten, Freigaben und Kosten

KI-Agenten lassen sich am besten orchestrieren, wenn schon vor dem nächsten zusätzlichen Agenten feststeht, wer den nächsten Schritt verantwortet. Für die Aufnahme von Anfragen, Recherche, Entwurf und Freigabe decken 4 Muster die wesentlichen Entscheidungen ab: ein leitender Agent mit Zuarbeitern, Übergaben zwischen Spezialisten, ein Graph mit Checkpoints und ein persistenter Workflow als Rahmen für die Agenten. Ob Nachrichten versendet, Geld ausgegeben oder Datensätze geändert werden dürfen, darf nicht im Ermessen des Modells liegen.

Die Dokumentation und die unten aufgeführten Infrastrukturpreise wurden am 13. Oktober 2026 geprüft. Die Geschäftsbeispiele sind vorgeschlagene Prozessentwürfe, keine Berichte über reale Implementierungen oder Leistungsbenchmarks.

Wie funktioniert die Orchestrierung von KI-Agenten?

Die Orchestrierung legt fest, welcher Agent als Nächstes arbeitet, welche Informationen er erhält und was geschehen muss, bevor aus seinem Ergebnis eine Aktion werden darf. Ein Agent verbindet ein Modell mit Anweisungen und Tools. Der Orchestrator koordiniert diese Agenten: Er regelt Zuständigkeiten, gemeinsamen Zustand, zulässige Übergänge und Abbruchbedingungen.

Ein Agent zur Anfrageaufnahme kann aus einer unübersichtlichen Anfrage vielleicht schon ein brauchbares Briefing machen. Kommen Recherche und Texterstellung als weitere Agenten hinzu, entstehen neue Fragen. Wer löst Widersprüche in den Quellen auf? Welche Entwurfsfassung lag der freigebenden Person vor? Wurde die Nachricht versendet, obwohl der E-Mail-Dienst einen Timeout meldete? Diese Fragen muss der Prozessentwurf beantworten.

Das passende Muster richtet sich danach, welche Zuständigkeiten und Grenzen der Prozess braucht:

Die Muster lassen sich verschachteln. Ein persistenter Vorgangsworkflow kann einen Graphen aufrufen; ein Knoten, also ein Schritt in diesem Graphen, kann einen leitenden Agenten mit der Delegation von Recherche beauftragen. Jede Ebene braucht eine eigene Aufgabe. Zusätzliche Ebenen ohne klar abgegrenzte Verantwortung schaffen nur weitere Stellen für die Fehlersuche.

Gegenüber einem einzelnen Agenten ändern sich vor allem die Verantwortlichkeiten. Die operative Leitung braucht eine Warteschlange mit Vorgängen, zuständigen Personen und nächsten Aktionen. Die technische Leitung braucht gespeicherten Zustand und eine Ausführung, die sich nach Fehlern fortsetzen lässt. Wer eine Lösung einkauft, muss wissen, welche dieser Aufgaben der gewählte Dienst übernimmt und welche beim eigenen Unternehmen bleiben.

Leitender Agent mit Zuarbeitern: eine klare Gesamtverantwortung

Ein leitender Agent mit Zuarbeitern passt zu Aufgaben, die Spezialwissen erfordern, aber eine schlüssige Gesamtantwort brauchen. Das ähnelt einer Person, die ein Angebot verantwortet, dafür Belege bei Kollegen einholt und anschließend das Angebot zusammenstellt. Die Kollegen leisten ihren Beitrag; sie machen dem Kunden keine eigenständigen Zusagen.

Bei einer Anfrage aus dem Vertriebsinnendienst kann der leitende Agent eine Kundenrecherche und eine interne Prüfung der Produkteignung beauftragen. Aus deren Ergebnissen erstellt er dann ein Briefing für den Angebotsentwurf.

1. 1

   Ziel und Befugnisse des leitenden Agenten festlegen

   Das Ziel ist ein Angebotsentwurf mit belastbaren Belegen. Erlaubt sind Recherche und Entwurf. Das Versenden des Angebots, Rabattzusagen und Änderungen am Kundendatensatz bleiben gesonderte Aktionen.

2. 2

   Klar begrenzte Rechercheaufträge vergeben

   Jeder Zuarbeiter erhält die relevanten Quellen, erlaubten Tools, das erwartete Ausgabeformat und eine Abbruchregel. Unabhängige Recherchen können parallel laufen. Hängt eine Aufgabe tatsächlich vom Ergebnis einer anderen ab, muss sie darauf warten.

3. 3

   Belege zurückgeben und Ergebnisse zusammenführen

   Gefordert sind Quellenverweise, Erkenntnisse und offene Fragen. Der leitende Agent klärt Widersprüche und erstellt den Entwurf. Eine fehlende Quelle bleibt eine fehlende Quelle; auch eine Zusammenfassung darf daraus keine gesicherte Aussage machen.

4. 4

   Das Arbeitsergebnis zur Freigabe vorlegen

   Die für den Kunden verantwortliche Person prüft Nachricht, Empfänger und Zusagen. Ein von der Anwendung gesteuerter Versandschritt versendet ausschließlich die freigegebene Fassung.

Claude Agent SDK, die programmierbare Agentenlaufzeit von Anthropic, setzt dieses Muster mit Subagenten um: eigenständigen Agenteninstanzen mit eigenen Anweisungen, eigenem Kontext und eigenem Toolzugriff. Sie werden über die Option agents definiert; der Hauptagent ruft sie über das Tool Agent auf. Ein regulärer Subagent ohne Fork erhält den Gesprächsverlauf des übergeordneten Agenten nicht. Sein Aufgaben-Prompt muss daher den benötigten Kontext enthalten. Der übergeordnete Agent erhält den Abschlussbericht. Dokumentation zu Claude-Subagenten.

Eine verbindliche Vorgabe für Belege schafft hier die nötige Grenze. Ein Rechercheagent kann eine Empfehlung zusammen mit den stützenden Quellenpassagen liefern. Die Grenze des Musters: In einem isolierten Kontext kann auch eine entscheidende Kundenanforderung fehlen. Diese muss ausdrücklich mitgegeben werden; die zugrunde liegenden Unterlagen müssen für die Prüfung verfügbar bleiben.

CrewAI, ein Framework für rollenbasierte Agenten und Aufgaben, bietet einen hierarchischen Prozess mit manager_llm oder manager_agent. Der Manager plant, delegiert und prüft Aufgabenergebnisse. Ein sequenzieller Prozess arbeitet dagegen die Aufgabenliste ab und nutzt frühere Ergebnisse als Kontext. Dokumentation zu CrewAI-Prozessen.

Die Hierarchie passt, wenn die Arbeitsverteilung Abwägungen erfordert. Muss die Recherche immer vor dem Entwurf stattfinden, lässt sich eine explizite Abfolge leichter prüfen. Die Grenze des Musters: Auch die Prüfung durch den Manager bleibt ein automatisiertes Urteil. Die Aufgabenoption human_input von CrewAI fordert eine menschliche Prüfung der endgültigen Antwort an. Recherche- und Entwurfsaufgaben sollten deshalb nur Leserechte erhalten, damit diese Prüfung nicht erst nach einem folgenreichen Schreibzugriff stattfindet. Dokumentation zu CrewAI-Aufgaben.

Übergaben: Der nächste Spezialist übernimmt die Verantwortung

Eine Übergabe ist sinnvoll, wenn ein anderer Spezialist die nächste Antwort oder einen weiteren Arbeitszweig verantworten soll. Das entspricht der Übergabe eines Supportfalls an die Abrechnung samt Vorgangsakte. Es ist etwas anderes, als der Abrechnung eine Frage zu stellen und selbst für den Fall zuständig zu bleiben.

OpenAI Agents SDK, eine Bibliothek für Agentenanwendungen, bildet diesen Unterschied ausdrücklich ab: Handoffs übertragen die Kontrolle an einen Spezialisten. Werden Agenten dagegen als Tools bereitgestellt, bleibt der Manager für die Antwort verantwortlich. Letzteres unterstützt in JavaScript agent.asTool(). Übergaben können strukturierte Metadaten oder einen gefilterten Verlauf enthalten. OpenAI-Dokumentation zur Orchestrierung.

Für einen Posteingang im Kundenservice bietet sich folgende Abfolge an:

1. Der Agent zur Anfrageaufnahme erkennt eine strittige Rechnung und sammelt die zugehörigen Kundenkonto- und Rechnungsreferenzen.
2. Er übergibt den Vorgang an den Abrechnungsspezialisten: mit dem Kundenanliegen, gesicherten Fakten, offenen Fragen und den zulässigen nächsten Aktionen.
3. Der Abrechnungsspezialist prüft den Sachverhalt und entwirft eine Lösung. Er verantwortet die nächste Antwort, statt lediglich einen Recherchebericht an die Anfrageaufnahme zurückzugeben.
4. Eine Person genehmigt jede vorgeschlagene Erstattung oder Kontoänderung, bevor das entsprechende Tool sie ausführt.

Die Grenze des Musters: Eine Übergabe überträgt die Kontrolle, aber keine geschäftliche Befugnis. Ein Agent darf nicht allein deshalb eine Erstattung veranlassen, weil die Anfrageaufnahme ihm den Fall zugewiesen hat. Die Aktionsregeln müssen dort durchgesetzt werden, wo das Erstattungstool ausgeführt wird.

Ebenso muss feststehen, ob ein Spezialist den Vorgang zurückgeben darf. Eine ausdrückliche Eskalation mit Begründung sollte möglich sein; wiederholte Übergaben brauchen eine Obergrenze. Sonst wandert eine unklare Anfrage zwischen Spezialisten hin und her, verbraucht Modellaufrufe und kommt nicht voran.

Der Freigabeablauf des SDK liefert Unterbrechungen und einen fortsetzbaren Zustand zur Prüfung durch die Anwendung zurück. Bei verzögerten Entscheidungen muss dieser Zustand gespeichert und derselbe Lauf fortgesetzt werden. Eingabe-Guardrails greifen beim ersten Agenten, Ausgabe-Guardrails beim Agenten mit der endgültigen Ausgabe. Sensible Tools brauchen deshalb eigene Prüfungen; die Kontrollen an den äußeren Grenzen prüfen nicht automatisch jede interne Aktion. OpenAI-Dokumentation zur menschlichen Prüfung.

Graph mit Checkpoints: zulässige Schritte ausdrücklich festlegen

Ein Graph passt, wenn die erlaubten Pfade wichtiger sind als die Frage, welcher Agent den Plan improvisiert. Ein Graph besteht aus Schritten, die durch Regeln verbunden sind. Ein Checkpoint hält den Fortschritt fest, damit der Prozess pausieren und später fortgesetzt werden kann.

LangGraph, ein Framework für zustandsbehaftete Agentenworkflows, unterstützt explizite Ablaufpfade einschließlich Verzweigungen und paralleler Arbeit. Seine Checkpointer speichern den Graphenzustand für einen Thread. Über interrupt() lässt sich die Ausführung für externe Eingaben anhalten. Der unterbrochene Thread wird mit Command(resume=...) fortgesetzt. Workflow-Muster in LangGraph, Dokumentation zu Unterbrechungen.

Für ein Einkaufsteam, das eine Lieferantenempfehlung vorbereitet:

1. 1

   Den Vorgang als strukturierten Zustand speichern

   Anfrage, Quellenverweise, fehlende Informationen, Ablageort des Entwurfs und Prüfstatus gehören in benannte Felder. Ein Gesprächsprotokoll kann den Vorgang ergänzen, darf aber nicht der einzige Ort sein, an dem sich der aktuelle Status findet.

2. 2

   Die erlaubten Pfade festlegen

   Sind die Pflichtfelder vorhanden, geht die Anfrageaufnahme in die Recherche über. Fehlen Informationen, geht der Vorgang an die anfragende Person zurück. Die Recherche liefert die Grundlage für den Entwurf; eine Belegprüfung kann den Vorgang zur gezielten Nachrecherche zurückführen.

3. 3

   Checkpoint setzen und zur Prüfung pausieren

   Die vorgeschlagene Empfehlung wird gespeichert und der Ablauf vor allen freigabeabhängigen Arbeiten unterbrochen. Die zuständige Person im Einkauf prüft die konkrete Fassung, die Belege und die beantragte Aktion.

4. 4

   Auf einem zulässigen Pfad fortfahren

   Eine Freigabe erlaubt die Einreichung. Änderungswünsche führen zurück zum Entwurf und machen die bisherige Freigabe ungültig. Eine Ablehnung schließt den Vorgang mit dokumentierter Begründung.

Die Grenze des Musters: Wird eine LangGraph-Unterbrechung fortgesetzt, startet der betreffende Knoten wieder von vorn. Code vor der Unterbrechung läuft erneut. Ein folgenreicher Schreibzugriff gehört daher in einen gesondert kontrollierten Schritt. Wiederholbare Operationen müssen idempotent sein: Dieselbe logische Anfrage darf bei erneuter Ausführung keine zusätzliche Wirkung erzeugen. Regeln für Unterbrechungen in LangGraph.

Ein Knoten, der beispielsweise einen Lieferantendatensatz übermittelt und erst danach um Freigabe bittet, hat diese Grenze bereits überschritten. Beim Fortsetzen kann er den Datensatz zudem erneut übermitteln. Zuerst muss die Änderung vorbereitet, dann freigegeben und schließlich mit einer stabilen Aktionskennung ausgeführt werden.

Für den Produktivbetrieb braucht es dauerhaften Checkpoint-Speicher. Die In-Memory-Speicher von LangGraph verlieren ihre Checkpoints beim Neustart des Prozesses. Eine beständige Thread-Kennung und ein in einer Datenbank gespeicherter Zustand gehören zum Wiederherstellungskonzept. LangGraph-Dokumentation zur Persistenz.

Persistente Workflows: den Vorgang über Agentenaufrufe hinweg erhalten

Ein persistenter Workflow ist dann sinnvoll, wenn der Geschäftsprozess das Ende eines Agentenaufrufs, den Neustart eines Workers oder eine verspätete externe Antwort überstehen muss. Er steuert den gesamten Lebenszyklus des Vorgangs: starten, warten, erneut versuchen, fortsetzen, abschließen oder eskalieren. Ein Agent wirkt innerhalb dieses Lebenszyklus mit.

Cloudflare Workflows, ein Dienst für die dauerhafte Ausführung mehrstufiger Abläufe, bietet persistierte Schritte und konfigurierbare Wiederholungsversuche. step.do führt Arbeit aus, step.waitForEvent wartet auf eine externe Entscheidung und instance.sendEvent übermittelt diese Entscheidung an die wartende Instanz. Cloudflare Workflows, Dokumentation zu Ereignissen.

Für ein operatives Team, das eine individuelle Serviceanfrage bearbeitet:

1. Beim Eingang der Anfrage werden ein Vorgangsdatensatz und eine stabile Workflow-Kennung angelegt.
2. Der Rechercheagent wird aufgerufen und seine Belegsammlung gespeichert. Anschließend erhält der Entwurfsagent diese Unterlagen.
3. Die vorgeschlagene Antwort wird gespeichert. Der Workflow wartet auf das Freigabeereignis der operativen Leitung. Die Freigabeoberfläche kennzeichnet sowohl den Vorgang als auch die Fassung des Arbeitsergebnisses.
4. Die Entscheidung wird validiert; der genehmigte Versand oder die Datensatzänderung erfolgt in einem separaten Schritt.
5. Die Bestätigung des externen Systems wird erfasst und der Vorgang abgeschlossen. Ist der Abschluss ungewiss, wird zunächst der Status mit dem externen System abgeglichen, bevor ein weiterer Schreibzugriff erfolgt.

Die Grenze des Musters: Eine persistente Prozesssteuerung macht die Aktion eines externen Dienstes nicht automatisch gefahrlos wiederholbar. Cloudflare empfiehlt ausdrücklich idempotente API-Aufrufe, kleinteilige Schritte und deterministische Schrittnamen und warnt vor Seiteneffekten außerhalb von step.do. Hat ein Dienst den Versand angenommen, aber seine Antwort geht verloren, kann ein erneuter Versuch ohne Deduplizierung die Nachricht noch einmal versenden. Regeln für Workflows.

Wiederholungsversuche sollten für vorübergehende Fehler konfiguriert werden, die sich ohne Änderung der Anfrage beheben können. Eine fehlgeschlagene Authentifizierung, eine verweigerte Freigabe oder eine ungültige Geschäftsanweisung erfordert in der Regel einen Eingriff. Cloudflare bietet eine Retry-Konfiguration und NonRetryableError für Fehler, nach denen keine weiteren Versuche erfolgen sollen. Dokumentation zu Wiederholungsversuchen.

Eine LangGraph-Anwendung mit dauerhaften Checkpoints kann sich bereits nach Fehlern wiederherstellen. Eine zusätzliche Workflow-Engine ist sinnvoll, wenn sie einen umfassenderen Lebenszyklus über Dienste, Callbacks und Agentenlaufzeiten hinweg verantwortet. Beide Ebenen sollten nicht unabhängig voneinander dieselbe kostenpflichtige Operation oder Aktion mit Seiteneffekten wiederholen. Diese Abgrenzung vertieft der Beitrag zu Managed-Agent-Ergebnissen, Webhooks und dem Cloudflare-Workflow.

Menschliche Freigabe unmittelbar vor der Aktion

Eine Person sollte die konkrete folgenreiche Aktion genehmigen, bevor sie ausgeführt wird. Die Prüfung eines gut formulierten Entwurfs reicht nicht aus, wenn ein anderer Agent anschließend Empfänger, Betrag oder Anhang ändern kann.

Bei einem Angebot sollte die Prüfoberfläche Empfänger, endgültige Nachricht, angehängtes Dokument, geschäftliche Zusagen und die Belege für unsichere Aussagen zeigen. Der Freigabedatensatz muss die Identität der prüfenden Person mit genau dieser Fassung und diesen Aktionsparametern verknüpfen.

Die ausführende Komponente muss diesen Datensatz unmittelbar vor der Aktion prüfen. Wurden Entwurf oder Ziel nach der Freigabe geändert, geht der Vorgang zurück in die Prüfung. Maßgeblich ist eine ausdrückliche Freigabeentscheidung der berechtigten Person. Kommentare und Änderungsvorschläge sind getrennt davon zu behandeln.

CrewAI Flows können mit @persist Zustand speichern und mit @human_feedback für Rückmeldungen pausieren. Bei folgenreichen Aktionen ist ein Detail entscheidend: Sind emit-Ergebnisse konfiguriert, interpretiert ein Sprachmodell frei formulierte Rückmeldungen und ordnet sie einem Ergebnis zu. Die Autorisierung sollte deshalb über ein separat validiertes Freigabefeld erfolgen. Ein interpretierter Kommentar darf nicht die einzige Handlungsbefugnis sein. Dokumentation zu CrewAI Flows.

Wo der Prozess einen weiteren Kauf auslösen kann, braucht es eine weitere Berechtigungsgrenze. Eine fehlgeschlagene Verbindung erneut aufzubauen und ein neues Ergebnis einzukaufen, weil dem Agenten das fertige Ergebnis nicht gefällt, sind unterschiedliche Entscheidungen. Für Letzteres braucht es einen festgelegten Ausgabenrahmen oder eine neue Freigabe. Der Beitrag zu menschlichen Freigaben für Wiederholungsversuche von KI-Agenten behandelt diesen speziellen Fehlerfall.

Was protokolliert und begrenzt werden muss

Die Protokolle müssen den Vorgang nachvollziehbar machen; Obergrenzen müssen greifen, bevor weitere Arbeit beginnt. Eine überzeugend formulierte Abschlussantwort erklärt nicht, warum ein Prozess das falsche Dokument versendet oder sein Budget überschritten hat.

Vorgangsdatensatz und Ausführungsereignisse sollten diese Feldgruppen enthalten:

• Identität und Zuordnung: Vorgangs-ID, Workflow-/Lauf-ID, IDs über- und untergeordneter Läufe, Agentenrolle, aktueller Schritt und Versuch. So lässt sich ein Fehler eines Zuarbeiters der geschäftlichen Anfrage zuordnen.
• Eingaben und Konfiguration: Verweise und Versionen der Eingabeartefakte, Modellkennung, Prompt-/Konfigurationsversion und erlaubte Tools. Damit wird sichtbar, was sich zwischen Läufen geändert hat.
• Entscheidungen und Belege: Routingentscheidung, gewähltes Ziel, Quellenverweise, Validierungsergebnisse und fehlende Informationen. Festzuhalten sind beobachtbare Entscheidungen und knappe Begründungen; die Nachvollziehbarkeit darf nicht vom internen Denkprozess des Modells abhängen.
• Freigabe: prüfende Person, Entscheidung, Zeitstempel, Prüfsumme des Artefakts, Aktionsparameter und Ablaufzeitpunkt. Die Prüfsumme ist ein Fingerabdruck des geprüften Inhalts.
• Aktionen und Wiederherstellung: Toolname, um sensible Angaben bereinigte Parameter, Aktions-/Idempotenzschlüssel, externe Anfrage-ID, Bestätigung, Fehlerkategorie und geplanter Wiederholungsversuch. Ist das Ergebnis unbekannt, muss ein ausdrücklich ungewisser Status erhalten bleiben.
• Verbrauch und Ergebnis: Kategorien der Modelltokens, geschätzte und abgeglichene Ausgaben, Nutzung kostenpflichtiger Tools, verstrichene Zeit, Wartezeit auf Prüfung, Abschlussstatus und die Information, ob eine Person das Ergebnis akzeptiert hat.

Der Lesezugriff auf diese Protokolle muss begrenzt sein. Zugangsdaten gehören nicht hinein, Kundendaten nur im nötigen Umfang. Wo eine vollständige Kopie unnötige Einblicke ermöglichen würde, sollten Verweise auf zugriffsgeschützte Artefakte verwendet werden.

Das Tracing im OpenAI Agents SDK erfasst Modellaufrufe, Toolaufrufe, Handoffs und Guardrails. Diese technischen Traces sollten mit dem Vorgangsdatensatz verknüpft werden. Der Trace allein darf jedoch nicht geschäftlich verbindlich darüber entscheiden, ob eine Kundenaktion freigegeben war. OpenAI-Dokumentation zum Tracing.

Tools für KI-Agenten brauchen durchsetzbare Obergrenzen

Festzulegen sind Grenzen für Gesamtausgaben pro Vorgang, Agentenrunden, Toolaufrufe, parallele Zuarbeiter, Delegationstiefe, Anzahl der Übergaben, Wiederholungsversuche und Gesamtlaufzeit. Die Frist für die aktive Ausführung ist von der Frist für die menschliche Prüfung zu trennen. Die Werte richten sich nach den für das Unternehmen vertretbaren Kosten und Verzögerungen; einen universell sicheren Standardwert gibt es nicht.

Vor dem Start paralleler Arbeit muss Budget reserviert und nach Abschluss jedes Aufrufs abgeglichen werden. Sonst kann jeder Zuarbeiter dasselbe Restbudget sehen und unabhängig ausgeben. Auch fortgesetzte Läufe sind demselben Vorgangsbudget zuzurechnen.

Claude Agent SDK bietet Ausgabenbegrenzungen für Aufrufe, darunter maxBudgetUsd in TypeScript und max_budget_usd in Python, sowie Kontrollen für Tiefe und Parallelität von Subagenten. Welche installierte Version dafür erforderlich ist, steht in der Subagenten-Dokumentation.

Entscheidend ist, was jeweils mitgezählt wird: Das Feld usage schließt Subagentenaktivität aus, während modelUsage beziehungsweise model_usage sie einschließt. total_cost_usd enthält Subagenten, ist aber eine clientseitige Schätzung. Die Ausgabenobergrenze eines Aufrufs gilt für dessen eigene Ausgaben, nicht für frühere Ausgaben, die aus einer fortgesetzten Sitzung wiederhergestellt wurden. Deshalb braucht es ein Kostenbuch auf Vorgangsebene; Schätzungen müssen mit den maßgeblichen Verbrauchsdaten abgeglichen werden. Claude-Dokumentation zur Kostenerfassung.

Eine SDK-Budgeteinstellung garantiert außerdem keine exakt eingehaltene Obergrenze der endgültigen Rechnung: Das dokumentierte Ergebnis eines begrenzten Laufs kann den Schwellenwert erreichen oder überschreiten. Für bereits laufende Arbeit muss Spielraum bleiben. Die Vergabe neuer Aufgaben muss stoppen, bevor der geschäftliche Ausgabenrahmen ausgeschöpft ist.

Für die Kosten zählt der gesamte Vorgang

Das Budget muss das abgeschlossene Geschäftsergebnis abdecken, einschließlich erfolgloser Arbeit und Prüfung. Mehr Agenten können unabhängige Recherchen beschleunigen. Sie können aber auch Kontext vervielfachen, zusätzliche Aufrufe zur Zusammenführung erfordern und Überarbeitungsschleifen erzeugen. Wirtschaftlich zählt, ob sich das akzeptierte Ergebnis so weit verbessert, dass es diese Mehrkosten rechtfertigt.

Für die monatliche Kalkulation gilt:

Prozesskosten = Modellnutzung + kostenpflichtige Tools + Workflow-Infrastruktur + Zustands- und Protokollspeicher + menschliche Prüfung + Betrieb.

Anschließend wird durch die Zahl der freigegebenen Ergebnisse geteilt, nicht durch die Zahl der Agentenläufe. Fehlgeschlagene Vorgänge und verworfene Entwürfe gehören weiterhin in den Zähler. Der Vergleich mit dem bisherigen Prozess muss dieselben Abnahmekriterien und Annahmen zu Personalkosten verwenden. Ohne diese Angaben lässt sich kein belastbarer prozentualer Einspareffekt ableiten.

Als konkreten Anhaltspunkt für die Infrastruktur nennt Cloudflare folgende Gebühren:

Quellen: Workers-Preise und Workflows-Preise. Der Mindestbetrag des Kontos deckt Infrastruktur ab und ist kein Komplettpreis für Agenten. Anfragen, CPU-Zeit (Prozessorarbeit), Modellaufrufe und weitere Dienste müssen zusätzlich berücksichtigt werden. Laut Abrechnungsankündigung beginnt die Abrechnung von Schritten und Speicher frühestens am 10. August 2026. Die öffentliche Formulierung bestätigt nicht, ob sie für ein bestimmtes Konto bereits aktiviert wurde.

Unsere Rechnung: Die veröffentlichten $0.80 geteilt durch 100,000 ergeben effektiv $0.000008 je zusätzlichem Schritt, vor weiteren Gebühren. Das ist eine Umrechnung des angegebenen Tarifs, keine Schätzung eines Arbeitsvolumens und keine gemessene Rechnung. Veröffentlichter Schritttarif.

Warten erfordert keine aktive Modellschleife. Laut Cloudflare verursachen Wartezeiten auf APIs, Schlafphasen und Leerlauf keine CPU-Zeit. Zustandsspeicher und Schrittzählung werden gesondert behandelt. Der Vorgang sollte gespeichert werden und auf ein Ereignis warten, statt einen Agenten wiederholt zu fragen, ob die freigebende Person schon geantwortet hat. Workflows-Preise.

Frameworks für Multi-Agenten-Systeme müssen zum Prozess passen

Zuerst werden die Zuständigkeiten der Koordination festgelegt, dann das Framework. Braucht es eine zusammengeführte Antwort, bleibt die Verantwortung bei einer Stelle. Soll der nächste Spezialist eigenständig handeln, wird die Verantwortung übergeben. Sind zulässige Übergänge entscheidend, eignet sich ein Graph. Muss die Arbeit über einen einzelnen Aufruf hinaus bestehen bleiben, kommt eine dauerhafte Steuerung des Lebenszyklus hinzu.

Der Vergleich der KI-Agenten-Frameworks hilft bei der Auswahl der einzelnen Frameworks. Geht es bereits konkret um expliziten Graphenzustand oder rollenbasierte Crews, führt LangGraph vs CrewAI weiter.

Die technische Leitung muss Persistenz, Ausführungsberechtigungen und die Verantwortung für die Wiederherstellung klar festlegen. Die operative Leitung definiert Abnahmekriterien, Freigabeberechtigte, Eskalation und zulässige Ausgaben. Beim Einkauf ist zu klären, wer diese Kontrollen betreibt, wo Datensätze liegen und wie ein pausierter Vorgang nach einem Fehler wieder aufgenommen wird.

Eine Plattform kann den Betrieb der Infrastruktur übernehmen. Sie kann nicht festlegen, was im jeweiligen Unternehmen als genehmigte Erstattung, belegte Angebotsaussage oder vertretbarer Zusatzkauf gilt.

Welche Versprechen zu weit gehen

Mehr Agenten sind kein Beleg für bessere Ergebnisse. Eigenständige Agenten sollten unterschiedliche Quellen, Tools oder Verantwortlichkeiten erhalten. Austauschbare Agenten immer wieder gegenseitig Kritik üben zu lassen, kann Budget verbrauchen, ohne neue Belege beizutragen.

Auch eine Graphendarstellung beweist keine zuverlässige Wiederaufnahme nach Fehlern. Was einen Fehler übersteht, bestimmen der gespeicherte Zustand, das Persistenz-Backend und das Verhalten bei erneuter Ausführung. Ebenso setzt ein Prompt wie „vor dem Versenden fragen“ keine Versandrichtlinie durch. Die ausführende Komponente muss die Berechtigung prüfen.

Modellgesteuerte Planung gehört schließlich in eine klar begrenzte Aufgabe. Ein Rechercheagent kann entscheiden, welche relevante Quelle er als Nächstes prüft. Ob private Daten offengelegt, Ausgaben genehmigt oder Kundennachrichten versendet werden dürfen, bestimmen die Zugriffs- und Freigaberegeln der Anwendung.

Der erste Schritt für Montag

Am Anfang steht ein Prozess und die kleinste zusätzliche Grenze, die er braucht. Der bereits funktionierende Agent bleibt bestehen. Seine Eingabe, sein Arbeitsergebnis, seine Tools, die zuständige Person sowie Erfolgs- und Abbruchbedingungen werden festgehalten. Anschließend kommt die fehlende Zuständigkeit für Recherche oder Entwurf hinzu.

Bevor kundenseitig wirksame Schreibzugriffe aktiviert werden, müssen Fehlerfälle mit repräsentativen, nicht sensiblen Eingaben erprobt werden: die Ausführung nach dem Speichern eines Entwurfs unterbrechen, eine Freigabe doppelt zustellen, ein Angebot ablehnen, ein freigegebenes Artefakt verändern, das Budget ausschöpfen und einen externen Schreibzugriff simulieren, dessen Antwort verloren geht. Zu prüfen ist, ob der Vorgang einen dokumentierten Zustand mit klarer nächster Aktion erreicht.

Handlungsbedarf besteht, wenn Arbeit zwischen Spezialisten wechselt, auf Freigaben wartet oder zuverlässig wiederhergestellt werden muss. Liegt das eigentliche Problem bei schlechten Quelldaten oder unklaren Abnahmekriterien, sollten zusätzliche Agenten warten. Ein zuverlässiger Prozess mit einem einzelnen Agenten, der keine solche Grenze benötigt, kann unverändert bleiben.

Häufige Fragen aus der Prozessverantwortung

Braucht es eine Plattform zur Orchestrierung von KI-Agenten, wenn ein Agent bereits funktioniert?

Nur wenn Koordination oder Betriebsfunktionen fehlen, die die bestehende Anwendung nicht bietet. Zuerst muss die fehlende Zuständigkeit benannt werden: Verantwortung eines Spezialisten, gespeicherter Fortschritt, verzögerte Freigabe oder Wiederherstellung. Diese Anforderung entscheidet darüber, ob eine Bibliothek, ein Workflow-Dienst oder etwas Anwendungscode hinzukommen sollte.

Lassen sich diese Muster im selben Prozess kombinieren?

Ja. Ein persistenter Workflow kann den Vorgang verantworten, während ein Graph die Prüfpfade steuert und ein leitender Agent Recherche delegiert. Jede Ebene braucht eine klare Aufgabe. Sich überschneidende Wiederholungsregeln für dieselbe Operation sollten vermieden werden.

Erlaubt die Freigabe eines Entwurfs auch einen weiteren kostenpflichtigen Versuch?

Nur wenn die Freigabe diesen Ausgabenrahmen ausdrücklich einschließt. Die Freigabe zur Nutzung eines Artefakts und die Erlaubnis zum Kauf eines weiteren Versuchs sollten getrennt dokumentiert werden. Auch ein geänderter Entwurf muss erneut geprüft werden, bevor die damit verbundene folgenreiche Aktion ausgeführt wird.

Was passiert, wenn die freigebende Person nicht antwortet?

Die ausstehende Entscheidung läuft nach einer festgelegten Regel ab. Die zuständige Person wird benachrichtigt, der Vorgang angehalten oder geschlossen. Für eine spätere Prüfung muss genügend Kontext gespeichert bleiben. Schweigen darf nicht zur automatischen Freigabe werden.

Den Newsletter abonnieren und praktische Anleitungen zum Aufbau und Betrieb von Geschäftsworkflows mit KI erhalten.