Workflow-Runs

Ein Workflow ist ein Programm, das ein Agent schreibt, um viele Agenten auszuführen und zu kombinieren, was sie zurückgeben. Ein „workflow run" (Workflow-Run), kurz Run, ist die Ausführung eines Workflows. „Dynamic workflows" (dynamische Workflows) ist die Funktion, mit der ein Agent Workflows schreiben und Runs starten kann. Du schaltest sie mit der Einstellung workflows im multiagent-Block des Agenten ein oder aus.

Der Server führt einen Workflow im Hintergrund aus. Seine Agenten arbeiten in Session-Threads, die der Server erstellt, sobald der Workflow sie benötigt. Du verfolgst Runs im Event-Stream der Session. Nur der Agent startet einen Run. Kein Event, das du sendest, beendet einen; das Archivieren der Session kann es.

Wie dynamische Workflows funktionieren

Der Agent, den die Session ausführt, schreibt jeden Workflow für die Arbeit, die du beschreibst. Ein Workflow ist ein Programm: Er führt andere Agenten aus, sammelt, was jeder zurückgibt, und kombiniert die Ergebnisse. So kann der Agent eine Aufgabe übernehmen, die für eine einzelne Konversation zu groß ist, etwa die Prüfung von Hunderten von Dokumenten. Während eines Runs kann der Agent weiterarbeiten oder seinen Turn beenden, und er kann den Stand des Runs prüfen.

Das Diagramm zeigt ein Beispiel. Jeder Workflow, den der Agent schreibt, hat seine eigenen Phasen und Agenten. Ein Run hat diese Ebenen:

• Workflow-Run: Der Server führt den Workflow im Hintergrund als einen Workflow-Run aus. Eine Session kann mehrere Runs gleichzeitig offen haben.
• Phasen: Ein Workflow kann seine Arbeit in Phasen aufteilen. Eine Phase ist ein benannter Abschnitt des Runs, etwa „Read the contracts" (Verträge lesen). Du verfolgst den Fortschritt eines Runs anhand seiner Phasen-Events.
• Agent-Threads: In einer Phase führt das Programm Agenten aus. Jeder Agent arbeitet in seinem eigenen Session-Thread, an einem Prompt, den das Programm geschrieben hat. Ein Agent in einem Run kann ein Inline-Agent sein, den das Programm selbst definiert, oder ein vordefinierter Agent, den du in workflows.predefined_agents aufführst. Was jeder Thread zeigt, erfährst du unter Die Threads eines Runs.

Das Programm kann Folgendes tun:

• Agenten gleichzeitig ausführen: Das Programm kann viele Agenten gleichzeitig ausführen, was als „fanning out" (Auffächern) bezeichnet wird. Im Diagramm lesen drei Agenten in der ersten Phase Verträge.
• Ergebnisse von einem Agenten an einen anderen weitergeben: Jeder Agent gibt sein Ergebnis an das Programm zurück. Das Programm kann dieses Ergebnis an einen anderen Agenten weitergeben. Im Diagramm arbeitet der Agent in der zweiten Phase mit dem, was die ersten drei zurückgegeben haben. Die Agenten eines Runs arbeiten außerdem mit denselben Dateien, in der Sandbox der Session.
• Den nächsten Schritt selbst gehen: Das Ergebnis eines Agenten geht an das Programm, nicht an den Agenten, den die Session ausführt. Das Programm bestimmt, welche Agenten als Nächstes laufen, und schreibt ihre Prompts.
• Wiederholen und wählen: Innerhalb einer Phase kann das Programm Arbeit wiederholen und seinen nächsten Schritt anhand dessen wählen, was ein Agent zurückgegeben hat. Zum Beispiel kann es einen Entwurf überarbeiten lassen, bis er eine Prüfung besteht oder eine festgelegte Anzahl von Runden aufgebraucht ist. Im Diagramm kann das Programm einen Schritt innerhalb der zweiten Phase wiederholen.
• Einen fehlgeschlagenen Agenten behandeln: Wenn einer seiner Agenten fehlschlägt, kann das Programm den Fehler behandeln oder ihn den Run beenden lassen.

Wenn der Run endet, bekommt der Agent, den die Session ausführt, einen Turn, um zu lesen, was der Run getan hat. Er kann dir dann antworten oder einen weiteren Run starten. Run-Events listet die Fälle auf, in denen dieser Turn später oder gar nicht kommt.

Du kannst steuern, wie ein Run die Arbeit erledigt, zum Beispiel wie er die Arbeit aufteilt und was er tut, wenn ein Agent fehlschlägt. Siehe Dem Agenten mitteilen, wann er einen Run verwenden soll.

Wie ein Run seine Zustände durchläuft

Ein Run startet als laufend oder als inaktiv. Das Erreichen des Budgets zum Beispiel pausiert einen laufenden Run, wodurch er inaktiv wird; das Erhöhen oder Entfernen des Budgets lässt ihn dann wieder laufen, es sei denn, eine Unterbrechung hat ihn ebenfalls pausiert. Ein laufender Run endet, wenn sein Workflow fertig ist, der Agent ihn stoppt, er fehlschlägt, seine Lebensdauer abläuft oder die Session archiviert wird. Auch ein inaktiver Run kann enden, zum Beispiel wenn der Agent ihn stoppt oder die Session archiviert wird.

Ein Run ist offen von seinem workflow_run.created-Event bis zu seinem workflow_run.status_ended-Event, egal ob er läuft oder inaktiv ist. Ein Run ist inaktiv, während er pausiert ist, zum Beispiel beim Budget der Session. Die Lebensdauer eines Runs beträgt standardmäßig 24 Stunden. Der Agent kann beim Starten des Runs eine kürzere Lebensdauer festlegen. Zeit, die ein Run mit Warten auf deinen Client verbringt, zählt zu dieser Lebensdauer. Eine Pause hält die Lebensdauer eines Runs nicht an, sodass ein Run, der pausiert bleibt, mit timeout_error enden kann. Die folgenden Events melden den Start eines Runs, seine Phasen und sein Ende. Eine Pause beim Budget sendet ebenfalls eines. Eine Pause nach einer Unterbrechung sendet möglicherweise keines. Jedes workflow_run.*-Event enthält workflow_run_id, das nur bei einem workflow_run.error, bei dem kein Run erstellt wurde, null ist.

Run-Events

Run-Events kommen im Event-Stream der Session an, also im Stream des primären Threads, und das Auflisten der Events der Session gibt sie ebenfalls zurück. Run-Events lösen keine Webhooks aus. Status-Events aus den Threads des Runs kommen im selben Stream an. Jedes nennt seinen Thread in session_thread_id, und die Threads eines Runs sind diejenigen, deren session.thread_created-Event die workflow_run_id des Runs hatte.

Ein Fehlerergebnis sieht so aus: {"type": "error", "error": {"type": "timeout_error", "message": "..."}}, wobei message sicher protokolliert werden kann. Behandle einen unbekannten result.type als Run, der auf andere Weise geendet hat, und einen unbekannten error.type als Fehler. Wenn etwas fehlschlägt, von dem die Session abhängt, etwa das Modell, ein MCP-Server, Anmeldedaten oder die Abrechnung, bekommt der Stream des fehlschlagenden Threads einen session.error. Das beendet einen Run nicht von selbst. Wenn es aber einen der Threads des Runs fehlschlagen lässt und der Workflow dadurch den Run enden lässt, endet der Run mit program_error.

Zum Beispiel fragst du den Vertragsprüfungs-Agenten, welche von 300 Verträgen eine Change-of-Control-Klausel enthalten, und der Agent startet einen Run:

1. workflow_run.created benennt den Run „Find change-of-control clauses" und listet die Phasen „Read the contracts" und „Reconcile the findings" in phases auf. Dann folgt workflow_run.status_running.
2. Phasen-Events markieren jede Phase, und jeder Thread, den der Run erstellt, sendet session.thread_created mit der workflow_run_id des Runs.
3. workflow_run.status_ended kommt mit result: {"type": "completed"} an.
4. Der Agent antwortet: „41 der 300 Verträge enthalten eine", und session.status_idle kommt mit end_turn an.

Das erste Event des Runs listet seine Phasen auf:

{
  "type": "workflow_run.created",
  "id": "sevt_01abc...",
  "workflow_run_id": "wrun_01J8XkN5uT3vHpLqRfWdY2",
  "name": "Find change-of-control clauses",
  "description": "Reads each contract and lists those that have the clause.",
  "phases": [
    {
      "id": "wrph_01Kd3a1f3",
      "name": "Read the contracts",
      "description": "Reads each contract for the clause."
    },
    { "id": "wrph_01Kd3b7c9", "name": "Reconcile the findings", "description": null }
  ],
  "processed_at": "2026-10-09T14:01:45Z"
}

Jedes Phasen-Event nennt seine Phase über workflow_run_phase_id. Das ist eine id in phases, aber die API garantiert das nicht:

{
  "type": "workflow_run.phase_started",
  "id": "sevt_01def...",
  "workflow_run_id": "wrun_01J8XkN5uT3vHpLqRfWdY2",
  "workflow_run_phase_id": "wrph_01Kd3a1f3",
  "processed_at": "2026-10-09T14:01:46Z"
}

Das letzte Event des Runs meldet, wie er geendet hat:

{
  "type": "workflow_run.status_ended",
  "id": "sevt_01ghi...",
  "workflow_run_id": "wrun_01J8XkN5uT3vHpLqRfWdY2",
  "result": { "type": "completed" },
  "processed_at": "2026-10-09T14:09:12Z"
}

Die Threads eines Runs

Jeder Agent in einem Run arbeitet in seinem eigenen Session-Thread, den der Server erstellt, sobald der Workflow ihn benötigt. Du kannst die Threads eines Runs wie jeden Kind-Thread auflisten, lesen und streamen und ihre Tool-Aufrufe aus dem primären Stream beantworten. Um sie zu stoppen, bitte den Agenten, den Run zu stoppen (siehe Eine Session mit offenen Runs unterbrechen). Du kannst keinen über seine ID stoppen oder einen archivieren, während sein Run offen ist.

• Gruppierung: Ein Thread eines Runs trägt die workflow_run_id des Runs, ebenso wie das session.thread_created-Event, das ihn ankündigt. Bei anderen Threads und den session.thread_created-Events, die sie ankündigen, ist workflow_run_id auf null gesetzt.
• Agent: agent zeigt den Agenten, den der Thread ausführt. Für einen Agenten, den du in multiagent.workflows.predefined_agents aufgeführt hast, enthält agent die id und version dieses Agenten, wie beim Thread eines Subagenten, den du aufgeführt hast. Für einen Agenten, den der Workflow definiert (einen Inline-Agenten), hat agent den type inline und keine id oder version. Er hat den System-Prompt, den der Workflow geschrieben hat, nicht den des Session-Agenten. Er hat außerdem den Namen und die Beschreibung, die der Workflow ihm gegeben hat; der Server vergibt einen Namen, wenn der Workflow keinen angegeben hat. Er verwendet das Modell des Session-Agenten, also des Agenten, den die Session ausführt. Seine Tools, MCP-Server und Skills sind eine Teilmenge derer des Session-Agenten. Er bekommt alle davon, aber die API garantiert das nicht. Seine Tools behalten ihre Berechtigungsrichtlinien.
• Was die Threads teilen: Die Threads eines Runs arbeiten in der Sandbox der Session, sodass jeder Thread mit denselben Dateien arbeitet. Dazu gehören die Dateien eines Memory Stores, den die Session einbindet. Ein Agent, den der Workflow definiert, verwendet seine MCP-Server mit den Anmeldedaten, die die Session für sie auflöst. Jeder Thread hat seinen eigenen Gesprächsverlauf.
• Events: Die Events session.thread_created, session.thread_status_running, session.thread_status_idle und session.thread_status_terminated eines Run-Threads kommen auch im primären Stream an (siehe Run-Events). Seine Nachrichten-Events bleiben in seinem eigenen Stream. Seine Thread-Webhooks werden wie bei jedem Kind-Thread gesendet. Was der eigene Stream des Threads aufzeichnet, erfährst du unter Session-Thread-Events.
• Phasen: Kein Event und kein Feld sagt, in welcher Phase ein Thread arbeitet, und Threads eines Runs können denselben agent_name haben. Verfolge den Fortschritt eines Runs anhand seiner Phasen-Events und unterscheide seine Threads über session_thread_id.
• Thread-Limit: Die Threads eines Runs sind vom Kind-Thread-Limit der Session ausgenommen.
• Runs starten: Nur der Agent im primären Thread der Session startet Runs. Ein Agent, der im Thread eines Runs arbeitet, kann keinen eigenen Run starten, sodass Runs nicht verschachtelt werden.
• Archivierung: Der Server archiviert jeden Thread spätestens am Ende seines Runs. Er kann einen früher archivieren, sobald der Thread sein Ergebnis zurückgibt oder der Run mit ihm fertig ist. Wenn der Thread zu diesem Zeitpunkt noch läuft oder auf deinen Client wartet, stoppt der Server ihn zuerst. Ein archivierter Thread bleibt in der Thread-Liste, mit dem Status terminated. Du musst die Threads eines Runs nicht selbst archivieren. Während der Run offen ist, gibt eine Anfrage zum Archivieren eines Threads, den der Server noch nicht archiviert hat, 400 mit error.details.error_code: "workflow_run_open" zurück.
• Sichtbarkeit: Du siehst den Code des Workflows nicht, aber du kannst den Agenten nach dem Workflow fragen, wie der Tipp nach dieser Liste beschreibt. Du siehst auch nicht die Tool-Aufrufe, die der Agent macht, um Runs zu starten und zu verwalten, oder das Ergebnis, das jeder Thread an den Workflow zurückgibt.

Erkennen, wann die Arbeit erledigt ist

Während ein Run läuft, erwarte, dass die Session running bleibt, selbst wenn keiner ihrer Threads arbeitet. Sie wechselt zu idle mit requires_action, wenn kein Thread arbeitet und ein Thread auf deinen Client wartet. Ein Idle allein bedeutet nicht, dass die Arbeit erledigt ist. Die Arbeit ist erledigt, wenn beides zutrifft:

1. Jeder Run, dessen Erstellung du gesehen hast, hat sein workflow_run.status_ended.
2. Danach kommt ein session.status_idle mit stop_reason end_turn an, und deine eigene Anfrage, etwa eine Unterbrechung, hat es nicht verursacht. Nachdem du unterbrochen hast, zähle nur ein Idle, das nach deiner nächsten user.message oder user.define_outcome kommt.

• Pausierte Runs: Ein pausierter Run hält die Session nicht auf running, sodass die Session inaktiv werden kann, während der Run noch offen ist. Beim Budget zum Beispiel wird die Session mit budget_reached inaktiv. Die Arbeit ist erst erledigt, wenn der Run endet.
• Ein weiterer Run: Der Agent kann einen neuen Run starten, wenn er ein Ergebnis liest, also prüfe erneut.
• Outcomes: Wenn du ein Outcome definiert hast, startet keine Auswertung, während ein Run offen ist, egal ob er läuft oder inaktiv ist. Der Turn, in dem der Agent das Ergebnis des Runs liest, kann eine starten.
• retries_exhausted: Der Turn des Agenten ist an einem Fehler gescheitert: Die Wiederholungsversuche sind aufgebraucht, oder bei dem Fehler ist kein erneuter Versuch möglich, etwa bei einem Abrechnungsfehler. Ein Run läuft möglicherweise noch, wenn dieses Idle kommt. Wenn ein Run beendet ist und der Agent sein Ergebnis noch nicht gelesen hat, startet der Server einen neuen Turn ohne Eingabe von dir. Die Session wechselt wieder zu running, also warte auf das nächste Idle. Wenn die Session inaktiv bleibt, lies den session.error, der davor kam, und behebe die Ursache. Sende dann eine user.message oder lies das result jedes Runs selbst.

Einen Run verfolgen

Dieses Beispiel verfolgt eine Session von deiner Nachricht bis zur Antwort des Agenten. Es öffnet den Stream und sendet die Nachricht. Dann tut es Folgendes:

• Verfolgt jeden Run von seinem workflow_run.created bis zu seinem workflow_run.status_ended und gibt jede Phase aus, sobald sie startet.
• Beantwortet benutzerdefinierte Tool-Aufrufe, sobald jedes agent.custom_tool_use ankommt, weil ein Thread eines Runs auf deinen Client warten kann, während die Session running bleibt. Wenn die Tools deines Agenten um Bestätigung bitten, füge einen Zweig hinzu, der jedes agent.tool_use oder agent.mcp_tool_use beantwortet, dessen evaluated_permission ask ist. Das Beispiel hat keinen, weil ein Zweig, der jeden Aufruf erlaubt, always_ask in „immer erlauben" verwandeln würde.
• Stoppt, wenn die Arbeit erledigt ist: Kein Run ist offen, und die Session wird mit end_turn inaktiv. Es stoppt auch, wenn die Session beendet wird. Bei einem Idle mit einem anderen Stop-Grund außer requires_action, etwa budget_reached, retries_exhausted oder refusal, gibt es den Grund aus und stoppt, also behandle diese in deinem eigenen Code. Es stoppt bei retries_exhausted selbst dann, wenn der Server gleich von selbst einen neuen Turn starten wird. Es wartet weiter bei requires_action und bei end_turn, während ein Run offen ist.

open_runs: dict[str, str] = {}  # workflow_run_id -> run name
phase_names: dict[tuple[str, str], str] = {}  # (run ID, phase ID) -> phase name

# Öffne zuerst den Stream und sende dann die Benutzernachricht
with client.beta.sessions.events.stream(session_id) as stream:
    client.beta.sessions.events.send(
        session_id,
        events=[
            {
                "type": "user.message",
                "content": [
                    {
                        "type": "text",
                        "text": "Which contracts in /contracts have a change-of-control clause?",
                    },
                ],
            },
        ],
    )

    for event in stream:
        match event.type:
            case "workflow_run.created":
                open_runs[event.workflow_run_id] = event.name
                for phase in event.phases:
                    phase_names[event.workflow_run_id, phase.id] = phase.name
                print(f"Run started: {event.name}")
            case "workflow_run.phase_started":
                phase_id = event.workflow_run_phase_id
                key = (event.workflow_run_id, phase_id)
                print(f"  Phase: {phase_names.get(key, phase_id)}")
            case "workflow_run.status_ended":
                name = open_runs.pop(event.workflow_run_id, event.workflow_run_id)
                print(f"Run ended: {name} ({event.result.type})")
            case "agent.custom_tool_use":
                # Antworte, wenn das Event eintrifft. Der Thread eines Runs kann auf deinen
                # Client warten, während die Session weiterläuft.
                result = call_tool(event.name, event.input)
                try:
                    client.beta.sessions.events.send(
                        session_id,
                        events=[
                            {
                                "type": "user.custom_tool_result",
                                "custom_tool_use_id": event.id,
                                "content": [{"type": "text", "text": result}],
                            },
                        ],
                    )
                except anthropic.BadRequestError as error:
                    # Der Server lehnt ein Ergebnis ab, das zu spät kommt, nachdem er
                    # den Thread des Aufrufs archiviert hat. Verfolge den Run weiter.
                    print(f"  Answer to {event.name} refused: {error.message}")
            case "session.status_idle":
                # Fertig, wenn jeder Run beendet ist und der Agent seinen Turn abgeschlossen hat
                if not open_runs and event.stop_reason.type == "end_turn":
                    break
                # Ein Idle mit requires_action wartet auf deinen Client, also lies weiter.
                # Bei jedem anderen Stop-Grund gib ihn aus und brich ab.
                if event.stop_reason.type not in ("end_turn", "requires_action"):
                    print(f"Session idle: {event.stop_reason.type}")
                    break
            case "session.status_terminated":
                break

Eine Session mit offenen Runs unterbrechen

Sende user.interrupt ohne session_thread_id oder mit der ID des primären Threads. Es stoppt den Turn des Agenten. Es beendet keinen Run. Die Runs der Session pausieren möglicherweise oder laufen weiter, und ihre Events zeigen möglicherweise nicht, welches von beidem. Die Lebensdauer eines pausierten Runs läuft weiter, sodass der Run mit timeout_error enden kann, während er pausiert ist.

• Wartende Tool-Aufrufe: Nach der Unterbrechung wartet ein Tool-Aufruf eines Run-Threads möglicherweise noch auf deinen Client. Beantworte jeden. Um einen Aufruf abzubrechen, der um Bestätigung bittet, lehne ihn ab. Um einen benutzerdefinierten Tool-Aufruf abzubrechen, sende ein Ergebnis mit is_error auf true gesetzt und einem Text in content, der den Grund nennt. Während die Session idle mit requires_action ist, gibt eine user.message 400 zurück, also beantworte zuerst die Aufrufe.
• Um die Runs zu stoppen: Sende eine user.message, die den Agenten bittet, seine Runs zu stoppen. Ein gestoppter Run endet mit result {"type": "stopped"}. Während die Session idle mit budget_reached ist, gibt eine user.message 400 zurück, bis du das Budget erhöhst oder entfernst. Das Erhöhen oder Entfernen setzt auch die Runs fort, die das Budget pausiert hat, es sei denn, die Unterbrechung hat sie ebenfalls pausiert.
• Um fortzufahren: Sende eine user.message, die den Agenten bittet, seine Runs fortzusetzen. Nach einer Unterbrechung warten die Runs möglicherweise auf diese Nachricht. Wenn die Session idle mit budget_reached ist, erhöhe oder entferne zuerst das Budget.
• Run-Ergebnisse: Ein Run, der nach der Unterbrechung endet, sendet trotzdem workflow_run.status_ended.

Während ein Run offen ist

Den Run-Zustand nach einer erneuten Verbindung wiederherstellen

Stelle den Zustand jedes Runs aus den Events der Session wieder her. Der Stream spielt nicht erneut ab, was du verpasst hast: Eine neue Verbindung liefert nur Events, die nach ihrem Öffnen ausgegeben wurden. Liste die Events also mit einem types-Filter auf, mit einem types[]-Eintrag für jeden Event-Typ, wie in Vergangene Events auflisten. Übergib das next_page jeder Antwort als page, bis next_page null ist oder fehlt. workflow_run.created, workflow_run.status_running, workflow_run.status_idle und workflow_run.status_ended geben den Zustand jedes Runs an, außer dass ein nach einer Unterbrechung pausierter Run möglicherweise noch als laufend angezeigt wird. workflow_run.phase_started und workflow_run.phase_ended stellen den Fortschritt wieder her. Ein Run ohne bisheriges Status-Event hat noch nicht mit der Ausführung begonnen. Kein Endpunkt listet Runs auf.

Budgets und Limits

Die Modellanfragen eines Runs zählen zum Budget der Session. Ein Run hat keinen eigenen Preis. Die Token, die seine Agenten verwenden, werden wie die anderen Token der Session abgerechnet, zu den Tarifen des jeweiligen Modells. Alle Kosten einer Session findest du unter Preise für Claude Managed Agents.

• Nutzung eines Runs: Liste die Threads der Session auf und addiere die Token-Zahlen in usage der Threads mit der workflow_run_id des Runs. Die Liste enthält archivierte Threads, deren Status terminated ist, sodass die Threads eines beendeten Runs mitgezählt werden. Übergib das next_page jeder Antwort als page, bis next_page null ist oder fehlt, und überspringe einen Thread, dessen usage null ist. Wenn du stattdessen die list_cost der Threads addierst, lässt die Summe die Session-Laufzeit aus, und jeder Wert wird separat gerundet.
• Beim Budget: Jeder offene Run pausiert, und die Session meldet idle mit budget_reached oder requires_action, wenn zusätzlich ein Tool-Aufruf wartet. Jeder Thread beendet die Modellanfrage, die er bereits gestartet hat, sodass ein Run das Budget um eine Anfrage pro arbeitendem Thread überschreiten kann. Das Erhöhen oder Entfernen des Budgets setzt die Runs fort, die es pausiert hat, es sei denn, eine Unterbrechung hat sie ebenfalls pausiert. Wenn die Nutzung der Session ein Modell ohne Listenpreis umfasst, tut das nur das Entfernen des Budgets; siehe Modelle ohne Listenpreis.

Der Server kürzt den name eines Runs oder einer Phase auf 64 Zeichen und ihre description auf 256. Der Server hat weitere Limits für Workflows und Regeln dafür, die hier nicht aufgeführt sind. Was du siehst, hängt davon ab, wann der Server das Problem findet:

Eine Session kann über ihre Lebensdauer beliebig viele Runs starten.

Ratenlimits

Die Arbeit eines Runs zählt zu den „rate limits" (Ratenlimits), die deine Organisation bereits hat.

Wenn eine Modellanfrage aus einem der Threads eines Runs durch ein Ratenlimit begrenzt wird oder das Modell überlastet ist, kann der eigene Stream des Threads einen session.error vom Typ model_rate_limited_error oder model_overloaded_error bekommen:

• Wenn sein retry_status.type retrying ist, wiederholt der Server die Anfrage, und der Thread arbeitet noch.
• Wenn er exhausted ist, ist der Thread fehlgeschlagen. Wenn der Workflow diesen Fehler den Run beenden lässt, endet der Run mit program_error, was die Ursache nicht nennt. Lies die Events der fehlgeschlagenen Threads, um sie zu finden.

Der Server begrenzt außerdem, wie viel alle Sessions deiner Organisation pro Minute tun. Ein Thread, der dieses Limit erreicht, stoppt, mit einem session.error in seinem eigenen Stream, dessen Nachricht ein Ratenlimit nennt. Warte eine Minute, bevor du den Agenten bittest, fortzufahren.

Ein Run kann mehr als einen Thread für dieselbe Arbeit erstellen, also sorge dafür, dass die Tools, die deine Agenten aufrufen, sicher zweimal aufgerufen werden können.