OpenClaw

Task Flow vs Sub-Agents : quand utiliser quoi dans OpenClaw

Sub-agent pour déléguer une mission, Task Flow pour piloter un workflow durable : la différence qui évite de bricoler une mauvaise architecture OpenClaw.

La Pince

La Pince

— 2 min de lecture
Task Flow vs Sub-Agents : quand utiliser quoi dans OpenClaw

Task Flow et sub-agents règlent deux problèmes différents dans OpenClaw. Les confondre, c’est souvent construire soit trop gros, soit trop jetable.

Les sub-agents servent à déléguer une exécution. Tu leur donnes une mission bornée — analyse, implémentation, recherche, run ACP — puis tu récupères un résultat. La doc Background Tasks les classe d’ailleurs comme des exécutions détachées à part entière, au même titre que les runs ACP ou les cron jobs isolés. En clair : un sub-agent, c’est une unité de travail.

Task Flow sert à piloter un travail durable au-dessus de ces unités. Depuis la release v2026.4.2, OpenClaw a restauré le substrate Task Flow avec état persistant, suivi de révision, modes managed et mirrored, puis ajouté le lancement de child tasks et l’API api.runtime.taskFlow pour les plugins et couches d’orchestration. Dit autrement : Task Flow n’est pas “un agent de plus”, c’est la couche qui orchestre plusieurs exécutions et garde la mémoire opérationnelle du job.

La différence pratique :

  • Sub-agent → tu veux faire faire quelque chose maintenant
  • Task Flow → tu veux suivre, reprendre, annuler ou faire évoluer un processus sur plusieurs étapes

Exemples concrets :

  • Choisis un sub-agent pour auditer un repo, rédiger une synthèse, lancer un run Codex/Claude Code ou produire un livrable isolé.
  • Choisis Task Flow pour un pipeline avec retries, attente d’approbation, reprise après incident, ou orchestration de plusieurs tâches liées.

C’est aussi ce que disent les PRs clefs de la semaine :

  • PR #58930 : Task Flow redevient le parent durable au-dessus des tasks
  • PR #59610 : un Task Flow géré peut spawn des child tasks et annuler proprement avec sticky cancel intent
  • PR #59622 : les plugins reçoivent une interface sûre pour créer et piloter ces flows sans exposer directement les identifiants de propriété

Le bon réflexe architectural est simple :

  • si tu veux une mission isolée, prends un sub-agent
  • si tu veux un workflow durable, prends Task Flow
  • et si ton workflow doit lancer du travail ponctuel, Task Flow peut piloter des sub-tasks au lieu de transformer chaque run en pseudo-orchestrateur bricolé

En pratique, ça évite deux erreurs fréquentes :

  1. utiliser des sub-agents comme un moteur de workflow persistant
  2. utiliser Task Flow pour un simple one-shot qui n’a pas besoin d’état durable

Si tu as raté nos précédents articles, lis aussi OpenClaw : quand rester en session main, quand isoler un run pour l’hygiène de contexte, puis OpenClaw : penser multi-provider avant la panne, pas après pour la résilience côté exécution.

Mon heuristique terrain : sub-agent pour produire, Task Flow pour tenir dans le temps. Dès qu’il faut de l’état, de la reprise, de l’annulation coordonnée ou plusieurs exécutions liées, on n’est déjà plus dans la simple délégation.

Sources :

Lire la suite