Deep Agents

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 1 sur 16. Créer un coding agent from scratch, c'est marrant pendant environ une heure. Ensuite, ton modèle atteint sa context limit, oublie complètement la task de départ, et écrase un fichier critique avec n'importe quoi. Pour éviter que ton assistant ne détruise son propre workspace, tu as besoin de ce qu'on appelle le pattern agent harness. On découvre souvent ce pattern via une librairie qui s'appelle Deep Agents. D'abord, petite clarification. Deep Agents, ce n'est pas LangChain, et ce n'est pas LangGraph. C'est une librairie Python standalone qui vient se greffer au-dessus de ces outils, pour les packager dans un coding assistant prêt à l'emploi. Si tu essaies de coder un coding assistant toi-même, tu commences en général par un script basique. Tu prends un prompt utilisateur, tu l'envoies à un large language model, et tu print le code qu'il te renvoie. C'est juste une simple chat loop. Ça marche très bien pour répondre à une seule question. Mais très vite, tu as envie que le modèle implémente une feature sur plusieurs fichiers de ta machine. C'est là que l'illusion se brise. Tu te rends compte que tu dois écrire manuellement des tools pour lire les fichiers, chercher dans les répertoires, et appliquer des code diffs de manière safe. Tu as besoin d'un système pour tracker le contexte sur des dizaines de steps sans exploser la token limit. Tu dois créer une task list persistante pour que le modèle se souvienne vraiment de ce qu'il vient de faire et de ce qu'il doit faire ensuite. Tu finis par passer tout ton temps à écrire du boilerplate pour le file system et le state management, au lieu de te concentrer sur le comportement de l'agent. C'est exactement ce que le pattern agent harness vient résoudre. Un harness, c'est la couche d'infrastructure qui vient wrapper le modèle de langage brut. Il transforme une chat loop fragile et stateless en un agent durable et long-running. Dans Deep Agents, ce harness fournit le memory management, les opérations sur le file system, et la logique de planification step-by-step, directement out of the box. Tu lui donnes un objectif high-level et tu le pointes vers un répertoire local. Le harness prend le relais sur le travail répétitif pour offrir au modèle un environnement safe afin de planifier, éditer et vérifier le code. Voici l'idée clé. Le principal avantage d'utiliser un harness indépendant comme Deep Agents, c'est qu'il est complètement model-agnostic. Les solutions très intégrées comme le SDK Claude Agent ou les écosystèmes plus anciens comme OpenAI Codex sont hyper optimisées, mais elles t'enferment chez un seul provider. Si un modèle moins cher ou plus intelligent sort demain, migrer ton agent tightly coupled devient un énorme casse-tête. Parce que Deep Agents abstrait l'environnement du moteur de raisonnement, le modèle de langage devient un composant totalement remplaçable. Le harness gère les task lists, lit le file system, et s'occupe de l'error recovery. Cette logique reste identique, que tu utilises Anthropic, OpenAI, ou un modèle open-weight local. Le harness, c'est le châssis de la voiture, et le modèle de langage, c'est juste le moteur. La vraie valeur de ce pattern, c'est la fiabilité. Un agent n'est performant qu'à la hauteur de l'environnement dans lequel il opère, et sans un harness pour l'ancrer à un vrai file system et à un plan concret, même le modèle le plus intelligent n'est qu'un générateur de texte qui tourne dans le vide. Si tu veux aider à faire vivre le podcast, tu peux chercher DevStoriesEU sur Patreon, tout soutien fait une énorme différence et est toujours très apprécié. C'est tout pour cet épisode. Merci de m'avoir écouté, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 2 sur 16. Tu n'as pas besoin d'un énorme diagramme d'architecture ou de centaines de lignes de boilerplate pour qu'un modèle de langage planifie son travail de manière autonome. Tu as juste besoin d'un seul function call pour déclencher la Core Loop. Le point d'entrée pour ce comportement est une fonction appelée create deep agent. C'est dans cette fonction que tu définis le cerveau de ton application. Au lieu d'importer des libraries clientes séparées et d'écrire des wrappers sur mesure, tu indiques à la fonction quel modèle utiliser via une simple string séparée par des deux-points. Tu passes le provider, un deux-points, et le nom exact du modèle. Tu pourrais utiliser anthropic deux-points claude-sonnet-4-6, ou openai deux-points gpt-5.4. Le framework lit cette string et gère l'initialisation spécifique sous le capot. Un agent a besoin d'un moyen d'interagir avec le monde, ce que tu lui fournis via des tools. Un tool est juste une fonction Python standard qui effectue une action spécifique. Disons que tu développes un agent de recherche sur Internet. Tu écrirais une fonction qui prend une query, appelle une API de recherche, et renvoie du texte. Tu passes cette fonction de recherche directement dans ton appel à create deep agent, au sein d'une liste. Ton agent est maintenant prêt. Pour démarrer le processus, tu appelles la méthode run sur ton nouvel agent et tu lui passes un prompt, comme lui demander de rechercher et de synthétiser les actualités récentes sur l'informatique quantique. Maintenant, la Core Loop prend le relais. Voici l'idée clé. Les développeurs pensent souvent qu'ils doivent écrire des system prompts complexes pour forcer le modèle à découper les tâches, ou construire des parsers sur mesure pour suivre sa progression. Tu n'as rien à faire de tout ça. Quand tu appelles create deep agent, le framework injecte automatiquement un tool intégré appelé write todos. Tu n'as jamais à écrire ou gérer ce tool toi-même. Il fait partie du moteur principal. Avant même que l'agent ne touche à ton tool de recherche, la Core Loop force le modèle à utiliser le tool write todos. L'agent évalue ton prompt et génère une liste structurée d'étapes. La phase d'exécution ne commence qu'une fois ce plan finalisé. La loop itère sur le plan étape par étape. L'agent regarde sa première tâche, reconnaît qu'il a besoin d'informations, et appelle ton tool de recherche internet. Il lit le texte brut renvoyé par le moteur de recherche et met à jour sa mémoire interne. La loop vérifie ensuite si l'objectif principal est atteint. Si les résultats de la recherche sont incomplets, l'agent passe à l'élément suivant sur sa todo list, en formulant peut-être une nouvelle query de recherche pour trouver les détails manquants. Ce cycle de sélection d'un tool, d'observation du résultat, et de vérification du plan continue de manière autonome. Quand la loop confirme que toutes les tâches nécessaires sont terminées, elle arrête d'appeler des tools. L'agent analyse les données collectées, génère une réponse synthétisée finale, et te la renvoie. La caractéristique principale de la Core Loop est qu'elle transforme un générateur de texte statique en un système de résolution de problèmes actif, en le forçant structurellement à planifier avant d'agir. C'est tout pour cet épisode. Merci pour ton écoute, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 3 sur 16. Donner à un agent autonome un accès direct à ton ordinateur est un excellent moyen de supprimer accidentellement ton home directory. Si un agent décide de réorganiser tes fichiers ou de tester un script, tu dois t'assurer qu'il est confiné dans une zone sécurisée. C'est pour ça qu'on utilise The Pluggable Filesystem. Quand tu donnes à un Deep Agent des tools pour lire ou éditer un fichier, ces tools ne se connectent pas directement à ton système d'exploitation. Ils sont plutôt mappés à un backend. Un backend est un environnement de stockage qui détermine où et comment les fichiers sont réellement stockés. L'environnement par défaut, c'est le StateBackend. C'est un disque fantôme éphémère, entièrement gardé en mémoire. Supposons que tu demandes à un agent d'écrire un brouillon d'e-mail rapide ou de manipuler des données texte. L'agent crée le fichier, le relit et l'édite, le tout dans le StateBackend. Quand ton script a fini de tourner, cette mémoire est vidée et les fichiers disparaissent. C'est complètement isolé et parfaitement sûr. Mais que se passe-t-il quand tu veux que l'agent génère un vrai projet Python sur ton disque local ? La mémoire ne suffit plus. Tu augmentes les permissions de l'agent en lui attachant un FilesystemBackend. Ça connecte les tools de fichiers de l'agent à ton vrai disque dur. Pour garder ça sécurisé, tu initialises le backend avec un paramètre appelé virtual mode set à true. Voici le point clé. Le virtual mode crée une limite de path stricte. Tu définis un base directory, et l'agent opère à l'intérieur. Si l'agent essaie de lire un fichier système sensible en dehors de ce dossier, le backend bloque la requête. Il enferme l'agent dans un workspace désigné. Cependant, il y a une fausse idée dangereuse ici. Beaucoup de développeurs pensent qu'activer le virtual mode crée une sandbox complètement sécurisée. Ce n'est pas le cas. Le FilesystemBackend contrôle uniquement les opérations sur les fichiers. Si tu veux aussi que ton agent lance des commandes dans le terminal, tu dois attacher un troisième type de backend appelé le LocalShellBackend. Le LocalShellBackend donne à l'agent un nouveau tool appelé execute. Ça permet à l'agent de lancer des commandes shell sur ta machine hôte. Si tu attaches un LocalShellBackend, le virtual mode de ton FilesystemBackend ne te protégera pas des commandes destructrices dans le terminal. L'agent pourrait exécuter un script de suppression sur tout le système, et le shell le lancerait, en contournant complètement tes restrictions de path. L'accès aux fichiers et l'exécution dans le shell sont des capacités distinctes, mappées à des backends distincts. Si ton agent a juste besoin d'écrire du code, reste sur le FilesystemBackend. N'attache le LocalShellBackend que si l'agent doit absolument compiler ou run ce code en local. L'agent autonome le plus sécurisé n'est pas celui avec les prompts les plus intelligents, mais celui déployé avec un StateBackend éphémère qui ne peut physiquement pas toucher ton système d'exploitation hôte. C'est tout pour aujourd'hui. Merci d'avoir écouté — va builder un truc cool.

Salut, ici Alex de DEV STORIES DOT EU. Deep Agents, épisode 4 sur 16. L'erreur la plus fréquente dans le design d'agents, c'est d'écrire un énorme system prompt de quatre mille mots qui détaille exactement comment chaque tool fonctionne, et de hardcoder des données de session spécifiques. Tu te retrouves avec un prompt fragile, des context windows saturées, et c'est un vrai cauchemar pour gérer plusieurs utilisateurs. Les system prompts dynamiques résolvent ce problème en assemblant à la volée les instructions exactes dont le modèle de langage a besoin. Imagine le context engineering dans Deep Agents comme une chaîne de montage dynamique. Au lieu d'écrire un seul bloc de texte statique, le prompt final envoyé au modèle de langage est construit à partir de trois couches distinctes. Ces couches sont le system prompt statique, les tool prompts et le runtime context. Elles fusionnent au moment précis de l'exécution pour former l'input context complet. La première couche, c'est le system prompt statique. C'est la partie que tu écris manuellement. Il définit le persona de l'agent, ses règles principales et son but ultime. Il est volontairement simple. Tu peux dire à l'agent qu'il est un assistant de requêtes de base de données, mais tu ne lui dis pas comment se connecter à la base de données, quel formatage le tool attend, ou quel est le session ID de l'utilisateur. Tu gardes cette couche strictement concentrée sur la business logic de haut niveau. La deuxième couche est constituée des tool prompts, et c'est là que le framework intervient. Deep Agents injecte automatiquement les instructions d'utilisation nécessaires pour les tools spécifiques que tu attaches à l'agent. Si tu donnes à l'agent un tool pour lire un fichier, le framework ajoute dynamiquement le schéma exact pour ce tool. En plus des schémas, il injecte un planning prompt intégré. Ce planning prompt explique au modèle comment séquencer efficacement les tools disponibles pour résoudre un problème. Tu n'écris jamais manuellement les instructions sur la façon dont le modèle doit formater un tool call ou planifier ses étapes d'exécution. Le framework gère cette mécanique automatiquement. Quand tu ajoutes ou retires un tool de l'agent, les tool prompts sous-jacents se mettent à jour instantanément, sans que tu touches au system prompt principal. Maintenant, on doit dissiper une source fréquente de confusion entre le system prompt statique et le runtime context. Le prompt statique est défini quand tu initialises l'agent. Le runtime context, en revanche, est injecté exactement au moment où tu invoques l'agent pour travailler. Imagine un scénario où tu construis une application multi-tenant. Quand un utilisateur spécifique pose une question, l'agent a besoin de son connection ID unique à la base de données pour récupérer ses données. Si tu mettais cet identifiant dans le system prompt statique, tu devrais recréer l'agent entier de zéro pour chaque requête utilisateur. À la place, tu utilises le runtime context. Voici l'idée clé. Tu passes un objet de contexte via une fonctionnalité appelée ToolRuntime, pile à l'étape d'invocation. Tu donnes au framework un dictionnaire contenant le connection ID spécifique à la base de données pour cette session. Le framework prend ce runtime context, le fusionne avec ton prompt statique et les instructions de tool générées automatiquement, et le connecte directement aux tools qui en ont besoin. Le tool s'exécute en utilisant le bon connection ID, fourni dynamiquement. Ton system prompt statique reste totalement propre, sans identifiants temporaires, clés API ou session tokens. À la milliseconde de l'exécution, la chaîne de montage dynamique termine son travail. Deep Agents concatène tes instructions principales, les tool schemas générés dynamiquement, les planning prompts et les données d'invocation spécifiques en un seul input context cohérent. Le modèle reçoit un ensemble complet d'instructions parfaitement formatées, sur mesure pour cet utilisateur spécifique et cette tâche spécifique. Les agents les plus scalables ne savent rien de leur environnement jusqu'au moment exact où on leur demande d'agir. C'est tout pour aujourd'hui. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 5 sur 16. La plupart des agents IA plantent ou échouent silencieusement dès qu'ils lisent un system log ou un data dump qui dépasse la taille maximale de leur prompt. Deep Agents évite ça en gérant les limites de contexte comme un système d'exploitation gère la mémoire virtuelle. C'est ce qu'on appelle le Context Compression et l'Offloading. Les grands modèles de langage ont un plafond strict sur la quantité de texte qu'ils peuvent traiter en une seule fois. Si un agent essaie de garder trop de données dans son prompt actif, le modèle renvoie une erreur et s'arrête. Deep Agents gère cet overflow de tokens en surveillant constamment la taille des données de la conversation. Ça marche exactement comme un ordinateur qui fait du paging de la RAM vers un disque dur quand la mémoire est pleine. L'espace de travail actif reste léger, pendant que le gros des données est mis de côté en toute sécurité. Ce mécanisme fonctionne en deux phases distinctes. La première phase gère les pics de données massifs et immédiats qui viennent d'outils externes. Le framework surveille le nombre de tokens de chaque tool input et tool result. Le seuil strict pour cette vérification est de vingt mille tokens. Si une opération dépasse cette limite, le système intercepte le payload avant même qu'il n'atteigne le modèle de langage. Prends l'exemple d'un agent qui exécute une requête pour récupérer un database dump massif de trente mille tokens. Un agent standard essaierait d'insérer tout ce payload directement dans l'historique de la conversation, ce qui déclencherait immédiatement un overflow de tokens. Deep Agents fait les choses autrement. Il intercepte cette réponse massive, offload le texte complet dans un nouveau fichier sur le filesystem du backend, et remplace le payload dans la conversation par un simple aperçu de dix lignes. L'agent lit l'aperçu et reçoit un chemin de fichier qui pointe vers les données complètes. L'agent sait exactement ce qu'il a trouvé, mais le prompt actif reste complètement dégagé. Ça, c'est pour gérer les pics de données soudains. La deuxième phase gère l'accumulation lente d'une conversation standard. Quand un agent exécute un processus long en plusieurs étapes, l'historique continu des allers-retours grignote doucement les tokens disponibles. Deep Agents surveille l'utilisation totale de la context window par rapport aux limites du modèle. Quand le prompt actif atteint 85 % de la context window totale disponible, un processus de résumé en background se déclenche automatiquement. Le système prend le plus vieux bloc de messages dans l'historique actuel et utilise un modèle de langage pour générer un résumé dense et factuel de ces événements. Il remplace ensuite cet ancien bloc de messages dans le prompt actif par le résumé fraîchement généré, ce qui fait redescendre instantanément le nombre de tokens à un niveau de travail sûr. Et voici le point clé. Les développeurs pensent souvent que résumer la conversation détruit définitivement l'historique original. C'est faux. Avant qu'un résumé n'ait lieu, les messages originaux sont écrits sur le filesystem comme un enregistrement permanent et canonique. Les données brutes ne sont pas perdues. Si l'agent détermine plus tard qu'il a besoin d'un détail très spécifique d'une étape précédente qui n'a pas fini dans le résumé, il peut utiliser ses outils de recherche pour interroger ce filesystem et récupérer le texte original exact. En combinant des offloads immédiats sur le filesystem pour les tool results massifs avec un résumé dynamique pour les historiques à rallonge, un agent peut fonctionner indéfiniment sans suffoquer sous son propre contexte. Merci de m'avoir écouté, et happy coding à tous !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 6 sur 16. Si ton agent IA principal doit lire dix pages web pour répondre à une seule question, il finira par oublier quel était le prompt original. Tout ce bruit intermédiaire finit par noyer les instructions. La solution à ça, c'est l'isolation du contexte avec des sous-agents synchrones. Imagine ça comme un pattern de clean architecture pour tes modèles de langage. Quand un seul agent a accès à des dizaines d'outils et tourne sur de longues loops itératives, sa context window se remplit rapidement de données brutes, de messages d'erreur et de tool outputs. Ce context bloat dégrade la capacité de raisonnement du modèle. Au lieu d'un seul agent massif qui essaie de tout faire, il te faut un superviseur. L'agent principal agit comme un manager. Il délègue le sale boulot gourmand en tokens à des spécialistes et ne reçoit qu'un rapport final propre et formaté. On confond souvent les sous-agents avec une chat room multi-agents permanente, où différents modèles s'assoient et débattent d'idées entre eux. Ce n'est pas le cas ici. Les sous-agents synchrones sont strictement éphémères. Ils sont instanciés pour exécuter un job spécifique, ils tournent de manière totalement autonome dans leur propre espace mémoire isolé jusqu'à ce que le job soit terminé, et ils renvoient un seul résultat final au superviseur. Une fois qu'ils ont transmis ce résultat, ils disparaissent. Prends un scénario spécifique. Ton agent principal est chargé d'écrire un briefing de marché, et il a besoin de données sur les tendances économiques récentes. Au lieu que le superviseur invoque directement un outil de web search cinq fois et pollue sa propre context window avec du texte brut de site web, il délègue le problème. Il déclenche un sous-agent researcher. Ce researcher éphémère part dans sa propre loop isolée. Il fait les cinq recherches Google, lit les résultats bruts, synthétise les trouvailles et écrit un seul paragraphe de résumé. Il ne renvoie que ce paragraphe au superviseur. Le superviseur obtient exactement ce dont il a besoin, et son contexte reste immaculé. Pour configurer ça, tu définis tes spécialistes en utilisant de simples dictionnaires. Tu les passes au paramètre subagents quand tu construis ton agent principal. Chaque dictionnaire est une spécification de sous-agent qui nécessite quatre informations. Premièrement, tu fournis un nom, comme researcher ou calculator. Deuxièmement, tu fournis une description. C'est la partie qui compte. Le superviseur lit cette description pour décider quel spécialiste engager pour un problème donné. Troisièmement, tu fournis les tools, ce qui donne à ce sous-agent spécifique un accès isolé à des choses comme un web scraper ou un database client. Enfin, tu fournis un system prompt, qui gouverne la façon dont le sous-agent se comporte. Une fois que tu passes cette liste de configurations à l'agent principal, il gagne automatiquement accès à un tool intégré appelé task. Le superviseur n'a pas besoin de savoir comment instancier les sous-agents. Quand il rencontre un problème qui correspond à la description d'un spécialiste, il appelle simplement le tool task. Il passe deux arguments : le nom du sous-agent à utiliser, et une instruction en plain text de ce qui doit être fait. L'exécution du superviseur se met en pause. Le sous-agent démarre, travaille avec ses tools, et finit par terminer. Pour le superviseur, le tool task retourne simplement la réponse texte finale comme si c'était un function call standard. Même si tu ne définis explicitement aucun dictionnaire, le framework te donne un fallback. Il y a un sous-agent par défaut généraliste qui est built-in. L'agent principal peut utiliser ce spécialiste par défaut pour décharger des étapes de raisonnement complexes. Il agit comme une page blanche, donnant au modèle une context window toute neuve pour résoudre un puzzle logique dense sans embourber la memory du superviseur. Voici l'idée clé. En imposant des frontières strictes entre les tâches isolées, tu empêches le travail intermédiaire de scratchpad de dégrader la qualité de raisonnement de ton flow d'application principal. C'est tout pour cet épisode. Merci pour ton écoute, et continue à builder !

Bonjour, ici Alex de DEV STORIES DOT EU. Deep Agents, épisode 7 sur 16. Laisser un système autonome exécuter des requêtes SQL à l'aveugle est un excellent moyen de drop accidentellement une base de données de production. Si tu veux que ton agent fonctionne dans le monde réel, tu as besoin d'un mécanisme pour l'intercepter avant qu'il ne fasse quelque chose de destructeur. C'est là qu'interviennent les interventions Human-in-the-Loop. L'idée de base est simple. Tu mets l'agent en pause juste avant qu'il n'exécute une opération sensible, tu demandes des instructions à un humain, puis tu reprends l'exécution en fonction de ce feedback. Avant de regarder la mécanique, il y a un piège courant à éviter. LangGraph nécessite de la mémoire pour mettre en pause et reprendre le state. Si tu essaies de configurer une intervention Human-in-the-Loop sans mettre en place un checkpointer, l'intervention va échouer. Le système a besoin d'une couche de persistance, comme un memory saver, pour figer l'execution graph et stocker les variables actuelles pendant qu'il attend qu'un humain réponde. Attache toujours un checkpointer en premier. Tous les tools n'ont pas besoin d'une vérification humaine. Vérifier la météo ou lire un log file est généralement sans risque. Supprimer des fichiers ou modifier des enregistrements en base de données nécessite un contrôle strict. Tu gères cette catégorisation des risques en utilisant le paramètre de configuration interrupt on. Quand tu initialises ton agent ou que tu définis ton tool node, tu passes une liste de noms de tools à ce paramètre. Si l'agent tente de call un tool qui n'est pas sur la liste, il s'exécute immédiatement. S'il essaie de call un tool qui est sur la liste, l'exécution se met en pause. Prenons un scénario concret. Tu as un agent avec un tool de base de données appelé execute. Tu ajoutes execute à ta liste interrupt on. L'agent décide qu'il a besoin de nettoyer d'anciennes données et tente de lancer une commande drop sur la base de données. Le système intercepte le call et met en pause l'execution graph. Quand tu fais tourner ton agent, tu surveilles l'objet result renvoyé par le framework. Plus précisément, tu cherches une propriété appelée interrupts. Si la liste interrupts du result contient des données, l'agent a atteint une barrière de sécurité et attend ton input. À ce stade, l'opérateur humain évalue l'action en attente. Tu as trois décisions autorisées que tu peux renvoyer à l'agent. Ce sont approve, reject ou edit. Si tu choisis approve, l'agent exécute le tool avec les arguments d'origine. Si tu choisis reject, le tool call fail proprement, et l'agent reçoit un message d'erreur qui le prompt à essayer une approche différente. C'est là que ça devient intéressant. La décision edit te permet de modifier l'action prévue par l'agent avant qu'elle ne se produise. Dans notre scénario de base de données, l'agent tente une commande drop dangereuse. Tu peux intercepter cette requête, réécrire les arguments du tool pour exécuter une requête select sécurisée à la place, et renvoyer ce payload modifié au système. Pour unpause l'agent, tu l'invoques à nouveau, mais cette fois tu passes un objet command en utilisant le paramètre resume. À l'intérieur de ce paramètre resume, tu fournis ta decision string avec les éventuels arguments modifiés. Le checkpointer récupère le state figé, injecte ta décision humaine directement dans le graph comme si l'agent l'avait initialement prévu comme ça, et l'exécution continue. La chose la plus importante à retenir est que les interventions Human-in-the-Loop te donnent bien plus qu'un simple bouton d'arrêt d'urgence. La capacité d'éditer les arguments d'un tool en plein vol te permet de guider un agent en toute sécurité à travers des workflows complexes sans avoir à tout recommencer. Si tu veux aider à soutenir l'émission, cherche DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci pour ton écoute, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 8 sur 16. Tu pourrais voir un agent lire un fichier local et te dire que cette fonctionnalité est hardcodée au fin fond de l'execution loop principale. Eh bien non. La magie derrière le système de fichiers d'un agent repose entièrement sur des middlewares composables que tu peux étendre toi-même. Aujourd'hui, on va voir comment étendre le harness avec des middlewares. Deep Agents n'est pas une boîte noire. Le harness qui pilote l'execution pipeline est ultra extensible. Quand tu équipes un agent avec un système de fichiers ou une todo list, tu attaches simplement des middlewares pré-packagés à ce harness. Le middleware se situe exactement à la frontière entre le moment où l'agent décide d'invoquer un tool et l'exécution réelle de ce tool. C'est un intercepteur. Il te donne un contrôle absolu sur ce qui entre, ce qui sort, et ce qui est enregistré pendant l'échange. Pour écrire ton propre middleware custom, tu crées une fonction d'interception et tu appliques un décorateur spécifique qui s'appelle wrap tool call. Ce décorateur enregistre ta fonction auprès du harness. Quand l'agent déclenche un tool, le harness met en pause le flow par défaut et passe le contrôle à ta fonction wrappée. À l'intérieur de cet intercepteur, tu reçois les arguments d'input bruts générés par l'agent, une référence au tool qui est appelé, et le graph state actuel. Tu exécutes le tool d'origine manuellement depuis ta fonction, tu captures son output, et ensuite tu renvoies cet output au harness. Prends l'exemple d'un middleware custom conçu pour monitorer une API externe. Tu veux intercepter chaque tool call vers l'API, logger les arguments exacts que l'agent a utilisés, et tracker les métriques d'utilisation pour éviter les rate limits. Ta fonction wrap tool call attrape la requête avant qu'elle ne touche le réseau. Elle extrait le payload, l'écrit dans les logs de ton application, puis exécute la vraie requête API. Une fois la requête terminée, le middleware reçoit les données de la réponse. Maintenant, il doit enregistrer qu'un appel a été fait. Fais bien attention à cette partie. Quand ils trackent les métriques d'utilisation, les développeurs essaient souvent d'utiliser des variables d'instance de classe standards. Ils écrivent simplement un truc du genre self point api call count plus égal un. C'est une erreur fatale. Deep Agents exécute couramment des tools et des sous-agents en parallèle. Si plusieurs tools se résolvent au même moment et essaient de muter la même propriété d'instance directement, tu vas provoquer des race conditions. Tes compteurs vont s'écraser les uns les autres, des updates seront perdues, et tes métriques seront complètement fausses. Pour gérer les données de manière safe, tu dois plutôt mettre à jour le graph state. Le graph state est explicitement conçu pour gérer l'exécution en parallèle. Plutôt que de modifier une variable locale, ton middleware lit la métrique actuelle depuis le graph state, calcule la nouvelle valeur, et renvoie un objet state mis à jour en même temps que le résultat du tool. Le harness d'exécution prend le relais à partir de là. Il traite toutes les updates de state entrantes qui proviennent des exécutions de tools en parallèle, et les merge proprement sans collisions. En routant tous les side effects et le tracking des métriques via le graph state, ton middleware reste complètement thread-safe. Comprendre ce pattern débloque tout le framework. Tu arrêtes de traiter l'agent comme un système fermé et tu commences à le voir comme un pipeline transparent où chaque action peut être interceptée et mesurée en toute sécurité. C'est tout pour aujourd'hui. À la prochaine !

Salut, ici Alex de DEV STORIES DOT EU. Deep Agents, épisode 9 sur 16. Avoir un assistant de code IA, c'est génial, jusqu'à ce que tu doives lui rappeler pour la cinquantième fois que ton projet exige un typage strict et des variables en snake case. La solution ? Les conventions de projet via les fichiers mémoire. L'ergonomie développeur exige que tes outils s'adaptent à ta codebase, et non l'inverse. Tu ne devrais pas avoir à coller un guide de style dans chaque prompt. Deep Agents gère cela en donnant à l'agent une mémoire persistante grâce à un fichier spécifique nommé AGENTS point md. On confond parfois mémoire et compétences. La mémoire fournit ta base de référence universelle. Elle est toujours chargée au démarrage, ce qui la rend idéale pour les conventions globales et les règles architecturales. Les compétences sont des outils fonctionnels que l'agent charge dynamiquement, uniquement quand une tâche spécifique en a besoin. Aujourd'hui, nous regardons strictement la mémoire. Quand tu initialises un agent et que tu passes le paramètre memory, le framework injecte automatiquement le contenu du fichier AGENTS point md directement dans le context de l'agent avant qu'il ne fasse quoi que ce soit. Cette opération repose sur le protocole memory-first, qui dicte trois phases distinctes pour l'agent : la Recherche, la Réponse et l'Apprentissage. Lors de la phase de Recherche, l'agent lit le fichier mémoire pour comprendre l'environnement. Lors de la phase de Réponse, il génère le code ou répond au prompt. Vient ensuite la phase d'Apprentissage. Voici l'idée clé. Tu n'as pas besoin d'écrire manuellement le fichier AGENTS point md. L'agent met à jour ce fichier de manière autonome en fonction de tes retours. Prenons un scénario concret. Tu demandes à l'agent de générer un nouvel endpoint d'API. Il écrit un code fonctionnel, mais il formate les variables en CamelCase. Tu refuses la pull request et tu réponds que ce projet utilise strictement le snake case. L'agent corrige le code, mais il ne s'arrête pas là. Il entre dans la phase d'Apprentissage, ouvre le fichier AGENTS point md local et ajoute une nouvelle règle exigeant le snake case pour toutes les futures variables. La prochaine fois que tu demanderas un endpoint, l'agent lira ce fichier mémoire pendant sa phase de Recherche et écrira nativement en snake case dès le début. Ce système de mémoire persistante fonctionne sur deux scopes différents. Le premier est le scope global. Ce fichier se trouve dans ton répertoire utilisateur, à l'intérieur d'un dossier point deepagents. Tu l'utilises pour tes préférences personnelles de développeur. Si tu préfères toujours le Python asynchrone au code synchrone dans tous tes projets, l'agent l'apprend ici. Le second est le scope projet. Ce fichier se trouve directement dans le dossier de ton repository local. C'est là que vont les règles spécifiques au repository. Quand un agent s'exécute, il charge les deux fichiers. Il applique d'abord tes préférences globales, puis superpose les conventions spécifiques au projet. Comme le fichier mémoire du scope projet se trouve dans ton repository, tu le commites dans le version control. Quand un nouveau développeur rejoint l'équipe et lance l'agent, son instance locale hérite instantanément de toutes les décisions stylistiques que l'agent a déjà apprises. Chaque erreur corrigée améliore de façon permanente la compréhension de ton repository par l'agent, le faisant passer d'un générateur de code générique à un mainteneur hautement contextualisé. C'est tout pour cette fois. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 10 sur 16. Si tu balances cinquante guides de documentation d'API différents dans ton system prompt, ton agent ne deviendra pas plus intelligent. Il sera juste distrait et échouera sur des tâches de base. Il te faut un moyen de donner à un agent une expertise pointue sans exploser la context window. La divulgation progressive avec les skills résout exactement ce problème. Dans Deep Agents, un skill fonctionne comme une mise à jour modulaire de son cerveau. Il te permet de packager une logique complexe, comme des règles de deploy AWS ou des workflows de data science sur mesure, dans un répertoire isolé. Pour en créer un, il te suffit de créer un nouveau dossier, de lui donner le nom de ton skill, et d'y placer un fichier nommé exactement skill point md. On croit souvent à tort que le framework se contente d'ajouter tout le contenu de ce fichier au system prompt. Ce n'est pas le cas. Faire ça nous ramènerait directement au problème de surcharge de la context window, ce qui dégraderait les performances et augmenterait les coûts. À la place, le framework s'appuie sur un pattern appelé divulgation progressive, qui se déroule en trois étapes : Match, Read, et Execute. Tout en haut de ton fichier skill point md, tu écris un bloc frontmatter. Il est formaté en YAML basique et contient juste un nom et une courte description. Voici l'élément clé. Le framework ne charge que cette courte description dans le system prompt initial. L'agent lit la description et décide si elle correspond à la requête actuelle de l'utilisateur. C'est la phase de Match. Si l'agent décide que le skill est pertinent, il n'essaie pas de deviner quoi faire ensuite. Il utilise activement un tool interne pour récupérer le reste du fichier skill point md. C'est la phase de Read. Maintenant, l'agent a les instructions complètes et détaillées temporairement chargées dans sa mémoire de travail pour ce tour spécifique. Enfin, il passe à la phase d'Execute, où il suit ces instructions détaillées pour accomplir la tâche. Quand la conversation passe à un autre sujet, le lourd payload est abandonné, et l'agent retourne à son état de base. Imagine un scénario où tu veux créer un skill appelé langgraph-docs. Le frontmatter de ton fichier skill point md a une description indiquant que ce skill fournit des instructions et des URL internes pour chercher dans la documentation de LangGraph. Le corps du fichier contient ces fameuses URL internes et la méthodologie de recherche spécifique. Quand un utilisateur demande ce qu'est LangGraph, l'agent vérifie ses skills actifs. Il voit la courte description, réalise qu'il a besoin de plus d'informations pour répondre à la question, et demande le document complet. Il lit les URL, effectue la recherche, et formule une réponse précise. Sans la divulgation progressive, tu devrais coller toutes ces URL dans le prompt principal pour chaque conversation. En construisant une bibliothèque de skills, tu pourrais rencontrer des conflits où deux skills essaient de définir des instructions pour des tâches similaires. Deep Agents résout ça en utilisant la priorité des sources. La règle est simple : le dernier gagne. Le skill chargé en dernier va override les instructions conflictuelles des précédents. Ça te permet d'empiler d'abord des skills larges et génériques, puis d'ajouter des overrides très spécifiques plus tard dans ta configuration. L'exécution de tout ton workflow agentique repose sur la façon dont tu rédiges ce frontmatter. Garde tes descriptions précises et les corps de tes skills très détaillés, car l'agent ne lira le fichier complet que si tu le convaincs d'abord avec la description. C'est tout pour cet épisode. Merci de ton écoute, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 11 sur 16. Un assistant intelligent ne devrait pas te demander quelle base de données tu utilises à chaque fois que tu commences une nouvelle conversation. Pourtant, par défaut, la plupart des agents souffrent d'une amnésie totale dès qu'un thread se termine. Pour résoudre ça, tu as besoin de Long-term Memory Stores. Quand tu fais tourner un agent, il génère des fichiers. Les auditeurs pensent souvent que si un agent écrit un fichier, il reste pour toujours. Ce n'est pas le cas. Par défaut, tout est éphémère. Deep Agents utilise un StateBackend, qui stocke les fichiers dans le state du thread de conversation en cours. Quand ce thread se termine, ces fichiers disparaissent. Si tu veux une vraie personnalisation où l'agent construit une base de données permanente des préférences utilisateur et des connaissances du projet, il te faut une approche différente. Tu as besoin du StoreBackend. Il se connecte directement à un LangGraph Store persistant, ce qui garde les données en sécurité à travers plusieurs threads. Mais tu ne veux pas persister chaque fichier temporaire que ton agent crée. Tu as besoin d'un mécanisme pour séparer le travail éphémère de type scratchpad des mémoires durables. C'est là qu'intervient le CompositeBackend. Vois-le comme un routeur de trafic pour le file system de ton agent. Tu configures le CompositeBackend avec un fallback par défaut, généralement le StateBackend éphémère. Ensuite, tu enregistres explicitement une route pour ton stockage à long terme. Tu dis au routeur que tout chemin de fichier qui commence par le préfixe de répertoire slash memories slash doit être géré par le StoreBackend. Fais bien attention à cette partie. Cette persistance n'est pas automatique. Tu dois spécifiquement router le chemin slash memories slash vers le Store. Si tu sautes cette étape de routage, l'agent va juste écrire les fichiers de mémoire dans le state éphémère, et ils seront supprimés quand le thread se terminera. Une fois que tu introduis une base de données persistante, tu fais face à un nouveau problème. Tu ne peux pas avoir un utilisateur qui lit les préférences stockées d'un autre utilisateur. Pour éviter ça, le StoreBackend utilise des namespace factories. Une namespace factory est simplement une fonction qui injecte une couche d'isolation basée sur le contexte actuel. Au lieu de sauvegarder un fichier globalement, la factory génère un array de préfixes, comme le mot users suivi de l'ID utilisateur unique. À chaque fois que l'agent interagit avec le StoreBackend, la base de données scope automatiquement l'opération à ce namespace utilisateur exact. Regardons comment ça se passe en pratique. Tu lances la conversation un. Tu mentionnes que tu construis une application React. L'agent le note et écrit un résumé dans un fichier appelé project notes dot txt, en le plaçant spécifiquement dans le répertoire slash memories slash. Le CompositeBackend voit ce préfixe de répertoire, intercepte la commande d'écriture, et la route vers le StoreBackend durable sous ton namespace utilisateur isolé. Demain, tu lances la conversation deux. C'est un tout nouveau thread avec zéro contexte immédiat. Tu poses une question sur les frameworks de state management. Avant de répondre, l'agent vérifie son répertoire slash memories slash. Le CompositeBackend route la requête de lecture vers le store persistant. L'agent lit tes notes de projet, voit les détails sur React, et fournit une réponse ultra pertinente adaptée à ta stack spécifique. Le contexte est parfaitement conservé, même si les threads sont séparés. La persistance cross-thread demande un design délibéré en routant des répertoires spécifiques vers un store persistant et en les protégeant avec des namespaces spécifiques à l'utilisateur. Merci d'avoir passé quelques minutes avec moi. À la prochaine, à plus.

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 12 sur 16. Laisser une IA écrire du code, c'est impressionnant. Mais laisser cette IA exécuter aveuglément le code qu'elle vient d'écrire directement sur ton laptop, c'est une très mauvaise idée. Pour régler ça, il te faut un endroit sûr pour que l'agent puisse vérifier sa logique sans mettre en danger ta machine hôte. C'est exactement ce dont on va parler aujourd'hui : l'exécution de code dans des sandboxes. Si un agent ne peut pas exécuter de code, il ne peut pas vérifier si son code marche vraiment. Il se base uniquement sur ses données d'entraînement pour deviner si un script est correct. Les sandboxes donnent à l'agent un terrain de jeu sécurisé pour itérer, échouer et corriger les erreurs en se basant sur l'output réel de l'exécution. Avant de regarder comment ça marche, on doit clarifier une idée reçue. Tu pourrais penser que l'agent lui-même doit être déployé et exécuté à l'intérieur de la sandbox. Ce n'est pas le cas. Les Deep Agents se basent sur le pattern Sandbox as tool. La logique de l'agent, sa mémoire et ses prompts restent en toute sécurité sur ton serveur. L'agent se contente d'envoyer des commandes shell et du code via une API vers un environnement distant et isolé. Cette interaction se fait via le tool execute. Quand l'agent décide qu'il a besoin de lancer un script, il appelle le tool execute et lui passe le bloc de code généré. Ce tool transfère le payload à un backend de sandbox. Des providers comme Modal, Daytona et Runloop fournissent ces environnements. Ils provisionnent un conteneur sécurisé, exécutent le code et renvoient la standard output ou les logs d'erreur à l'agent. La sandbox crée une frontière d'isolation stricte entre l'espace d'exécution et ton système. Imagine un agent chargé de créer un petit package Python et de lancer une suite de tests avec pytest. L'agent se trouve sur ton serveur. Il utilise le tool execute pour contacter un serveur éphémère distant. D'abord, il envoie une commande pour installer les librairies requises. Ensuite, il écrit les fichiers Python dans le répertoire de la sandbox. Enfin, il envoie une commande pour lancer pytest. La sandbox exécute ces étapes et renvoie l'output du terminal. Si un test échoue, l'agent lit l'erreur dans la réponse de l'API, met à jour le code et appelle à nouveau le tool execute. L'agent peut faire un build, tester et tout effacer, pendant que ta machine hôte reste complètement intacte. Quand tu configures un backend de sandbox, tu dois définir son lifecycle. Il y a deux approches principales. La première est thread-scoped. Ici, la sandbox est liée à un thread de conversation spécifique. Quand la conversation démarre, une nouvelle sandbox est lancée. Quand la session utilisateur se termine, la sandbox est détruite. Ça garantit un environnement vierge pour chaque interaction et c'est idéal pour les opérations à tâche unique où les données n'ont pas besoin de persister. La deuxième approche est assistant-scoped. Dans ce modèle, la sandbox est liée à l'agent lui-même, peu importe la conversation active. Chaque thread qui interagit avec cet agent partage exactement le même state de la sandbox. Si un thread installe une version spécifique d'une librairie ou télécharge un gros dataset, ces fichiers restent disponibles pour le thread suivant. C'est le bon choix quand ton agent agit comme un worker persistant qui a besoin d'un workspace stable et continu. Voici le point clé. L'environnement d'exécution dicte les capacités de l'agent. En contrôlant le lifecycle de la sandbox et en imposant des frontières d'API strictes, tu donnes à l'agent la liberté de faire des erreurs sans compromettre ton infrastructure. La vraie puissance d'un agent, ce n'est pas juste de générer du code, mais d'itérer sur les échecs, et les sandboxes distantes offrent le seul moyen sécurisé de laisser cette itération se faire automatiquement. C'est tout pour aujourd'hui. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 13 sur 16. Tu lances une query complexe, ton agent superviseur délègue à trois sous-agents en parallèle, et ton utilisateur reste planté à regarder un loading spinner générique pendant deux minutes entières. C'est une expérience utilisateur catastrophique, et pour corriger ça, tu dois exposer exactement ce qui se passe sous le capot. La solution, c'est la Subgraph Streaming UX. Les workflows multi-agents sont par nature asynchrones et lents. Quand un agent principal délègue des tâches, ça crée une boîte noire. Si tu attends juste le résultat final combiné, l'utilisateur va croire que l'application a freezé. Tu dois streamer l'activité des sous-agents directement vers le frontend. Une erreur classique que font les développeurs ici, c'est de supposer que quand les sous-agents streament des tokens, ces tokens sont juste ajoutés aveuglément à l'output stream de l'agent principal. Si c'était vrai, les outputs parallèles s'entremêleraient pour donner une bouillie de texte illisible. Au lieu de ça, le framework gère le problème en isolant chaque événement dans son propre namespace. Pour que ça marche, tu utilises le format de streaming version deux et tu passes un flag qui met subgraphs à true quand tu appelles ton stream. Quand tu fais ça, le stream ne renvoie plus des chunks de texte bruts. Il renvoie des dictionnaires. Chaque dictionnaire contient trois clés spécifiques : type, ns, et data. Type t'indique quel genre d'événement tu es en train de regarder. Data contient le payload ou le token de texte. Et ns veut dire namespace. C'est la partie qui compte. Le namespace est un tuple qui définit le chemin exact du node qui a généré l'événement. Si un chunk vient de l'agent principal, le tuple du namespace est vide. S'il vient d'un sous-agent, le namespace contient le chemin. Ça ressemble à un tuple contenant le mot tools, suivi d'un ID unique de sous-agent. Disons que tu construis un dashboard frontend. Un utilisateur demande au système de planifier des vacances. L'agent superviseur lance trois sous-agents distincts : un pour les vols, un pour les hôtels, et un pour les activités. Dans ton code frontend, tu boucles sur le stream entrant. En vérifiant la clé namespace sur chaque chunk de dictionnaire, tu sais exactement quel sous-agent a généré ce token spécifique. Tu peux ensuite router ces data vers des composants UI séparés. Au lieu d'un seul spinner bloqué, ton utilisateur voit trois loading bars individuelles ou des fenêtres de texte se remplir avec des outputs en temps réel, côte à côte. Parfois, tu as besoin de streamer des informations qui ne sont pas juste un token de modèle de langage. Peut-être que tu veux pousser un status update custom, comme notifier l'UI qu'une API externe est en train d'être appelée. Tu peux faire ça depuis l'intérieur d'un node en utilisant la fonction get stream writer. Tu récupères le writer, tu lui passes ton dictionnaire custom, et il injecte ces data directement dans le stream global sous le namespace du sous-agent actuel. Le frontend le reçoit exactement comme n'importe quel autre événement et met à jour la bonne loading bar spécifique. Si tu veux nous aider à faire vivre l'émission, tu peux nous soutenir en cherchant DevStoriesEU sur Patreon. La transparence multi-agents est fondamentalement un problème de routing ; mapper des tuples de namespace à des composants UI indépendants, c'est ce qui transforme une boîte noire frustrante en une expérience utilisateur premium. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de coder !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 14 sur 16. Et si tu pouvais connecter ton agent terminal local à la base de données propriétaire de ta boîte sans écrire une seule ligne de code Python ? C'est exactement pour ça qu'on va parler de la CLI Deep Agents et des External MCP Tools. Le SDK Deep Agents fournit une CLI intégrée out of the box. Tu lances le process, et tu obtiens un prompt dans ton terminal où tu peux discuter avec ton agent. Tu peux gérer le cerveau central de l'agent directement depuis ce prompt. Si tu as besoin d'un moteur de raisonnement plus puissant, il te suffit de taper slash model suivi de l'identifiant du nouveau modèle. La CLI fait un hot-swap du provider instantanément, et tu continues ta session. Mais un agent dans le terminal qui ne fait que discuter, c'est pas très utile. Il a besoin d'accéder à ton vrai travail. Normalement, donner accès à un agent à un repo GitHub ou à une base de données locale nécessite d'écrire un wrapper Python custom pour gérer les appels d'API. La CLI évite ça complètement en utilisant le Model Context Protocol, plus connu sous le nom de MCP. Il y a souvent de la confusion sur ce qu'est vraiment MCP. Ce n'est pas une librairie Python que tu importes dans le code de ton agent. Un serveur MCP est un process entièrement séparé ou une URL distante. Il agit comme un wrapper standardisé autour d'un système externe. Quand la CLI démarre, elle parle à ce process séparé, lui demande quels tools il fournit, et les charge dynamiquement. Tu configures cette connexion avec un simple fichier texte nommé point mcp point json. Ce fichier est le cœur des intégrations zero-code. Quand tu lances la CLI Deep Agents, elle fait de l'auto-discovery. Elle cherche cette configuration json dans ton répertoire courant. Si elle en trouve une, elle se connecte aux serveurs listés à l'intérieur, enregistre leurs tools, et les passe à ton agent. Ce fichier de configuration supporte deux mécanismes de transport. Le premier, c'est l'entrée et la sortie standard, ou stdio. C'est pour les serveurs locaux. La CLI spawn le serveur comme un process en background sur ta machine et communique avec lui via les streams standards du terminal. Le deuxième type de transport repose sur HTTP et les Server-Sent Events. Tu utilises ça quand ton serveur MCP est hébergé à distance, peut-être situé dans un réseau d'entreprise privé. Parce que les serveurs stdio exécutent des commandes locales, la sécurité est une priorité. La CLI maintient un trust store local pour les serveurs au niveau du projet. La toute première fois que la CLI détecte une nouvelle commande de serveur local dans ton fichier point mcp point json, elle s'arrête et demande une permission explicite. Une fois que tu l'approuves, le hash de cette commande est sauvegardé dans ton trust store, et les futurs runs se connectent automatiquement. Regardons un scénario spécifique. Tu veux que ton agent lise des fichiers sur ton disque local. Tu crées un fichier point mcp point json. À l'intérieur, tu définis un bloc server et tu le nommes local-filesystem. Tu règles le type de transport sur stdio. Pour la ligne de commande, tu lui dis de lancer l'outil du node package manager, npx, en le pointant vers un serveur communautaire pre-built appelé server-filesystem, avec le chemin du répertoire que tu veux exposer. Tu sauvegardes le fichier et tu lances la CLI Deep Agents. Voici le point clé. La CLI spawn automatiquement cette commande npx en background. Le serveur filesystem boote et broadcast qu'il a des tools pour lire des fichiers et lister des répertoires. La CLI capte ce broadcast et équipe ton agent. Tu peux immédiatement taper dans ton terminal, pour demander à l'agent de lire ton fichier de log système. L'agent comprend qu'il a le tool, appelle le process en background, récupère le contenu du fichier, et répond à ta question. Tu viens de donner à un système d'IA un accès sécurisé à ton disque local en utilisant quelques lignes de texte de configuration. En découplant la logique des tools de ton application Python, MCP transforme ton terminal d'une simple interface de chat en un centre de contrôle extensible. C'est tout pour aujourd'hui. À la prochaine !

Salut, ici Alex de DEV STORIES DOT EU. Deep Agents, épisode 15 sur 16. Pourquoi te contenter d'un assistant de code générique quand tu peux injecter ton propre agent LangGraph ultra-personnalisé directement dans ton éditeur de code ? Le protocole qui sort ton agent sur mesure du terminal pour l'amener dans ton workflow quotidien, ce sont les Editor Integrations via ACP. Avant d'aller plus loin, on doit clarifier une collision d'acronymes. Tu as probablement déjà entendu parler de MCP, ou Model Context Protocol. MCP connecte ton agent à des tools externes, ce qui lui permet de chercher dans une database ou de lire un file system. ACP, le Agent Client Protocol, est complètement différent. ACP connecte ton agent à des IDE externes, comme Zed ou VSCode. L'un connecte l'agent à des data externes, l'autre connecte l'agent à ton workspace. ACP est une couche de communication standardisée. Elle définit exactement comment un Integrated Development Environment envoie des sélections de texte, des structures de fichiers et des prompts utilisateur à un agent IA. Elle dicte aussi comment cet agent renvoie des insertions de code, des diffs de fichiers et des réponses de chat. En implémentant ce protocole, ton deep agent custom se comporte exactement comme un assistant prêt à l'emploi dans ton éditeur. La différence, c'est qu'il possède toutes les structures de mémoire spécifiques, les templates de prompt custom et les tools internes spécialisés que tu as buildés dedans. Pour faire le pont, tu installes le package deepagents-acp. L'intégration demande un script Python très court pour servir d'entry point. Dans ce script, tu instancies ton deep agent préconfiguré. Ensuite, au lieu de démarrer un serveur web ou une boucle en ligne de commande, tu wrappes ton agent dans une interface de serveur ACP. Tu fais ça en appelant une fonction run dédiée et en lui passant un objet AgentServerACP, qui wrappe lui-même la logique sous-jacente de ton agent. Voici le point clé. Quand tu configures ce serveur, tu le paramètres pour utiliser le standard input et output, plus connu sous le nom de mode stdio. C'est crucial parce que ça veut dire qu'il n'y a pas de ports réseau à gérer, pas de règles de firewall à contourner, et pas de WebSockets à débugger. Le process de l'agent écoute simplement les strings de texte entrantes sur le standard input et affiche ses réponses structurées sur le standard output. Ensuite, tu dois connecter ton éditeur à ce script. Prenons l'éditeur Zed comme scénario concret. Dans Zed, tu ouvres ton fichier JSON de user settings. Tu ajoutes un bloc de configuration qui indique à l'éditeur d'utiliser un agent custom. Au lieu de pointer Zed vers un endpoint d'API REST distant, tu le pointes directement vers ton exécutable Python local, en fournissant le chemin vers ton nouveau script ACP comme argument principal. Quand tu démarres une session, l'éditeur lance ton script Python comme un process en background caché. À chaque fois que tu demandes un inline edit ou que tu highlight une fonction pour du refactoring, l'éditeur envoie un message ACP structuré via le standard input directement à ton script en cours d'exécution. Ton agent custom traite la requête, parcourt son node graph interne, interroge sa mémoire, et affiche la réponse au format ACP sur le standard output. L'éditeur capture cet output et applique les changements de code nativement dans ta fenêtre d'application. La chose la plus importante à retenir ici, c'est le contrôle. En routant ton agent custom via ACP sur stdio, tu arrêtes de dépendre d'un assistant générique et tu commences à collaborer avec une entité qui comprend intrinsèquement les conventions spécifiques de ta codebase. C'est tout pour cet épisode. Merci pour ton écoute, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. Deep Agents, épisode 16 sur 16. Tu demandes à ton agent un refactor massif de ta codebase, et l'interface de chat freeze instantanément. Tu restes bloqué devant un loader qui tourne pendant vingt minutes, incapable de poser des questions ou de changer d'avis. Pour résoudre ça, tu as besoin de Background Workers avec des Async Subagents. Les subagents standards sont synchrones. Ils bloquent le main thread. Le superviseur leur confie une tâche et attend simplement qu'elle se termine. Les async subagents changent complètement cette dynamique en s'exécutant comme des background workers non bloquants. Quand le superviseur assigne du travail, il n'attend pas le résultat. Il reçoit immédiatement un job ID et rend la main à l'utilisateur. L'interface utilisateur reste réactive pendant que le gros du travail se fait ailleurs. Tu configures ces background workers en utilisant la spécification Async SubAgent. Quand tu déploies ton application sur LangSmith Deployments, ces async subagents sont hébergés indépendamment. Le superviseur principal communique avec eux via des protocoles de transport standards. Si tu déploies le worker exactement sur le même serveur que le superviseur, ils communiquent en utilisant ASGI, ce qui est super efficace pour le routing local. Si le worker se trouve sur un serveur distant séparé, le superviseur s'y connecte via HTTP. Pour orchestrer ces remote workers, le superviseur est équipé d'une suite spécifique d'async tools. Repense à cette demande de refactor de la codebase. L'utilisateur demande la réécriture. Le superviseur décide que ça va prendre du temps et appelle le tool start async task. Ce tool lance le subagent coder et transmet un job ID au superviseur. Le superviseur répond à l'utilisateur, en confirmant que le background job est en cours d'exécution. Comme le main thread est libre, l'utilisateur peut continuer la conversation. Quelques minutes plus tard, l'utilisateur peut demander comment avance le refactor. Le superviseur appelle le tool check async task, en passant le job ID, et récupère le statut d'exécution actuel auprès du worker. Voici le point clé. L'utilisateur n'est pas bloqué en dehors du process pendant que le worker tourne. Si l'utilisateur se rend compte soudainement qu'il a besoin que le refactor impose un strict type hinting, il peut juste le dire au superviseur. Le superviseur appelle alors le tool update async task. Ça pousse de nouvelles instructions de pilotage à la volée directement au subagent en cours d'exécution, sans redémarrer le job de zéro. Si l'utilisateur décide que le refactor était finalement une mauvaise idée, le superviseur utilise le tool cancel async task pour terminer proprement le background process. Un point de confusion fréquent, c'est comment le superviseur se souvient de ces jobs pendant une longue session. Avec le temps, les historiques de chat sont compressés pour économiser des context tokens. Si le job ID n'existait que sous forme de texte dans l'historique de conversation, le superviseur finirait par l'oublier et perdrait la trace du worker. Pour éviter ça, les metadata de la tâche ne sont jamais stockées uniquement dans le chat log. Elles sont sauvegardées dans un state channel dédié appelé async tasks. Ce state channel fonctionne indépendamment de la liste des messages, garantissant que les job IDs actifs survivent à n'importe quelle compression de la conversation. Passer des blocking calls aux background workers fait évoluer ton architecture d'une simple interface de chat vers un moteur d'orchestration parallèle capable de gérer des workloads massifs. Comme ça conclut notre série actuelle, je t'encourage à lire la documentation officielle, à essayer de déployer un async worker toi-même, ou à visiter devstories dot eu pour suggérer des sujets pour notre prochaine saison. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.