DeepAgents : comment LangChain révolutionne les agents IA avec le Context Engineering

Pourquoi vos agents LangChain classiques atteignent leurs limites

Si vous travaillez avec LangChain, votre agent ressemble probablement à ceci :

from langchain.agents import create_react_agent, AgentExecutor
from langchain_openai import ChatOpenAI
from langchain.tools import tool

@tool
def search_confluence(query: str) -> str:
    """Recherche dans Confluence."""
    return results

llm = ChatOpenAI(model="gpt-4o")
agent = create_react_agent(llm, tools=[search_confluence], prompt=prompt)
executor = AgentExecutor(agent=agent, tools=[search_confluence])

C'est le pattern ReAct : Reason, Act, Observe, en boucle. Ça fonctionne très bien pour des tâches courtes et bien délimitées. Mais vous avez forcément rencontré ses limites : l'agent oublie ce qu'il a fait trois tours plus tôt, il rappelle des outils déjà utilisés et, sur une tâche de dix étapes, il commence à halluciner sur des données qu'il avait pourtant récupérées.

Ce n'est pas un bug de votre code. C'est une limite structurelle : l'agent ReAct n'a aucun mécanisme de gestion du contexte sur la durée.

"Quand les agents échouent, c'est parce qu'ils n'ont pas le bon contexte. Quand ils réussissent, c'est parce qu'ils l'ont." – Harrison Chase, CEO de LangChain

DeepAgents part de ce constat et propose une réponse architecturale. Il ne remplace pas LangChain. Il construit, par-dessus LangGraph (le runtime bas niveau de LangChain), une couche "harness" qui prend en charge tout ce que vous deviez gérer à la main.

Ce que DeepAgents change au niveau du paradigme

Avec un agent LangChain classique, vous passez votre temps à faire du function engineering : vous écrivez des outils Python, vous soignez leur docstring pour que le LLM comprenne quand les utiliser, vous construisez vos chains. C'est du travail de bas niveau, et vous recommencez pour chaque nouveau cas d'usage.

DeepAgents pousse vers le context engineering : la performance de l'agent dépend moins de la qualité des fonctions individuelles que de ce que l'agent sait faire, quand il le sait, et comment il gère ce qu'il apprend en chemin. Quatre mécanismes incarnent ce changement.

1. Le system prompt structuré

Le premier mécanisme est un system prompt riche, directement inspiré de l'architecture de Claude Code. Il ne se résume pas à une instruction métier. Il embarque des règles de comportement détaillées, des exemples d'utilisation des outils ainsi que des instructions anti-dérive pour les tâches longues. Ce n'est pas un paramètre cosmétique : c'est le premier niveau de context engineering.

2. L'outil de planification (write_todos)

write_todos est l'idée la plus surprenante, et probablement la plus efficace. C'est un outil "no-op" : il n'exécute rien. Il force simplement l'agent à décomposer sa tâche en sous-étapes avant d'agir. L'agent maintient une todo-list explicite dans son contexte, qu'il coche au fur et à mesure. Si vous avez déjà essayé le "chain of thought" ou le "pense étape par étape" dans un prompt, vous savez que ça ne tient pas sur vingt tours. Ici, la planification est imposée architecturalement, pas suggérée.

3. Les sous-agents (task tool)

L'outil task permet à l'agent principal de déléguer une sous-tâche à un agent spécialisé avec son propre contexte isolé. Seul le résultat final remonte à l'orchestrateur. Concrètement : si votre agent doit parcourir quinze sources web, lire des PDF et synthétiser, il délègue chaque partie à un sous-agent. L'orchestrateur ne voit jamais les dizaines d'appels intermédiaires. Il reçoit une synthèse propre, ce qui lui laisse de la place pour continuer à raisonner.

4. Le filesystem comme mémoire de travail

Les outils ls, read_file, write_file, edit_file transforment le filesystem en scratchpad persistant pour l'agent. Une recherche web retourne facilement 60 000 tokens. Plutôt que d'inonder le contexte, l'agent écrit le résultat brut dans un fichier et relit uniquement ce dont il a besoin. C'est de la gestion de contexte par externalisation.

Les Skills : le vrai saut qualitatif

C'est ici que DeepAgents s'éloigne le plus radicalement de l'approche LangChain classique.

Du docstring au SKILL.md

Avec un agent LangChain, vous documentez vos outils via des docstrings Python. C'est limité : quelques lignes de texte, une description des paramètres. L'agent sait qu'un outil existe et ce qu'il fait, mais pas comment bien l'utiliser dans un contexte complexe. Les Skills de DeepAgents remplacent cette approche par des fichiers SKILL.md. Ce ne sont pas des fonctions décorées : ce sont des documents Markdown structurés qui décrivent un workflow complet. Un SKILL.md peut contenir :

• le contexte métier de la compétence
• les étapes à suivre dans l'ordre
• les cas limites à anticiper
• des exemples de bonne et mauvaise utilisation
• les outils à combiner pour obtenir le résultat attendu

---
name: incident-analysis
description: Analyse un incident de production et produit un rapport structuré
triggers: ["incident", "postmortem", "alerte", "panne"]
---

## Workflow

1. Récupérer les logs sur la fenêtre temporelle concernée avec grep
2. Identifier les services impactés via les traces distribuées
3. Corréler avec les déploiements récents (fenêtre -2h)
4. Produire un rapport au format : résumé / timeline / cause racine / actions

## Règles

- Toujours inclure les métriques avant/après l'incident
- Si la cause racine est incertaine, le mentionner explicitement
- Escalader si l'incident affecte plus de 3 services critiques

La progressive disclosure : le contexte au bon moment

L'agent ne charge pas tous les skills au démarrage. Il lit d'abord les frontmatters de chaque SKILL.md (nom, description, triggers) et ne charge le contenu complet que lorsqu'il détermine que le skill est pertinent pour la tâche en cours. C'est ce que la doc LangChain appelle la "progressive disclosure" : vous ne polluez pas la fenêtre de contexte avec des instructions qui ne servent pas.

agent = create_deep_agent(
    model="openai:gpt-4o",
    tools=[search_logs, get_deployments],
    skills=["/skills/incident-analysis/", "/skills/reporting/"],
)

Skills vs Memory

DeepAgents distingue deux niveaux de contexte permanent :

• Memory (AGENTS.md) : toujours injecté dans le contexte. À garder minimal, pour les préférences générales de l'agent ou les règles transversales.
• Skills (SKILL.md) : chargés à la demande. Pour les workflows spécialisés et la connaissance métier profonde.

Cette distinction est importante : vous n'avez plus à choisir entre "je mets tout dans le system prompt" et "je ne mets rien". Vous architecturez la base de connaissances de l'agent comme vous architecturez votre code.

Les Backends : choisir où l'agent opère

C'est une dimension souvent ignorée dans les articles sur DeepAgents, mais elle est fondamentale pour la production.

Le concept de backend

Toutes les opérations de fichiers de l'agent (ls, read_file, write_file, execute) passent par un BackendProtocol. Ce protocole abstrait où et comment ces opérations sont exécutées. Cela signifie que votre agent peut travailler dans des environnements radicalement différents sans changer une ligne de code métier.

Les backends natifs

StateBackend (par défaut) : les fichiers sont stockés dans l'état LangGraph, en mémoire pour le thread en cours. Éphémère. C'est parfait pour un agent conversationnel ou des tâches one-shot.

agent = create_deep_agent(model="openai:gpt-4o")  # StateBackend par défaut

FilesystemBackend : accès direct au filesystem local avec un répertoire racine configurable. Adapté au développement et aux pipelines CI/CD où l'agent doit lire et écrire des fichiers réels.

from deepagents.backends import FilesystemBackend

agent = create_deep_agent(
    model="openai:gpt-4o",
    backend=FilesystemBackend(root_dir="/workspace/projet")
)

LocalShellBackend : filesystem local plus accès shell complet via l'outil execute. Pas d'isolation. À réserver aux environnements de développement contrôlés.

StoreBackend : persistance cross-thread via le LangGraph Store. Utile pour les agents qui doivent mémoriser des informations d'une session à l'autre.

Les backends sandbox (tiers)

Pour la production, DeepAgents s'intègre avec des environnements d'exécution isolés : Modal, Daytona, Deno, et LangSmith Sandbox. L'agent a alors accès à l'outil execute pour lancer des commandes shell dans un environnement sécurisé et reproductible.

from deepagents.backends.modal import ModalSandboxBackend

agent = create_deep_agent(
    model="openai:gpt-4o",
    backend=ModalSandboxBackend()
)

Le CompositeBackend : router les opérations

Le CompositeBackend est la pièce la plus puissante. Il vous permet de router différents chemins vers différents backends. Par exemple : tout en éphémère par défaut, mais /memories/ persisté dans le LangGraph Store pour garder les informations critiques entre les sessions.

from deepagents.backends import CompositeBackend, StateBackend, FilesystemBackend

agent = create_deep_agent(
    model="openai:gpt-4o",
    backend=CompositeBackend(
        default=StateBackend(),
        routes={
            "/memories/": FilesystemBackend(root_dir="/deepagents/agent-memory"),
            "/outputs/": FilesystemBackend(root_dir="/workspace/outputs"),
        }
    )
)

Implémenter son propre backend

C'est là que le design de DeepAgents brille vraiment. L'interface BackendProtocol est publique et documentée. Vous pouvez écrire votre propre backend pour projeter n'importe quel système de stockage dans l'espace de fichiers de l'agent : S3, PostgreSQL, ChromaDB, une API interne.

from deepagents.backends.protocol import (
    BackendProtocol, WriteResult, ReadResult, LsResult, EditResult
)

class S3Backend(BackendProtocol):
    def __init__(self, bucket: str, prefix: str = ""):
        self.bucket = bucket
        self.prefix = prefix

    def write(self, file_path: str, content: str) -> WriteResult:
        # Écriture dans S3
        ...

    def read(self, file_path: str) -> ReadResult:
        # Lecture depuis S3
        ...

Avec ce pattern, votre agent de documentation peut lire directement depuis votre base de connaissances S3, tandis que votre agent de données peut interroger PostgreSQL comme si c'était un filesystem. Le code métier de l'agent ne change pas.

Ce qu'il faut surveiller

• Attention aux coûts en tokens : un agent qui planifie, délègue à des sous-agents et maintient des skills en contexte consomme significativement plus de tokens qu'un appel ReAct classique. Calculez vos volumes avant de déployer à grande échelle.
• La maturité du projet : DeepAgents a été lancé en juillet 2025. La v0.5 apporte les sous-agents asynchrones et le support multimodal, mais l'écosystème reste jeune. La communauté est partagée : certains développeurs sur Hacker News reprochent une sur-complexification. La critique est légitime pour des cas d'usage simples.
• Le support TypeScript est en retard : DeepAgentsJS est en cours de refonte. Si votre stack est Node.js, attendez encore un peu.

Pour aller plus loin

DeepAgents est open source sous licence MIT. La documentation officielle couvre en détail les backends, les skills et le context engineering. Le blog LangChain de Harrison Chase explique le raisonnement derrière l'architecture et la genèse du projet à partir de Claude Code, une lecture qui éclaire bien le shift entre le function engineering et le context engineering.

La vraie question avant d'adopter n'est pas "est-ce mieux que mes agents actuels ?". C'est "est-ce que mes agents ont besoin de tenir sur la durée, de capitaliser sur une connaissance métier structurée et de s'exécuter dans des environnements variés ?" Si oui, DeepAgents répond à ces trois besoins d'un coup.