Dans le article précédent de cette série, nous avons exploré le Human-in-the-Loop. Ici, nous nous penchons sur les Handoffs, que je préfère appeler « délégation agentique »

Cet article accompagne une vidéo, je vous encourage à la regarder !

Voici le protocole de l’expérience

J’utilise le même système agentique, implémenté avec trois frameworks différents :

  • LangGraph
  • OpenAI Agents SDK
  • Google Agent Development Kit (ADK)

Dans tous les cas, l’agent suit une architecture « superviseur » : un agent unique reçoit la plupart des prompts utilisateur et décide s’il délègue une tâche à des agents plus spécialisés. Ici, j’ai un agent Google capable de lire et d’envoyer des e-mails, ainsi qu’un agent Slack capable de lire et d’envoyer des messages sur Slack. J’impose une validation HITL explicite sur tous les outils d’envoi.

Et bien sûr, comme ces outils sont des vraiesintégrations, je les ai implémentées avec Arcade.dev

Qu’est-ce que la délégation agentique ?

Dans les systèmes multi-agents, il existe plusieurs façons d’organiser les agents pour qu’ils collaborent (ou rivalisent) afin d’accomplir leurs tâches. L’une de ces façons est la délégation agentique (aussi appelée handoffs), qui consiste simplement à faire en sorte qu’un agent délègue une tâche à un autre agent du système selon ses propres critères internes.

Ce mécanisme est loin d’être le seul pour distribuer et coordonner les tâches entre agents, mais il gagne en popularité dans les systèmes multi-agents basés sur les LLM.

Comment chaque framework aborde-t-il la délégation agentique ?

Ce qui est assez universel dans l’approche des frameworks, c’est qu’ils font toujours appel à un outil qui transfère le contrôle à un autre agent, souvent appelé « sous-agent ». J’aime ce pattern car il s’appuie sur des primitives bien établies et contrôlables pour implémenter un contrôle fin. Les différences pratiques d’implémentation portent sur :

  • Le degré de transparence du handoff
  • Le degré de contrôle sur le contexte impliqué

Tout le reste n’est finalement qu’un appel de fonction.

Comme je l’ai dit, je pense que l’appel d’outil est le bon mécanisme pour la délégation agentique. J’étais donc ravi de voir ces 3 frameworks l’adopter. De ce point de vue, tous ont passé le test. Je vais maintenant mettre ma casquette de « chicaneur » et souligner les différences.

Google Agent Development Kit

Ce framework aborde les handoffs en implémentant un outil qui prend l’agent cible en argument, ainsi que le contexte d’invocation, lequel contient le contexte depuis le prompt utilisateur.

Cette implémentation fonctionne pour 90 % des cas, mais manque de flexibilité quand le contexte grossit en raison de la complexité du prompt. Par exemple, si mon prompt nécessite des dizaines d’appels à plusieurs outils ajoutés au contexte pour une synthèse, puis ensuite de déléguer à un agent pour envoyer cette synthèse par e-mail, je ne vois pas dans ADK comment dire « envoie uniquement la synthèse à l’agent e-mail ». C’est potentiellement du gaspillage, mais j’admets que c’est un cas limite.

OpenAI Agents SDK

Ce framework modélise les Handoffs de façon explicite et propose deux approches distinctes :

  • Handoffs : il s’agit d’un appel d’outil où le contrôle du flux est entièrement délégué à l’agent cible, avec transmission de l’intégralité du contexte. Les réponses à l’utilisateur proviennent désormais de cet agent, sauf s’il délègue à son tour via un handoff suivant.
  • Agent as tools : c’est un outil explicite qui encapsule un agent, et le flux de conversation n’est pas transféré à l’agent destinataire. L’agent reçoit une entrée générée par l’agent appelant. Il est censé répondre à l’agent appelant, pas à l’utilisateur.

Cela offre une plus grande souplesse au concepteur d’agents. On peut décider avec une certaine granularité ce qui est envoyé à l’agent destinataire selon la façon dont on le connecte à l’agent appelant. L’ergonomie reste perfectible à mon sens : j’imagine des cas où je veux stocker explicitement des éléments en pensant à des agents spécifiques dans la topologie, et ce framework me compliquerait la tâche pour obtenir ce niveau de contrôle. Mais je dirais qu’il couvre 95 %+ des cas d’orchestration agentique.

LangGraph

C’est à nouveau le framework qui offre selon moi l’expérience la plus complète. Il propose des fonctions utilitaires comme create_supervisor, excellente pour implémenter l’équivalent des handoffs de l’OpenAI Agents SDK. Le contexte peut être contrôlé avec une granularité similaire grâce au paramètre output_mode.

Ce qui fait de LangGraph mon framework préféré, c’est la possibilité de construire le graphe brut moi-même et d’ajouter des éléments spécifiques à l’état du graphe à n’importe quel point du flux.

Alors, quel est le meilleur framework ?

Contrairement au Human-in-the-Loop, il n’y a pas de vainqueur évident ici.

Oui, je préfère LangGraph aux autres frameworks pour un contrôle très fin. Mais ce n’est pas le cas pour la plupartdes projets agentiques. Pour les agents qui nécessitent moins de contrôle sur le contexte, LangGraph et l’OpenAI Agents SDK sont équivalents (vous ne regretterez probablement pas votre choix). Et si vous n’avez pas d’objection à céder tout contrôle sur le contexte au framework d’orchestration, Google ADK fera très bien le travail !

Essayez dès maintenant

Le code et les ressources de cette expérience sont open-source.

Il vous faudra :

Bonne construction !