Deep Agents sur LangChain : planification, sous-agents et gateway bancaire

De nombreuses équipes peuvent faire travailler un agent sur un ordinateur portable. Beaucoup moins parviennent à le maintenir opérationnel en production, et c’est là que les agents avancés trouvent leur utilité. Cette idée n’est pas un simple mot à la mode : c’est une réponse à une limite concrète — un simple cycle d’appel d’outils échoue dès que le travail devient long, complexe ou désordonné.

La limite du cycle simple

L’agent le plus basique est un LLM qui fonctionne en boucle et appelle des outils. Un tel agent est généralement peu profond, ce qui signifie qu’il ne peut pas planifier un travail étendu ni accomplir une tâche complexe en plusieurs étapes. Il gère bien une seule question, mais bute sur tout ce qui est plus volumineux.

Des produits tels que Deep Research, Manus et Claude Code ont réussi à surmonter ce problème grâce à quatre éléments : un outil de planification, des sous-agents, un système de fichiers et une instruction détaillée. Le projet deepagents est né d’une tentative de comprendre ce qui rendait Claude Code si polyvalent, afin d’aller encore plus loin. LangChain utilise l’expression « deep agents » pour désigner ce type d’agents, car ils peuvent planifier des tâches complexes et les mener à bien sur de longues périodes. En réalité, il s’agit de la voie empruntée par LangChain pour créer des agents autonomes de type Claude Code capables de gérer des tâches réelles et multi-étapes, et non seulement des questions ponctuelles.

deepagents est une bibliothèque autonome conçue à partir des composants de base pour la création d’agents de LangChain et exécutée sur le moteur LangGraph, qui offre une exécution fiable, des fonctionnalités de streaming ainsi que le soutien d’un intervenant humain. On peut la décrire comme un outil de gestion d’agents : le même mécanisme d’appel d’outils que dans d’autres frameworks, mais accompagné d’outils et de capacités supplémentaires intégrés.

Les quatre éléments essentiels

Planification. Un outil intégré write_todos permet à l’agent de diviser une tâche complexe en étapes distinctes, de suivre les progrès et de modifier le plan à mesure que de nouvelles informations arrivent.

Un système de fichiers pour le contexte. Des outils tels que ls, read_file, write_file et edit_file permettent à l’agent d’envoyer du contexte volumineux en mémoire ou sur disque, afin que la fenêtre de contexte ne soit pas submergée et que les résultats des outils, quel que soit leur volume, puissent être gérés. Les messages plus anciens sont résumés automatiquement lorsque la conversation s’allonge.

Sous-agents. Un outil de tâche intégré crée des sous-agents spécialisés disposant d’un contexte isolé. L’agent principal reste organisé, tandis qu’un assistant s’occupe en profondeur d’une sous-tâche spécifique.

Instructions système longues. Les instructions reconstituées à partir de Claude Code sont longues et contiennent de nombreuses directives sur l’utilisation des outils, ainsi que des exemples montrant comment agir dans des situations particulières. Sans elles, ces agents seraient bien moins performants. L’élaboration des instructions reste essentielle.

Sa place dans l’écosystème LangChain

Il existe trois couches, chacune s’appuyant sur celle qui se trouve en dessous. LangGraph est l’environnement d’exécution des agents, conçu pour combiner des workflows et des agents. LangChain est le framework d’agents, adapté à l’utilisation du cycle de base ainsi qu’à la création de prompts et d’outils à partir de zéro. Deep Agents est l’outil de gestion, destiné aux agents autonomes et à long terme qui bénéficient d’une planification intégrée, d’un système de fichiers et d’autres fonctionnalités similaires. Cet outil est basé sur l’abstraction des agents de LangChain, qui elle-même repose sur LangGraph.

Un exemple bancaire

Imaginons une banque qui met à disposition cinq outils spécialisés : trouver des distributeurs automatiques selon un code postal, lister les conseillers en investissement dans une ville, obtenir les entreprises incluses dans le portefeuille d’investissement de la banque, fournir des informations sur les plans de retraite, et localiser les agences dans différentes régions. Chacun de ces outils excelle dans une tâche précise. Les problèmes commencent lorsque un utilisateur demande quelque chose qui nécessite l’utilisation de plusieurs d’entre eux en même temps :

Pouvez-vous lister les centres d’ATM de la banque XYZ ainsi que les entreprises figurant dans son portefeuille d’investissements, et indiquer également l’emplacement de ses responsables des investissements à Chicago ?

Répondre à cette question implique de détecter plusieurs intentions dans une seule demande, de choisir et de coordonner les outils appropriés, de conserver le contexte entre différents domaines de données et de rassembler les résultats en une réponse cohérente. Les architectures conçues pour des flux uniques ou linéaires échouent souvent dans ce cas. C’est précisément pour de telles situations que les agents avancés ont été créés.

La séquence se déroule comme suit.

1. Planification. L’orchestrateur principal lit la question complexe et utilise write_todos pour la diviser en trois tâches : obtenir les centres d’ATM, obtenir les entreprises du portefeuille et identifier les responsables à Chicago.

Génération. Au lieu de traiter les trois tâches séquentiellement dans un contexte surchargé, il lance trois sous-agents, un par tâche, chacun disposant de sa propre fenêtre de contexte afin qu’ils ne se gênent pas.

Appel des outils. Chaque sous-agent utilise précisément l’outil approprié parmi les cinq : get_atm_centers(zipcode=...), get_trusted_portfolio_companies() et get_investment_officers(city="Chicago").

Synthèse. Les résultats sont renvoyés à l’orchestrateur, qui les fusionne en une réponse bien formatée et coche les tâches à accomplir.

Un agent de base pour l’appel d’outils gérerait les trois tâches séquentiellement au sein d’un même contexte. Il pourrait oublier les résultats précédents, perdre la trace de la question à laquelle il répondait ou atteindre la limite de contexte. Un agent avancé conserve les différentes tâches séparément et suit les progrès à travers la liste de tâches à effectuer, de sorte que même si une requête échoue ou renvoie des données partielles, l’orchestrateur sait où en est la situation.

La structure est simple :

from deepagents import create_deep_agent

agent = create_deep_agent(
    tools=[
        get_atm_centers,         # your ATM tool
        get_investment_officers, # your officers tool
        get_portfolio_companies, # your portfolio tool
        get_retirement_plans,    # your retirement tool
        get_bank_locations,      # your locations tool
    ],
    system_prompt="You are XYZ Bank's AI assistant. Always answer completely and cite sources."
)

result = agent.invoke({"messages": [{"role": "user", "content": "Can you give me a list of ATM centers for XYZ bank and also list the name of companies XYZ has in its investment portfolio? Also can you give me the location of XYZ investment agents in Chicago?"}]})

L’agent décide quels outils appeler, dans quel ordre et comment combiner les résultats obtenus. Vous n’avez pas à écrire vous-même de logique de routage, et c’est là la véritable valeur de ce framework.

ReAct face aux agents avancés en l’absence d’un outil

Prenons la même demande et ajoutons une quatrième question pour laquelle aucun outil n’existe : une liste d’options de cartes de crédit pour les étudiants. Voici comment chaque conception gère cette situation.

Un agent avancé vérifie son registre d’outils et crée la liste des tâches à effectuer avant d’agir, ce qui lui permet de constater dès le début qu’aucun outil ne couvre les cartes de crédit. Il lance des sous-agents pour les trois tâches à accomplir, qui s’exécutent en parallèle et se terminent normalement ; il marque l’élément concernant la carte de crédit comme « aucun outil disponible » et renvoie une réponse synthétisée. Cette réponse répond pleinement aux trois questions et indique clairement à l’utilisateur qu’aucun outil pour les cartes de crédit n’a été configuré et qu’il pourrait être nécessaire d’en ajouter un. Rien ne tombe en panne, et le succès partiel est rapporté de manière claire.

ReAct, abréviation de Reasoning plus Acting, suit un cycle strict de Réflexion, Action, Observation étape par étape, sans plan préalable. Cela entraîne trois problèmes :

• Il fonctionne de manière séquentielle : d’abord les distributeurs automatiques, puis le portefeuille, enfin les agents. Le problème lié aux cartes de crédit n’apparaît qu’à la fin, après que tout le reste a été traité.

Il ne scanne jamais les outils disponibles. Il découvre celui qui manque en temps de exécution lorsqu’il tente de l’appeler, et selon le LLM et l’implémentation, il peut s’arrêter, réessayer avec un nom d’outil inventé ou, pire encore, créer une liste crédible de cartes de crédit car il s’attend à ce qu’une réponse existe.

Puisque l’échec survient au milieu du cycle, rien ne garantit que les trois résultats précédents parviennent proprement à l’utilisateur. L’agent peut simplement planter et ne rien renvoyer.

ReAct convient aux tâches courtes et bien définies où l’existence de chaque outil est connue. Les agents profonds sont destinés au monde réel plus complexe, où les questions sont composées, où des outils peuvent manquer et où l’on souhaite néanmoins tirer le plus de valeur possible de ce que l’on a.

La question de conception : un agent avec tous les outils ?

Cela signifie-t-il que nous devrions créer de nombreux outils et les exposer tous via un seul agent ? Non. Un seul agent contenant 50 outils ou plus constitue un anti-modèle. Une meilleure structure est une hiérarchie d’agents. Imaginez un agent dont la configuration liste des centaines d’outils, allant de la recherche sur Internet et du courrier électronique à la réservation de vols et au lancement de roquettes, avec pour instruction de « s’en sortir ». Cela pourrait fonctionner parfois, et il répondrait occasionnellement à une plainte concernant un retard de livraison en réservant un vol, en remplissant des déclarations fiscales et en commandant une pizza. Personne ne veut ça.

Propriété du domaine

La règle directrice est que chaque agent de domaine possède un petit groupe cohérent d’outils, idéalement de trois à cinq, provenant d’une même zone métier. Un agent de passerelle ne touche jamais aux outils ; il se contente de lire l’intention, d’orienter vers le bon agent de domaine et de rassembler les réponses. Il s’agit de la même séparation des responsabilités utilisée avec les microservices.

Dans le cas de la banque, la séparation naturelle est la suivante :

• Un agent pour les agences et les distributeurs automatiques disposant de get_atm_centers et get_bank_locations, qui gère la présence physique : codes postaux, villes, horaires d’ouverture.
• Un agent pour les investissements disposant de get_portfolio, get_officers et get_retirement_plans, qui s’occupe de la gestion de l’argent, y compris les réglementations financières, les certifications des responsables et les types de plans.
• Un agent pour les produits disposant de get_credit_cards dès que celui-ci existe, ainsi que pour les prêts et les comptes d’épargne, qui gère le catalogue des produits. Lorsqu’un outil fait défaut, seul cet agent signale le manque, tandis que les autres continuent sans être affectés.

Le code reflète cette structure :

from deepagents import create_deep_agent
# Each domain agent is self-contained
branch_agent = create_deep_agent(
    tools=[get_atm_centers, get_bank_locations],
    system_prompt="You are the Branch & ATM specialist for XYZ Bank..."
)
investments_agent = create_deep_agent(
    tools=[get_portfolio, get_officers, get_retirement_plans],
    system_prompt="You are the Investments specialist for XYZ Bank..."
)
products_agent = create_deep_agent(
    tools=[get_credit_cards],  # sparse now, grows over time
    system_prompt="You are the Products specialist for XYZ Bank..."
)
# Gateway knows nothing about tools — only about agents
gateway = create_deep_agent(
    tools=[
        branch_agent.as_tool(name="branch_atm_agent"),
        investments_agent.as_tool(name="investments_agent"),
        products_agent.as_tool(name="products_agent"),
    ],
    system_prompt="""You are the XYZ Bank assistant gateway.
    Parse the user's intent, delegate to the right domain agent(s),
    and synthesize a unified response. Never answer directly — always route."""
)

Pourquoi cela fonctionne bien

Lorsque la banque ajoute de nouvelles fonctionnalités, le gateway ainsi que les autres agents de domaine restent inchangés. Vous ajoutez un outil à l’agent de domaine approprié ou en créez un nouveau, comme pour les prêts ou la lutte contre la fraude, puis vous l’inscrivez auprès du gateway. Toute modification reste confinée à un seul domaine.

Pensez à une forêt d’outils : un agent disposant de 30 outils ne possède aucune notion de domaine et pourrait appeler get_retirement_plans pour répondre à une question concernant les horaires des distributeurs automatiques, simplement parce que ces deux actions relèvent du même champ d’application. Les agents de domaine évitent cela en leur conférant une identité précise grâce à leurs instructions système et à leur ensemble d’outils. Un agent qui sait qui il est peut raisonner plus efficacement dans son propre domaine d’activité.

Un test utile : si vous débattez du fait qu’un outil appartienne à l’agent A ou à l’agent B, soit cet outil fait trop de choses et doit être divisé, soit vous avez besoin d’un troisième domaine. La frontière devrait être aussi évidente que de savoir si une question doit être adressée au responsable de branche ou à l’ conseiller en investissements.

Questions en suspens

Deux points restent à clarifier : d’une part, si les agents avancés dépendent fortement du choix du modèle sous-jacent, et d’autre part, s’il est possible de créer une solution complète du début à la fin avec eux. La réponse à la deuxième question est oui, et l’étape suivante naturelle consiste à mettre en œuvre concrètement ce scénario bancaire.