Pendant un temps, l'« ingénierie des prompts » était le nom que nous donnions à l'art d'obtenir de bons résultats des grands modèles de langage. C'était logique à l'époque. La plupart des gens utilisaient des interactions en une seule passe, et le principal levier semblait vraiment être la formulation : demander plus clairement, ajouter un exemple, contraindre le format, et le modèle se comportait mieux.
Ce cadre est désormais trop étroit pour le vrai problème.
Quand un système d'IA échoue en production, le problème n'est généralement pas que le modèle avait besoin d'une phrase plus ingénieuse dans le prompt système. Le problème, c'est que le modèle n'a pas vu les bonnes informations, a vu trop d'informations non pertinentes, a vu les bonnes informations dans le mauvais format, ou n'a pas pu transmettre le bon état d'une étape à l'autre. En d'autres termes, le problème n'était pas seulement le prompt. Le problème était l'ensemble du pipeline de contexte.
C'est pourquoi le terme ingénierie du contexte s'est imposé. L'expression est entrée dans le débat mainstream de l'IA à mi-2025, quand Tobi Lütke et Andrej Karpathy ont soutenu que l'« ingénierie des prompts » sous-estimait le vrai travail impliqué dans la construction de systèmes LLM fiables.[1] Mais la discipline sous-jacente est plus ancienne que le nom. Si vous avez construit du RAG, des appels d'outils, des systèmes de mémoire, de la summarisation ou des boucles d'évaluation, vous avez déjà fait des morceaux d'ingénierie du contexte. Ce qui a changé, c'est que nous avons enfin un nom qui décrit l'ensemble du travail.
Si vous voulez l'image la plus simple possible, l'ingénierie du contexte est la couche entre le monde extérieur et la mémoire de travail du modèle.
flowchart TD\n U[\"Requête utilisateur\"] --> CE[\"Moteur de contexte\"]\n\n I[\"Instructions et politiques\"] --> CE\n R[\"Connaissances récupérées\"] --> CE\n M[\"Mémoire et état sauvegardé\"] --> CE\n T[\"Définitions et résultats d'outils\"] --> CE\n H[\"Historique récent de conversation\"] --> CE\n\n CE --> W[\"Fenêtre de contexte du modèle\"]\n W --> L[\"Le LLM raisonne et agit\"]\n L --> O[\"Réponse ou appel d'outil\"]\n O --> S[\"Nouvelle mémoire, logs et état\"]\n S --> CEC'est tout le jeu.
Le modèle est le moteur de raisonnement. Le moteur de contexte décide sur quoi le modèle peut raisonner.
Une raison pour laquelle ce terme résonne est qu'il relie plusieurs fils qui évoluaient séparément.
La génération augmentée par récupération, ou RAG, nous a appris que les modèles ont besoin d'accéder à des connaissances externes au moment de l'inférence.[2] ReAct nous a appris que le raisonnement et l'action fonctionnent mieux quand les modèles peuvent appeler des outils, observer les résultats et continuer à partir de là.[3] La recherche sur la mémoire nous a appris que les assistants à long terme ont besoin de stratégies d'indexation, de récupération et de lecture plutôt que d'une accumulation infinie de transcriptions.[4] L'évaluation des longs contextes a montré que simplement bourrer plus de tokens dans un modèle n'est pas la même chose que lui donner une meilleure mémoire de travail.[5][6][7]
Vu ainsi, l'ingénierie du contexte n'est pas un remplacement de ces idées. C'est le parapluie au-dessus d'elles.
Ce parapluie est important parce que les systèmes d'IA modernes ne sont plus des prompts isolés. Ce sont des systèmes dynamiques qui assemblent des instructions, des documents, des données structurées, des sorties d'outils et des états antérieurs dans une fenêtre de contexte temporaire pour l'étape suivante. LangChain l'a bien décrit en définissant l'ingénierie du contexte comme le travail de fournir les bonnes informations et les bons outils dans le bon format pour que le LLM puisse vraisemblablement accomplir la tâche.[8]
L'expression « vraisemblablement accomplir la tâche » fait beaucoup de travail ici. C'est le bon test.
Si un agent échoue, la première question ne devrait pas être : « Comment rendre le prompt plus intelligent ? »
La première question devrait être : « Ai-je vraiment donné au modèle ce dont il avait besoin pour réussir ? »
L'ingénierie des prompts est toujours importante. Elle est simplement devenue un sous-ensemble d'une discipline plus large.
L'ancien modèle mental était :
| Ingénierie des prompts | Ingénierie du contexte |
|---|---|
| Écrire de meilleures instructions | Construire l'environnement informationnel complet |
| Se concentrer sur une seule requête | Se concentrer sur des systèmes multi-étapes |
| Principalement statique | Dynamique et avec état |
| Optimiser la formulation | Optimiser la sélection, la structure, la mémoire et les outils |
| Améliorer un seul appel de modèle | Améliorer toute la boucle |
Cette distinction devient évidente dès que vous construisez un agent.
Supposons que vous construisiez un agent de support pour un logiciel d'entreprise. L'utilisateur demande : « Pourquoi nos requêtes API expirent-elles ? »
Si vous pensez uniquement en termes de prompt, vous pourriez améliorer la formulation :
Ce sont de bonnes améliorations. Mais elles ne suffisent pas.
Les vraies questions système sont plus difficiles :
C'est ça, l'ingénierie du contexte.
Le prompt n'est qu'un élément parmi d'autres.
En pratique, le contexte inclut tout ce que le modèle voit au moment de l'inférence, pas seulement le prompt visible.[8][9]
Cela signifie généralement :
C'est pourquoi l'expression « remplir la fenêtre de contexte » est devenue si centrale. La fenêtre de contexte n'est pas seulement un endroit où le texte va. C'est la mémoire de travail temporaire du modèle. Tout ce qui y entre est en compétition pour l'attention.
Et la compétition est le mot clé.
Chaque token supplémentaire n'est pas seulement une information additionnelle. C'est aussi une distraction supplémentaire.
L'une des idées fausses les plus courantes sur le marché actuel de l'IA est que les fenêtres de contexte plus grandes ont rendu l'ingénierie du contexte moins importante.
La recherche pointe dans la direction opposée.
Lost in the Middle a montré que les modèles utilisent souvent les longs contextes de manière inégale, obtenant de meilleures performances quand les informations pertinentes apparaissent près du début ou de la fin, et de moins bonnes performances quand les informations importantes se trouvent au milieu.[5] L'étude RAG à long contexte de Databricks a constaté que si l'ajout de plus de documents récupérés peut aider, seul un petit nombre de modèles de pointe maintenaient de bonnes performances au-delà de 64k tokens.[6] Le rapport Context Rot de Chroma est allé encore plus loin : même des tâches simples deviennent moins fiables à mesure que la longueur des entrées augmente, surtout quand l'ambiguïté et les distracteurs sont introduits.[7]
C'est la partie que beaucoup d'équipes apprennent à la dure.
Les fenêtres plus grandes n'éliminent pas le besoin de choisir. Elles rendent le coût des mauvais choix moins évident au début et plus douloureux ensuite.
Un long prompt peut échouer d'au moins quatre façons différentes :
C'est pourquoi l'ingénierie du contexte ne consiste pas à maximiser les tokens. Il s'agit de maximiser la densité du signal dans la fenêtre de contexte.
C'est là qu'entre en jeu l'une des meilleures idées récentes.
Jason Liu a soutenu que la prochaine étape après le RAG classique basé sur des chunks est d'arrêter de penser uniquement aux « passages les plus similaires » et de commencer à penser à la forme de l'espace de recherche.[10] Son cadre est particulièrement utile parce qu'il trace une progression que beaucoup d'équipes traversent déjà :
Les trois premiers sont des améliorations de ce qui est récupéré.
Le quatrième est plus intéressant. Il améliore ce que l'agent apprend sur le corpus lui-même.
Les facettes donnent au modèle quelque chose comme une vision périphérique. Au lieu de ne retourner que les quelques meilleurs chunks, le système peut aussi retourner des métadonnées agrégées :
Cela compte parce que la recherche par similarité est biaisée vers ce qui est le plus facile à faire correspondre, pas nécessairement ce qui est le plus important à inspecter.[10] Un système de récupération peut sur-exposer des incidents résolus bien documentés et sous-exposer des incidents rares encore ouverts. Une recherche juridique peut sur-exposer des contrats signés et cacher les non signés qui nécessitent réellement attention. Les facettes aident l'agent à voir non seulement « ce qui correspond », mais « ce qui existe à proximité ».
C'est un changement conceptuel majeur.
Le RAG concernait principalement la récupération.
L'ingénierie du contexte concerne de plus en plus la navigation.
La façon la plus simple de rendre l'ingénierie du contexte concrète est de la décomposer en missions réelles qu'elle accomplit.
La première mission est de décider ce qui mérite d'entrer dans la fenêtre.
Cela inclut la récupération, le classement, le filtrage, le choix des sources et les vérifications de fraîcheur. Cela semble évident, mais c'est encore là qu'une grande partie de la qualité est gagnée ou perdue. Des benchmarks comme BRIGHT montrent que la récupération réaliste est bien plus difficile que ce que suggère la correspondance sémantique de surface.[11] Si votre qualité de récupération est faible, aucune quantité de polissage de prompt en aval ne sauvera pleinement le résultat.
La sélection n'est pas seulement « trouver des chunks pertinents ». C'est :
Les bons systèmes récupèrent souvent moins que les systèmes naïfs, mais le font plus intentionnellement.
La deuxième mission est de décider comment le contexte choisi est représenté.
La même information peut être utile ou inutile selon le formatage. Les conseils d'Anthropic sur l'utilisation des outils sont explicites à ce sujet : les descriptions et interfaces d'outils influencent fortement le comportement du modèle.[9] Les conseils sur les prompts à long contexte font des recommandations similaires pour le balisage XML, l'étiquetage des sources et les sections de documents clairement séparées.[12]
En pratique, la structure signifie :
Un résultat court et bien étiqueté surpasse souvent un énorme blob JSON.
La troisième mission est de réduire le contexte sans détruire ce qui compte.
C'est là que beaucoup de systèmes d'agents s'améliorent considérablement ou se dégradent fortement.
La compression peut signifier :
La documentation de mise en cache des prompts d'OpenAI montre que l'ordre des prompts compte économiquement autant que cognitivement : les préfixes partagés statiques sont moins chers et plus rapides quand ils sont placés en tête parce que les hits de cache dépendent de la réutilisation exacte du préfixe.[13] Le travail plus récent d'OpenAI sur la compaction via l'API Responses pousse la même idée plus loin en traitant l'historique d'un agent à long terme comme quelque chose qui devrait être compressé en une représentation plus efficace en tokens avant que la fenêtre ne se remplisse.[14]
La compression n'est pas optionnelle. La seule question est de savoir si vous la faites délibérément ou si vous laissez la fenêtre de contexte se dégrader d'elle-même.
La quatrième mission est de décider ce qui doit persister au-delà du tour actuel.
C'est là que beaucoup d'équipes font la même erreur : elles confondent mémoire et rétention de transcription.
Mais une bonne mémoire n'est pas « tout garder pour toujours ». LongMemEval cadre la mémoire à long terme comme un problème en trois étapes : indexation, récupération et lecture.[4] C'est la bonne façon d'y penser. Un système de mémoire devrait aider le modèle à retrouver le bon fait antérieur au bon moment, pas le noyer dans le passé complet.
Cela conduit à une distinction utile :
Si tout reste en mémoire de travail, le modèle se distrait.
Si tout est poussé dehors, le modèle perd la continuité.
L'ingénierie du contexte décide ce qui appartient à chaque couche.
La cinquième mission est de rendre les outils lisibles pour le modèle.
C'est une partie sous-estimée de la discipline. Une surface d'outil n'est pas seulement de la conception d'API logicielle. C'est aussi de la conception de contexte.
Le modèle doit comprendre :
C'est pourquoi les descriptions d'outils sont si importantes.[9] C'est aussi pourquoi l'accent mis par Jason Liu sur les résultats des outils est important.[10] La sortie d'un outil ne répond pas seulement à la requête actuelle. Elle apprend à l'agent comment penser à la prochaine requête.
Quand la surface des outils devient standardisée via un protocole comme MCP, cela devient encore plus important. MCP facilite la connexion d'outils, de ressources et de prompts aux applications LLM, mais il ne décide pas quelles informations doivent être exposées, comment elles doivent être filtrées, ou quelle quantité doit être injectée dans le prochain appel de modèle.[15] Le protocole est la plomberie. L'ingénierie du contexte est toujours le savoir-faire.
La sixième mission est de décider quand ne pas partager le contexte.
C'est l'une des plus grandes différences entre les démos jouets et les agents en production.
Parfois, la bonne réponse n'est pas un prompt partagé plus grand. Ce sont plusieurs prompts plus petits avec des portées isolées.
Le système de recherche multi-agents d'Anthropic en est un bon exemple.[16] Leurs sous-agents s'exécutent en parallèle avec des fenêtres de contexte séparées, ce qui les aide à explorer différentes branches d'un problème sans se contaminer mutuellement avec chaque détail intermédiaire. LangChain décrit un modèle similaire sous « isoler » : parfois la meilleure façon d'améliorer la fiabilité d'un agent est de diviser les contextes plutôt que de les accumuler.[17]
Cela compte parce que le contexte partagé a un coût caché. Il crée une dépendance au chemin. Une seule mauvaise branche peut influencer l'étape suivante, et la suivante, et la suivante.
L'isolation est un moyen de limiter le rayon d'explosion.
En 2025, l'ingénierie du contexte était principalement un nom utile pour un problème que les gens ressentaient déjà. En 2026, elle commence à se solidifier en une architecture.
Le premier grand changement est que les constructeurs déplacent l'état durable en dehors de la fenêtre de contexte brute. L'édition de contexte et l'outil de mémoire d'Anthropic séparent explicitement ce qui reste actif dans la fenêtre de travail de ce qui devrait persister entre les sessions.[18] Le cookbook de janvier 2026 d'OpenAI sur la personnalisation fait le même mouvement sous une forme différente : des objets d'état structurés qui persistent entre les exécutions et sont délibérément réinjectés dans la mémoire de travail au début de chaque exécution.[19] L'API Responses d'OpenAI pousse ensuite cela un pas de plus avec la compaction native, de sorte que les boucles d'agents à long terme ne nécessitent pas que chaque équipe construise un sous-système de summarisation personnalisé à partir de zéro.[14]
Les Managed Agents d'Anthropic rendent le modèle sous-jacent inhabituellement explicite : la session n'est pas la fenêtre de contexte du modèle.[20] C'est une idée critique de 2026. La fenêtre est une mémoire de travail transitoire. Le journal de session est l'objet durable. Le harnais décide comment découper, compacter et réhydrater ce contexte durable dans le prochain appel de modèle.
Le deuxième changement est que la récupération devient plus juste à temps et plus native aux interfaces. Au lieu de précharger chaque token potentiellement pertinent, les équipes donnent aux agents des surfaces de récupération qu'ils savent déjà utiliser. ChromaFs de Mintlify en est un bon exemple : plutôt que de démarrer un sandbox complet pour la récupération de documentation, il présente les docs comme un système de fichiers virtuel navigable avec ls, cat et grep, réduisant la création de session p90 d'environ 46 secondes à environ 100 millisecondes.[21] AgentFS de Turso pousse la même intuition vers l'exécution générale d'agents : une abstraction de système de fichiers copy-on-write avec stockage portable en fichier unique et audit intégré.[22]
Le troisième changement est que les graphes de contexte deviennent une direction d'implémentation, pas seulement une métaphore. La thèse de Foundation Capital a rendu le terme visible, mais la revendication plus forte est architecturale : quand les agents se trouvent dans le chemin d'exécution, ils peuvent capturer des traces de décision comme artefacts durables, pas seulement émettre des sorties finales.[26][27] Des systèmes open-source comme Graphiti et des plateformes commerciales comme Zep opérationnalisent cela comme des graphes de contexte temporels avec des fenêtres de validité, des épisodes de provenance et une récupération hybride à travers la sémantique, les mots-clés et la structure du graphe.[23] TrustGraph adopte une approche connexe en traitant le contexte comme un artefact versionné : graphe, embeddings, preuves et politiques regroupés en « noyaux de contexte » portables qui peuvent être promus ou annulés comme des sorties de build.[24][25]
Le quatrième changement est que l'ingénierie du contexte est maintenant visible dans la pratique logicielle réelle, pas seulement dans les blogs de plateformes. L'article MSR 2026 sur l'ingénierie du contexte dans les logiciels open-source a étudié 466 dépôts et a constaté que les fichiers de contexte IA comme AGENTS.md se répandent, mais sans structure de contenu stable encore.[28] Cela compte parce que cela marque un passage de la théorie aux artefacts opérationnels. Le contexte n'est plus seulement quelque chose d'inféré à l'exécution. Il est rédigé, versionné, révisé et exploité dans le cadre du cycle de vie logiciel.
Si vous voulez le modèle mental 2026 en une image, il ressemble à ceci :
flowchart LR\n E[\"Journal de session / événements\"] --> A[\"Assembleur de contexte\"]\n F[\"Fichiers, docs et outils\"] --> A\n G[\"Graphe de contexte / mémoire\"] --> A\n P[\"Politiques et AGENTS.md\"] --> A\n\n A --> W[\"Fenêtre de contexte de travail\"]\n W --> X[\"Action de l'agent\"]\n\n X --> E\n X --> GC'est une architecture très différente de « prompt + recherche vectorielle ».
Une raison pour laquelle cette conversation devient confuse est que les gens utilisent ingénierie du contexte et graphe de contexte comme s'ils signifiaient la même chose. Ce n'est pas le cas.
L'ingénierie du contexte est la discipline plus large. C'est le travail de décider ce qui entre dans la prochaine fenêtre de contexte, ce qui reste dehors, ce qui est compressé et ce qui est récupéré à la demande.
Un graphe de contexte est un substrat de mémoire à long terme possible dans ce système plus large.
Cette distinction compte parce que tous les agents utiles n'ont pas besoin d'un graphe de contexte. Un assistant de documentation sur du contenu principalement statique peut avoir besoin d'une bonne récupération, d'une conception d'outils et d'une compaction, mais pas d'un graphe. Un agent de codage peut aller étonnamment loin avec des instructions de dépôt, un journal de session durable et une abstraction de système de fichiers.[20][21][22][28]
Les graphes de contexte deviennent convaincants quand le problème a quatre caractéristiques :
C'est pourquoi la meilleure définition d'un graphe de contexte, à mon avis, n'est pas « une base de données graphe pour l'IA ». C'est une représentation durable du précédent.
C'est aussi pourquoi les traces de décision comptent tant. Le cadre de Foundation Capital est utile ici : les règles disent à l'agent ce qui devrait se passer en général ; les traces de décision lui disent ce qui s'est passé dans un cas spécifique, sous de vraies contraintes, avec de vraies exceptions.[26] Une fois que ces traces sont liées à travers les entités et le temps, vous obtenez quelque chose de bien plus précieux que la mémoire générique. Vous obtenez un jugement consultable.
Si je construisais une pile d'ingénierie du contexte sérieuse aujourd'hui, je ne commencerais pas par le graphe. Je commencerais par les interfaces et les règles de promotion.
Chaque action, résultat d'outil, observation et artefact intermédiaire important devrait atterrir dans un journal de session ou un event store append-only. C'est votre objet de contexte récupérable.[14][20]
Ne confondez pas la fenêtre de contexte active avec la source de vérité.
La fenêtre est pour le raisonnement.
La session est pour la récupération, la relecture, le débogage et la réhydratation sélective.
L'assembleur devrait gérer explicitement :
C'est la couche qui décide ce que le modèle voit maintenant. Elle devrait être observable, testable et facile à modifier.[18][19][14]
Donnez d'abord au modèle des handles légers : chemins de fichiers, IDs d'objets, URLs, modèles de requêtes, IDs de tickets, IDs d'incidents. Puis laissez-le tirer les détails seulement quand nécessaire.[9][18][21]
C'est là que les systèmes de fichiers, les outils MCP, les APIs de recherche et les requêtes structurées deviennent plus précieux que d'énormes dumps top-K.
Tout ne devrait pas devenir mémoire.
Je promouvrais quatre classes d'artefacts :
Tout le reste devrait rester dans le journal de session jusqu'à ce qu'il prouve qu'il mérite d'être promu.
C'est la partie que beaucoup d'équipes inversent.
Le graphe ne devrait pas être votre transcription brute sous forme de graphe. Il devrait être la couche curée qui se situe au-dessus des sessions et en dessous de l'assemblage en temps réel :
Si vous sautez l'étape de promotion, le graphe devient une décharge.
Si vous faites bien la promotion, le graphe devient la mémoire de la façon dont l'organisation raisonne réellement.[23][26]
D'ici 2026, l'une des idées les plus prometteuses est de traiter le contexte comme un artefact versionné. Dans les projets logiciels, cela se manifeste sous la forme de AGENTS.md et d'autres fichiers de contexte spécifiques aux dépôts.[28] Dans les systèmes natifs aux graphes, cela se manifeste sous forme de noyaux de contexte : des bundles portables d'ontologie, de structure de graphe, d'embeddings, de provenance et de politique de récupération.[24][25]
Cela compte parce que les changements de contexte nécessitent la même discipline opérationnelle que les changements de code :
Une fois que le contexte devient un artefact, il devient gouvernable.
Vous avez besoin des deux :
Ce ne sont pas la même chose.
Je veux savoir :
Si vous ne pouvez pas répondre à ces questions, vous déboguez encore des prompts dans le noir.
Si vous essayez d'évaluer où se situe votre propre système, ce modèle de maturité est plus utile que des définitions abstraites.
Vous avez un prompt système, un message utilisateur et peut-être quelques exemples.
Cela peut fonctionner étonnamment bien pour des tâches étroites. Cela se casse rapidement quand la tâche nécessite des connaissances fraîches, de la persistance ou des outils.
Vous ajoutez des documents à l'exécution.
C'est là que beaucoup d'équipes s'arrêtent. C'est aussi là que beaucoup d'équipes commencent à voir les limites du chunking naïf, du classement et du gonflement du contexte.
Vous gérez maintenant l'historique, les résultats d'outils, la mémoire et le formatage intentionnellement.
C'est le premier niveau où « ingénierie du contexte » devient un terme utile, parce que le système n'est plus seulement prompt plus récupération. Il assemble plusieurs formes de contexte dynamiquement.
Le système change la façon dont il construit le contexte en fonction de la tâche.
Il peut :
À ce stade, la construction du contexte fait partie de la logique centrale de l'application.
Le système traite le contexte comme une surface d'ingénierie de premier ordre.
Il a :
C'est là que se dirigent les systèmes de production les plus solides.
Si je devais réduire toute la discipline à une liste de contrôle, elle ressemblerait à ceci :
Rien de tout cela n'est glamour. C'est exactement pourquoi cela compte.
L'ingénierie des prompts est devenue populaire parce qu'elle ressemblait à un raccourci.
L'ingénierie du contexte compte parce qu'elle décrit le vrai travail.
Le centre de gravité de l'IA se déplace.
La question frontière était autrefois : À quel point le modèle est-il intelligent ?
La question appliquée est de plus en plus : Que voit le modèle avant de devoir agir ?
C'est un problème d'ingénierie différent. Il s'agit moins de prompts uniques et plus de conception de systèmes. Moins de formulation et plus de flux d'information. Moins de qualité de sortie en une seule passe et plus de savoir si un agent peut rester fiable dans le temps.
C'est pourquoi l'ingénierie du contexte va continuer à croître comme discipline. Plus les modèles s'améliorent, plus les échecs restants ressemblent à des échecs de contexte. État manquant. Mauvais outil. Mauvaise récupération. Historique gonflé. Mauvais formatage. Preuves contradictoires. Mémoire faible. Boucles non bornées.
L'ironie est que cela rend les systèmes d'IA plus semblables aux logiciels classiques, pas moins. Nous revenons à construire des pipelines, des interfaces, des machines à états, des hiérarchies de mémoire, des caches et des couches d'observabilité. La nouveauté est que toutes ces pièces existent maintenant au service d'un moteur de raisonnement probabiliste.
Le nom est peut-être nouveau. La direction ne l'est pas.
Les systèmes d'IA fiables seront construits par des équipes qui traitent le contexte comme une surface produit de premier ordre.
Tous les autres continueront à dire que le modèle est capricieux.
Références :
[1] Simon Willison. (2025, 27 juin). Context engineering.
[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
[8] LangChain. (2025, 23 juin). The rise of \"context engineering\".
[9] Anthropic. How to implement tool use.
[10] Jason Liu. (2025, 27 août). Beyond Chunks: Why Context Engineering is the Future of RAG.
[12] Anthropic. Long context prompting tips.
[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
[16] Anthropic. (2025, 13 juin). How we built our multi-agent research system.
[17] LangChain. (2025, 2 juillet). Context Engineering.
[18] Anthropic. (2025, 29 septembre). Managing context on the Claude Developer Platform.
[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
[21] Mintlify. (2026, 24 mars). How we built a virtual filesystem for our Assistant.
[22] Turso. AgentFS.
[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
[24] TrustGraph. The context development platform.
[25] TrustGraph. Working with Context Cores.
[26] Gupta, J., and Garg, A. (2025, 22 décembre). AI's trillion-dollar opportunity: Context graphs.
[27] Garg, A. (2026, 16 janvier). Why context graphs are the missing layer for AI.
", "source_hash": "sha256:352e42d5b8ff71176c26e2e3f9853217033b811bae4f0beaef2cc91e2401caa9", "model": "claude-sonnet-4-6", "generated_at": "2026-04-23T20:55:31.367689+00:00" }