Après le lancement du 9 octobre 2026, comment un workflow_run Claude montre-t-il que le travail est fini ?

Demander de trouver une clause de changement de contrôle dans 300 contrats ne doit pas empiler 300 lectures dans une conversation. L'agent écrit un workflow et lance les phases en arrière-plan. Le programme ne voit pas le source. Il voit des événements. Un champ manqué transforme « le programme a fini » en « la revue a réussi ».

Ce que la doc ouvre vraiment

• Interrupteur : en-tête bêta managed-agents-2026-04-01. multiagent vaut {"type":"multiagent_20261001","workflows":{"type":"enabled"}}. Le prompt système dit quand lancer un run.
• Qui lance : seulement l'agent du fil principal. Un agent dans un run n'en lance pas un autre. Un événement envoyé ne termine pas un run. Archiver la session le peut.
• Ce qu'on ne voit pas : le code du workflow, les appels d'outils de démarrage, et le résultat que chaque fil rend au programme. Après la fin et idle, on peut demander le workflow mot pour mot, sans nouveau run.
• Où vont les événements : workflow_run.* sur le flux de session. Les lister les renvoie aussi. Pas de webhook.

created liste les phases

Un run est ouvert de workflow_run.created à workflow_run.status_ended.

{
  "type": "workflow_run.created",
  "workflow_run_id": "wrun_01J8XkN5uT3vHpLqRfWdY2",
  "name": "Find change-of-control clauses",
  "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"
}

name et description sont écrits par le modèle. phases est toujours là et peut être vide. Un événement de phase porte workflow_run_phase_id, pas le nom. On retrouve le nom par id dans created.phases. La fin a phase_started_id. L'API ne garantit pas une phase à la fois. Chaque phase commencée se termine avant status_ended. Un fil s'annonce par session.thread_created avec le même workflow_run_id. Aucun champ ne dit la phase. On distingue par session_thread_id.

La fin est result sur ended

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

• completed : le programme a fini. Pas la réussite. Un fil en échec peut quand même finir completed.
• stopped : l'agent a arrêté, ou la session a été archivée. L'événement ne dit pas lequel.
• timeout_error : durée de vie atteinte. 24 heures par défaut. Une pause ne l'arrête pas.
• program_error : échec du code, règle cassée, ou un fil en échec que le programme laisse terminer le run.
• thread_limit_error : plus de 1 000 agents lancés sur la vie du run. Les reprises peuvent dépasser 1 000 fils.
• unknown_error : le serveur ne peut pas continuer, ou une autre limite.

Une erreur ressemble à {"type":"error","error":{"type":"timeout_error","message":"..."}}. workflow_run.error n'est pas la fin. workflow_run_id null : aucun run. Un échec de modèle, de serveur MCP, d'identifiants ou de facturation met session.error sur le fil. Cela seul ne termine pas le run.

Quand le travail est vraiment fini

1. Chaque run vu a workflow_run.status_ended.
2. Ensuite arrive un session.status_idle dont stop_reason est end_turn, pas causé par votre interruption. Après une interruption, ne compter qu'un idle après le prochain user.message ou user.define_outcome.

Au budget, la session peut passer idle avec budget_reached pendant que le run reste ouvert. Un idle seul n'est pas la fin. L'agent peut lancer un autre run après avoir lu le résultat.

Durée, concurrence et plafond de fils

• Agents lancés sur la vie d'un run : 1 000. Au-delà, thread_limit_error.
• Durée de vie : 24 heures, ou moins si l'agent le fixe. L'attente du client compte. Raison : timeout_error.
• Runs ouverts en même temps : 10 par défaut. Les idle comptent. Le suivant donne max_workflow_runs_error.

Archiver un fil pendant que le run est ouvert renvoie 400, error_code workflow_run_open.

Vérifier dans la boîte à outils

{
  "type": "object",
  "properties": {
    "type": { "const": "workflow_run.status_ended" },
    "workflow_run_id": { "type": "string", "pattern": "^wrun_" },
    "result": { "type": "object", "properties": { "type": { "enum": ["completed", "stopped", "error"] } }, "required": ["type"], "additionalProperties": true }
  },
  "required": ["type", "workflow_run_id", "result"],
  "additionalProperties": true
}

{
  "ok_completed": {"type": "workflow_run.status_ended", "workflow_run_id": "wrun_01J8XkN5uT3vHpLqRfWdY2", "result": {"type": "completed"}},
  "not_ended": {"type": "workflow_run.error", "workflow_run_id": null},
  "missing_id": {"type": "workflow_run.status_ended", "result": {"type": "completed"}}
}

1. Coller les événements dans le formatage JSON et confirmer le parse.
2. Avec JSON → Schema, partir de ok_completed, puis ajouter pattern et enum.
3. Passer not_ended et missing_id dans la validation Schema. Les deux doivent échouer.
4. Après la forme, chercher les fils en échec. Les entrées d'outil d'un fil passent par les appels de fonction.

Les données restent dans le navigateur.

Questions fréquentes

result completed veut-il dire que les 300 contrats ont été relus ?

Non. Seulement le programme a fini. Un fil en échec peut être completed.

Puis-je prendre le résultat quand la session passe idle ?

Non. Au budget la session est idle et le run reste ouvert. Attendre chaque status_ended, puis end_turn.

workflow_run.error est-il la fin ?

Non. workflow_run_id null : aucun run. Sinon attendre status_ended.

Ces événements déclenchent-ils des webhooks ?

Non. Ils arrivent sur le flux de session. Les messages de fil restent sur le flux du fil.

Est-ce la même note que les événements MCP de ChatGPT ?

Non. L'autre est dans Événements MCP de ChatGPT. Celle-ci traite les workflow_run de Claude.

En bref

Au 13/10/2026, la note de version est datée du 09/10/2026. L'en-tête bêta est managed-agents-2026-04-01. L'avancement se lit dans created.phases, la fin seulement dans status_ended.result. completed n'est pas une revue réussie. Fini exige aussi un idle de session avec end_turn. Un run lance au plus 1 000 agents, vit 24 heures par défaut, et une session tient au plus 10 runs ouverts. Ensuite, refuser une fin sans workflow_run_id.

Outils liés

Articles liés