Un deep agent est un agent LLM conçu pour tenir sur des tâches longues. Il planifie avant d'agir, écrit ses résultats intermédiaires dans des fichiers au lieu de les empiler dans son contexte, et confie les parties encombrantes à des sous-agents.
Le terme n'est pas normalisé : c'est une famille d'architectures, pas un standard. C'est LangChain qui l'a fait connaître, en reprenant les motifs communs aux outils capables de travailler des heures sur un sujet — Claude Code en tête — pour les packager dans une bibliothèque open source, deepagents. C'est cette implémentation qui sert de fil conducteur ici, parce qu'elle est documentée et lisible ; les mêmes idées se retrouvent ailleurs sous d'autres noms.
L'agent classique et son plafond
Un agent, au sens courant, c'est une boucle. Vous donnez un objectif et des outils au modèle, il appelle un outil, vous lui renvoyez le résultat, il en rappelle un autre, jusqu'à ce qu'il réponde sans plus rien appeler. LangChain qualifie ces agents de shallow, littéralement « peu profonds ». Sur trois ou quatre étapes, ça marche très bien, et c'est ce que recouvre la plupart du temps le mot « agent » dans les projets qu'on nous présente.
À mesure que les tours s'accumulent, deux choses lâchent.
La première, c'est le contexte. Dans un agent minimal, les résultats d'outils sont généralement ajoutés à l'historique sans stratégie systématique de déchargement : le HTML d'une page, la réponse complète d'une API, la sortie d'une suite de tests. Après de nombreux appels, la fenêtre se remplit de matière brute et la demande initiale s'y noie. Le modèle raisonne alors en bonne partie sur du bruit qu'il a lui-même produit.
La seconde, c'est le cap. Sans plan écrit quelque part, l'agent redécide de la suite à chaque tour à partir de ce qu'il a sous les yeux. Il optimise localement : il corrige le détail qu'il vient de voir et laisse tomber les trois quarts de la demande d'origine. Personne ne s'en aperçoit avant la fin.
Dans l'architecture popularisée par LangChain, un deep agent combine quatre briques pour s'attaquer à ces deux problèmes.
Brique 1 : un prompt système détaillé et structuré
Le premier écart est le moins technique et le plus sous-estimé. Le prompt système d'un deep agent ne se résume pas à une phrase de rôle. On y trouve les conditions d'usage de chaque outil, des exemples de bonnes et de mauvaises réponses, des interdits explicites, et les critères qui permettent à l'agent de savoir quand il a fini.
La longueur n'est pas le sujet, la structure l'est : un prompt de trois pages mal organisé ne vaut pas mieux qu'un prompt de dix lignes. LangChain cite en exemple les prompts système de Claude Code reconstitués par la communauté, où l'essentiel du comportement de l'agent est décrit dans ces règles plutôt que dans le code de la boucle. Sur une tâche de dix minutes, la différence entre un agent qui aboutit et un agent qui part en vrille tient souvent à trois paragraphes de consignes.
Brique 2 : un outil de planification
deepagents fournit un outil write_todos qui maintient une liste de tâches avec leurs statuts : à faire, en cours, terminé.
Le détail intéressant, c'est que cet outil ne calcule rien. Aucun appel externe, aucun effet de bord : il écrit la liste dans l'état de l'agent, point. Son seul intérêt est que le plan réapparaît dans le contexte à chaque tour, ce qui réancre le modèle sur l'objectif complet plutôt que sur les dix derniers messages. C'est de l'ingénierie du contexte déguisée en outil, et ça reste l'un des ajouts les plus rentables de l'architecture.
Brique 3 : un système de fichiers
Le deep agent dispose de ls, read_file, write_file, edit_file, glob et grep, plus un execute pour lancer des commandes shell quand le backend est un bac à sable. La documentation des backends détaille les implémentations disponibles.
Le fichier sert de mémoire de travail. L'agent récupère un rapport de soixante pages, l'écrit dans sources/rapport.md, et ne garde que le chemin dans son contexte. Quand il en a besoin, il relit la portion utile avec grep. Le contexte transporte des références au lieu de contenu, et il tient sur la durée.
Ce système de fichiers n'est pas forcément un disque. Les backends disponibles vont de l'état LangGraph (les fichiers vivent le temps d'une conversation) au disque local, au store partagé entre conversations, au bac à sable distant. Le code de l'agent ne change pas, seul le backend change. C'est la même logique de découplage qu'en architecture logicielle classique : l'agent parle à une interface, pas à une implémentation.
Brique 4 : des sous-agents
Le dernier outil s'appelle task. Il lance un sous-agent éphémère : contexte vierge, mission précise, un rapport final en retour.
Le premier intérêt est d'isoler le contexte. Un sous-agent chargé de fouiller une documentation peut brûler trente appels d'outils ; l'agent principal n'en verra qu'un seul, avec la synthèse.
La délégation sert aussi à trois autres choses : spécialiser les outils, en donnant à chaque sous-agent le strict nécessaire pour sa mission ; paralléliser plusieurs pistes qui n'ont pas besoin de se parler ; et restreindre les permissions, un sous-agent qui explore n'ayant aucune raison de disposer du droit d'écrire. On définit un sous-agent avec un nom, une description (elle sert au principal pour décider s'il délègue), un prompt système et sa propre liste d'outils. Un sous-agent générique existe par défaut.
Attention quand même à ne pas en faire un réflexe. Le sous-agent ne voit pas l'historique de la conversation : tout ce qu'il sait, c'est ce que le principal a pris la peine de lui écrire. Une tâche mal décrite revient donc avec un rapport à côté de la plaque, et vous aurez payé deux fois. La délégation est rentable sur les tâches volumineuses et bien délimitées, beaucoup moins sur les tâches ambiguës.
Un projet d'agent IA à cadrer ?
Ce que les quatre briques ont en commun
Elles répondent toutes à la même contrainte : la fenêtre de contexte est une ressource limitée, et un agent qui travaille longtemps la remplit mécaniquement. D'où trois mécanismes complémentaires, que deepagents embarque sous forme de middlewares.
Résumer : quand l'historique dépasse un seuil, il est compressé automatiquement en un résumé qui remplace les anciens messages.
Décharger : les gros résultats d'outils partent dans des fichiers, et seul le chemin reste en mémoire.
Isoler : les explorations coûteuses se font dans un sous-agent, et seul le résultat remonte.
S'y ajoute le cache de prompt : chez les fournisseurs qui le proposent, il peut réduire le coût et la latence liés aux préfixes de conversation stables. Le gain réel dépend du modèle, de la stabilité du préfixe et de la tarification du cache, donc mesurez avant d'en faire un argument.
Rendre la main à l'humain
Un agent qui écrit en base de données, envoie des mails ou pousse du code sans validation ne passe pas en production. C'est souvent le point qui décide si un projet d'agent sort du prototype.
deepagents traite ça avec un paramètre interrupt_on : vous listez les outils qui demandent une validation, et l'exécution se met en pause avant l'appel. Le middleware de validation humaine expose trois décisions qui couvrent l'essentiel des cas — approve exécute l'appel tel quel, edit modifie les arguments avant exécution, reject annule l'appel et renvoie une explication au modèle.
from deepagents import create_deep_agent
from langgraph.checkpoint.memory import InMemorySaver
agent = create_deep_agent(
model="anthropic:claude-sonnet-4-6",
tools=[recherche_web],
system_prompt=PROMPT,
interrupt_on={
# écriture de fichier : on peut corriger le contenu avant d'écrire
"write_file": {"allowed_decisions": ["approve", "edit", "reject"]},
# commande shell : c'est oui ou c'est non
"execute": {"allowed_decisions": ["approve", "reject"]},
# lecture : aucun risque, on laisse passer
"read_file": False,
},
checkpointer=InMemorySaver(),
)Deux points à connaître avant de le brancher. Le checkpointer est obligatoire, puisqu'il faut bien stocker l'état pendant que l'agent attend votre réponse — InMemorySaver convient en développement, mais il faut une base derrière en production, sinon un redémarrage perd les tâches en attente. Et surtout, un rejet sans explication renvoie l'agent dans une boucle : il retente la même chose, se fait rejeter à nouveau, et vous brûlez des jetons pour rien. Un rejet doit toujours embarquer une consigne.
On peut aussi conditionner l'interruption. Une écriture dans le dossier de travail passe sans rien demander, une écriture ailleurs déclenche une validation. C'est ce réglage-là qui rend l'agent utilisable au quotidien : trop de demandes de validation et l'humain finit par tout approuver sans lire, ce qui revient à ne rien valider du tout.
Mémoire et compétences
Deux mécanismes complètent l'ensemble.
La mémoire longue durée passe par des fichiers AGENTS.md stockés dans un backend persistant. L'agent les lit au démarrage : préférences, conventions, décisions passées survivent d'une conversation à l'autre, et il peut les mettre à jour lui-même.
Cette dernière capacité mérite un avertissement. Une mémoire que l'agent peut réécrire est une surface d'injection : un contenu malveillant croisé pendant une tâche peut y déposer une instruction qui sera relue, et appliquée, lors de toutes les sessions suivantes. LangChain recommande de cloisonner la mémoire par utilisateur et de passer en lecture seule les fichiers qui portent des règles partagées. Traitez ces fichiers comme du code : revue avant écriture, portée limitée, et surtout pas de mémoire commune que n'importe quelle session peut modifier.
Les compétences (skills) sont des procédures que l'agent ne charge que lorsqu'il en a besoin. Plutôt que de gonfler le prompt système avec quinze modes opératoires, on les stocke à côté et l'agent va lire celui qui correspond à la situation. La documentation appelle ça la divulgation progressive : le contexte ne contient que ce qui sert maintenant.
Quand un deep agent se justifie
Cette architecture a un coût. Plus de latence, plus de jetons consommés, et un débogage nettement plus pénible : quand un sous-agent rend un rapport bancal, il faut remonter la trace pour comprendre ce qu'il a vu et ce qu'il a inventé. Ce n'est pas gratuit.
Quatre signaux indiquent que le jeu en vaut la chandelle : le nombre d'étapes est inconnu au moment de lancer la tâche, la matière à traiter dépasse largement la fenêtre de contexte, la tâche mobilise des compétences vraiment distinctes, ou elle tourne plusieurs minutes voire plusieurs heures. La recherche documentaire, l'audit de code, l'analyse d'un corpus de documents hétérogènes cochent ces cases.
À l'inverse, si votre processus est déterministe — étape 1, puis 2, puis 3, toujours dans cet ordre — écrivez un workflow classique et appelez le modèle aux endroits où il apporte quelque chose. Vous obtiendrez un résultat plus rapide, moins cher et testable. Même verdict si un utilisateur attend la réponse à l'écran, ou si vous avez besoin de rejouer exactement la même exécution pour un audit : un agent autonome ne garantit pas un chemin d'exécution identique d'un lancement à l'autre.
Trois questions suffisent en général à trancher :
- Le chemin d'exécution est-il connu à l'avance ? Si oui, c'est un workflow.
- La tâche déborde-t-elle la fenêtre de contexte ? Si non, un agent simple suffit.
- Existe-t-il des actions à valider avant exécution ? Si oui, prévoyez le circuit humain dès le départ, pas après la démo.
Et si vous décidez d'y aller, commencez par un agent simple avec de bons outils. Vous ajouterez la planification, les fichiers et les sous-agents quand vous aurez vu où votre agent décroche, pas avant.
Pour creuser l'implémentation, LangChain publie une formation gratuite « Introduction to DeepAgents » en 38 leçons, qui reprend ces briques une par une avec du code exécutable.
