Au-delà de l’historique : concevoir le contexte

Vous demandez à un agent IA de poursuivre un travail. Derrière cette simple demande s’accumule un ensemble de messages, de définitions d’outils, de résultats de recherche, de fichiers et de décisions. Lesquels le modèle doit-il voir ensuite ? Chez NanthAI, cette question guide notre travail depuis des mois.

Également publié sur [9][10].

Pi et sa société mère, Earendil, apportent aujourd’hui un nouvel effort d’ingénierie à ce problème avec la découverte MCP et Codemode. Leurs articles récents sont une contribution bienvenue à une direction dans laquelle nous avons engagé NanthAI.[1][2]

Ces deux premiers articles étaient des études de cas techniques détaillées. Ici, nous reprenons leurs idées centrales et nous appuyons sur les travaux récents de Pi pour explorer la couche suivante. Le point de départ est simple : un agent devrait pouvoir accéder à bien plus d’informations et de capacités qu’il n’a besoin d’en transporter dans chaque prompt.

Nos articles de mai ont posé les fondations. Cette suite examine l’approche de Pi à leurs côtés.

Cette suite relie ces idées : ce qui entre avant l’exécution des outils, ce qui parvient au modèle pendant l’exécution et ce qui reste utile ensuite.

La conversation grandit. Le bagage aussi.

Une application de chat simple envoie souvent toute la conversation à chaque nouveau message. Ajoutez des outils et leurs résultats rejoignent cet historique. Ajoutez des intégrations et un catalogue complet d’outils peut accompagner chaque requête. Les capacités comme l’historique font grossir le prompt.

Également publié sur [10].

L’approche de référence réinjecte l’historique accumulé. NanthAI prépare le contexte à partir de la conversation, des mémoires et des éléments probants récupérables.

Un historique de conversation a une fonction claire : permettre à une personne de suivre l’échange. Une requête au modèle en a une autre : donner au modèle les informations nécessaires pour agir maintenant. Ces vues se recoupent, mais elles n’ont pas à être identiques. L’utilisateur peut conserver une conversation lisible tandis que le runtime prépare un contexte de travail plus ciblé.

NanthAI sépare la conversation lisible des éléments probants et de l’état du runtime qui la sous-tendent. Les artefacts bruts préservent les résultats des outils. Des mémoires compactes portent les informations utiles avec des références aux sources. L’assemblage du contexte sélectionne les éléments appropriés pour la prochaine requête.

Également publié sur [10].

Des fenêtres de contexte plus grandes et la mise en cache des prompts sont utiles en complément de cette architecture. Une fenêtre plus grande apporte de la capacité. Le cache peut réduire le coût des préfixes répétés. L’assemblage du contexte détermine d’abord ce qui mérite cette capacité. C’est un choix de conception de l’information qui reste pertinent à mesure que les modèles progressent.

Donnez un point d’entrée à l’agent.

Également publié sur [9].

Une compétence est un paquet de connaissances sur une méthode de travail, que l’agent peut découvrir. Sa courte description aide le modèle à reconnaître quand l’utiliser. Ses consignes complètes expliquent comment réaliser le travail. Un outil est une opération exécutable : rechercher, lire, calculer, créer ou mettre à jour. Une compétence peut nécessiter plusieurs outils, et plusieurs compétences peuvent partager le même profil d’outils.

Dans NanthAI, charger une compétence apporte les consignes de travail et active les profils d’outils nécessaires. La compétence relie la tâche aux indications et aux capacités requises pour l’accomplir.

Imaginez une demande de rapport de recherche. Le catalogue donne à l’agent assez d’informations pour découvrir la bonne compétence. Son chargement apporte la méthode de recherche et les capacités nécessaires. Si le travail demande ensuite une autre capacité, une autre compétence peut élargir l’ensemble d’outils actifs. Le modèle démarre avec un moyen de trouver ce dont il a besoin.

NanthAI utilise les compétences pour activer les consignes et les profils d’outils. Pi ajoute la découverte d’outils MCP individuels à ses compétences.

Pi aborde la découverte MCP avec des descriptions compactes des serveurs, la recherche d’outils et leur inspection. L’agent découvre les déclarations individuelles et peut les utiliser via Codemode ou activer des outils pour des appels directs. Pi prend aussi en charge des compétences dont les consignes se chargent à la demande.[3][5]

La comparaison est donc plus intéressante que la simple question de savoir qui charge les outils à la demande. NanthAI relie explicitement les connaissances de méthode à des groupes d’outils. La découverte MCP de Pi permet à l’agent une sélection plus fine parmi les outils individuels. Les deux séparent le fait de savoir qu’une capacité existe du chargement de ses détails complets.

Également publié sur [9].

Une « mémoire d’outil » doit ramener à ses sources.

Également publié sur [10].

Un artefact d’outil est le relevé d’exécution : ce qui a été demandé et ce qui est revenu, y compris un fichier ou une erreur. Une mémoire d’outil est une représentation plus petite des éléments utiles de ce relevé. Elle porte un lien vers sa source. L’assemblage du contexte choisit les messages, mémoires, références et détails exacts qui doivent entrer dans la prochaine génération.

L’historique, les artefacts, les mémoires et le contexte assemblé remplissent des rôles différents. Les références aux sources les relient.

Supposons qu’un outil produise un CSV et que l’agent explique le résultat. Au tour suivant, le modèle peut n’avoir besoin que du constat et d’une référence au fichier. Plus tard, l’utilisateur demande les lignes exactes derrière un chiffre. Une mémoire compacte donne au système un chemin vers l’artefact d’origine. Le résumé est utile parce que les éléments probants restent récupérables.

Cette distinction aide aussi à gérer le temps. Les disponibilités d’un calendrier peuvent vite devenir obsolètes ; l’identité d’un fichier généré peut rester utile beaucoup plus longtemps. Les mémoires d’outils portent donc des informations de fraîcheur et de provenance. L’assembleur peut distinguer les éléments actuels d’une observation ancienne, au lieu de leur accorder la même autorité parce qu’ils apparaissent dans le chat.

Également publié sur [10].

Gardez les éléments probants. Choisissez ce qui circule.

Une fois les outils exécutés, le problème du contexte change de forme. Une recherche ou un appel API peut renvoyer des centaines d’enregistrements alors que la réponse n’a besoin que de quelques faits. C’est ici que le Codemode de Pi offre une comparaison particulièrement utile.

MCP fournit aux outils un moyen commun de se connecter aux agents. La manière dont un agent expose ces outils au modèle est un choix de conception distinct. L’article MCP d’Earendil et sa couverture par The New Stack concrétisent cette distinction : une intégration peut être disponible sans que tous ses schémas occupent le prompt dès le départ.[1][2]

L’agent écrit du JavaScript qui appelle des outils, joint ou filtre leurs réponses et émet une sortie choisie. Les valeurs intermédiaires peuvent rester dans le script : le modèle n’a donc pas à recevoir chaque réponse complète pour faire avancer le calcul.[4]

Pi peut réduire les réponses intermédiaires au sein d’une opération. NanthAI sélectionne et réutilise les éléments probants entre les requêtes.

Également publié sur [10].

La différence tient au point d’intervention. Codemode peut réduire les données intermédiaires avant leur première arrivée au modèle. Nos mémoires et notre assemblage façonnent ce qui est transmis aux requêtes suivantes. Les outils spécialisés de NanthAI traitent déjà les données en interne ; la boucle générale d’outils renvoie la charge utile produite par chacun.

Ce sont des techniques apparentées, appliquées à des étapes différentes du même flux d’information. L’apport de Pi nous offre un autre angle utile pour examiner ce flux.

C’est aussi pourquoi les seuls appels parallèles ne résument pas l’intérêt de Codemode. L’exécution parallèle peut obtenir plusieurs résultats à la fois. Un traitement programmatique peut ensuite les combiner et n’émettre que les éléments nécessaires à la réponse. Cela change ce que reçoit le modèle autant que l’organisation des appels.

Un rapport. Trois décisions de contexte.

Imaginez demander à un agent de comparer deux exports de ventes et d’expliquer quels comptes ont le plus changé. Le rapport final a besoin de noms de comptes, d’écarts significatifs et d’éléments à l’appui. Le traitement peut parcourir beaucoup plus de lignes que le rapport n’en contient.

Avant l’exécution, NanthAI peut charger la compétence d’analyse pertinente et activer ses outils. C’est le problème de sélection des capacités de notre premier article. Les consignes de calendrier ou de messagerie sans rapport n’ont pas à accompagner l’analyse.

Trois décisions de contexte illustrées par un rapport. Chaque colonne montre un mécanisme de l’approche nommée.

Pendant l’exécution, un script Codemode pourrait lire les deux jeux de données avec des outils, joindre les enregistrements par compte, calculer les changements et renvoyer les plus grands écarts. Cela illustre le mécanisme supplémentaire de Pi : exprimer plusieurs étapes de traitement des données en code et choisir la sortie reçue par le modèle.[4]

Ensuite, l’architecture de contexte de NanthAI peut préserver les artefacts et transmettre les mémoires d’outils utiles aux requêtes ultérieures. Quand l’utilisateur demande de réviser le rapport, le contexte sélectionné et les références aux sources aident à poursuivre le travail. Les éléments exacts peuvent être récupérés lorsque la tâche le nécessite.

Avec notre récente mise à jour du runtime local, cette répartition des responsabilités fait déjà partie du produit. NanthAI peut confier du travail à un runtime connecté sur votre Mac, dont Pi. NanthAI assemble le contexte pertinent de conversation, de branche, de mémoires et d’artefacts ; Pi combine ce contexte préparé avec ses propres consignes et outils de runtime, exécute la boucle de l’agent et appelle le fournisseur de LLM configuré.

NanthAI prépare le contexte ; Pi s’exécute sur le Mac connecté et appelle son fournisseur de LLM configuré. La réponse revient dans la même conversation.

Revenons au rapport de ventes : demandez la comparaison dans NanthAI, et le runtime Pi connecté peut réaliser l’analyse avec le contexte préparé par NanthAI. La réponse revient dans la même conversation. Quand vous posez une question complémentaire, NanthAI prépare le contexte pertinent pour le tour suivant, tandis que le runtime gère l’exécution. Notre investissement dans l’assemblage du contexte et les capacités des runtimes locaux se rejoignent dans un même flux de travail.

Le travail continue. Le contexte l’accompagne.

Également publié sur [10].

Cela compte lorsque l’on compare des modèles, reprend une tâche ou change d’environnement d’exécution. La préparation partagée de NanthAI réunit la branche pertinente de la conversation, les résumés, les messages récents, les mémoires et les éléments issus des artefacts. La même préparation canonique sert aux tours cloud et locaux.

NanthAI prépare un contexte partagé pour différentes voies d’exécution. Chaque voie conserve ses propres capacités d’outils.

Considérez deux branches d’une conversation de planification. L’une explore un budget prudent ; l’autre développe une proposition plus ambitieuse. Chacune peut générer une feuille de calcul différente. La requête suivante doit utiliser le fichier et les hypothèses associés à la branche que poursuit l’utilisateur. Le fichier le plus récent de toute la conversation n’est pas automatiquement le bon.

Pi maintient aussi la continuité avec des sessions, des branches et la compaction. L’article Pi Durable d’Earendil étend ce travail à l’exécution avec points de reprise et à la récupération.[6] Sa conception du contexte et de l’exécution mérite d’être comprise selon ses propres principes.

NanthAI apporte un contexte partagé à un produit qui traverse clients, modèles et voies d’exécution, y compris Pi lui-même. Un moteur d’exécution peut gérer sa session de travail tandis que NanthAI maintient le relevé partagé. C’est la valeur pratique de la séparation décrite en mai : le travail peut se poursuivre au-delà d’une seule session de modèle.

Également publié sur [10].

Construisez le contexte pour la prochaine étape utile.

Nos articles de mai ont établi deux principes liés : exposer les capacités progressivement et assembler l’historique utile de manière délibérée. Les travaux récents de Pi apportent un autre point de vue solide sur leur mise en œuvre, notamment pour la découverte des outils et le calcul sur leurs sorties.

Le problème commun est la quantité d’informations qu’un agent doit porter pour effectuer un travail utile. Les approches diffèrent par ce qu’elles sélectionnent, quand elles le sélectionnent et quelle partie du système prend la décision.

Comparaison des priorités : capacités progressives, résultats sélectionnés et continuité du travail.

Cloudflare et Anthropic ont aussi publié des travaux sur l’exécution de code pour piloter des outils.[7][8] Nous nous réjouissons de l’attention et des efforts d’ingénierie consacrés à ce problème. Comparer des conceptions qui fonctionnent et apprendre des choix de différentes équipes a une réelle valeur.

Pour NanthAI, cela prolonge un investissement soutenu dans les compétences, les mémoires d’outils et le contexte assemblé. Nous restons concentrés sur l’expérience rendue possible par ces fondations : choisir les modèles voulus, rendre les bonnes capacités accessibles et garder le travail utile disponible pour l’étape suivante.

Mettez un meilleur contexte au travail avec NanthAI

Dans NanthAI, ces choix d’architecture deviennent un espace de travail : choisissez vos modèles, façonnez leurs méthodes avec les compétences, travaillez avec des fichiers et continuez avec le contexte utile à portée de main.

Rédigez avec un modèle, obtenez un autre point de vue et décidez de la suite de la conversation. Explorez une branche sans perdre la direction initiale. Intégrez le travail Pi ou Codex pris en charge sur votre Mac aux conversations que vous utilisez sur votre téléphone et votre navigateur.

Nous investissons depuis des mois dans les fondations de cette expérience. Voir Pi, Earendil et d’autres équipes apporter leur poids et leurs idées au même problème est encourageant. Le contexte devient un sujet d’ingénierie de plus en plus riche en échanges, et nous sommes heureux d’y contribuer avec un produit opérationnel et la réflexion qui le sous-tend.

L’IA qu’il vous faut au prix qui vous convient

Découvrir NanthAI

Articles et sources

1. The New Stack: One MCP server used 18,000 tokens before doing anything
2. Earendil: You Said No MCP! (29 septembre 2026)
3. Pi documentation: MCP servers and tool exposure
4. Pi documentation: Codemode
5. Pi source: Skills and progressive disclosure
6. Earendil: Pi Durable (1er octobre 2026)
7. Cloudflare: Code Mode: the better way to use MCP
8. Anthropic: Code execution with MCP
9. NanthAI: Skills as Tool Gates (11 mai 2026)
10. NanthAI: The Transcript Trap (15 mai 2026)

Logo Pi issu du dossier de presse officiel de Pi. Comparaison technique fondée sur le code source et la documentation examinés en octobre 2026.

Également publié sur LinkedIn.