Une requête, toute une tâche : au cœur de Mangrove

Le 4 novembre, nous avons confié une petite mission à l’un de nos agents de test : rédiger la revue de presse IA du jour, en cinq points, chacun avec sa source.

Deux minutes et vingt-deux secondes plus tard, il avait une réponse. Il avait lancé huit recherches web et tenté une neuvième, qui a été refusée. Il avait essayé six pages, et trois de ces sites ont bloqué l’accès automatisé. Quand il s’est cru arrivé au bout, une vérification l’a renvoyé au travail. Et au bas de sa réponse, il a précisé quels étaient les deux points qui ne reposaient que sur des résultats de recherche, parce qu’il n’avait jamais pu lire les pages correspondantes.

L’exécution complète a consommé 1,96 Wh d’énergie.

Cette exécution est un bon moyen d’expliquer ce qu’est Mangrove, car presque tout ce qui compte s’y est passé là où tu ne pouvais pas le voir.

Transcription (traduite)

Un modèle de chat te donne une seule réponse. La plupart du travail ne tient pas en une réponse. Il faut chercher, lire, comparer, vérifier, et souvent tout recommencer. Mangrove est l’endpoint d’orchestration de GreenPT. Tu envoies une seule requête. Il détermine ce dont la tâche a besoin, utilise les bons outils, vérifie sa propre réponse et te remet le résultat. Il n’y a ni boucle d’agent à construire ni outils à brancher. Comme l’arbre, il fait son travail sous la surface.

Un modèle de chat te donne une seule réponse

Une complétion de chat, c’est une question et une réponse. La plupart du travail n’a pas cette forme. Il faut chercher, lire, comparer, vérifier, et assez souvent tout recommencer.

Tu peux construire cette boucle toi-même. Beaucoup d’équipes le font. Tu branches des outils, tu écris une boucle autour du modèle, tu ajoutes une nouvelle tentative ici et une limite là, puis tu découvres ce qui coûte cher : décider de ce qui se passe quand une page fait 1,3 million de caractères, quand le modèle dit qu’il a fini alors que ce n’est pas le cas, quand toutes les recherches échouent et que le modèle rédige de polies excuses que ton système enregistre comme un succès.

Mangrove est l’endpoint d’orchestration de GreenPT. Tu envoies une seule requête, et il mène toute la tâche à bien : il détermine ce dont elle a besoin, utilise les bons outils, vérifie sa propre réponse et te remet le résultat.

curl -X POST https://api.greenpt.ai/v1/agents/runs \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{ "question": "Summarise the EU grid carbon intensity news from this week" }'

Tu reçois un agentId immédiatement. Ensuite, tu interroges l’exécution à intervalles réguliers, ou tu reçois ses étapes en streaming, au fur et à mesure. Il n’y a ni boucle d’agent à construire ni outils à brancher.

Le nom est à prendre au pied de la lettre. Une mangrove fait son travail sous la surface : ce que tu vois, c’est un arbre, et ce qui tient tout debout, c’est un réseau de racines qui partent dans toutes les directions. C’est ainsi que nous concevons l’orchestration. Au-dessus de la surface, tu vois une tâche et un résultat.

Une précision avant de continuer, car elle compte pour tout ce qui suit. Mangrove n’est pas un modèle. C’est le système qui en fait tourner un. Le modèle qui décide a son propre nom.

Metis tranche. Mangrove fait le travail.

Transcription (traduite)

Avant qu’une exécution démarre, trois questions comptent. À quel point cette tâche est-elle difficile ? Quelle quantité de travail représente-t-elle ? Et combien de sources lui faut-il ? Un modèle qui devine dépense trop, ou trop peu. Mangrove interroge donc Metis, notre modèle de décision. Metis n’écrit rien. Il lit la tâche une seule fois et renvoie une probabilité pour chaque réponse possible. Les trois questions, en une seule passe. Environ soixante-cinq millisecondes de temps de modèle, et moins de cinq millièmes de wattheure. Metis tranche. Mangrove fait le travail.

Avant qu’une exécution démarre, trois questions comptent. À quel point cette tâche est-elle difficile ? Quelle quantité de travail représente-t-elle ? Combien de sources lui faut-il ?

Si ces réponses sont fausses, tu le paies dans tous les cas. Un agent sans notion d’échelle mobilise un grand modèle et un gros budget pour une recherche d’une ligne, ou laisse à un vrai travail de recherche trop peu de place pour aboutir.

Mangrove interroge donc Metis, notre modèle de décision. Metis n’écrit pas. Tu lui donnes un cas et une série de questions : il lit tout une seule fois et renvoie une probabilité pour chaque réponse possible. Mangrove envoie les trois questions en une seule requête.

Voici ce qui est revenu pour une tâche réelle, le 5 novembre : « Summarise this week’s news on EU grid carbon intensity in five bullets, with a source for each. »

Question	Réponse de Metis	Le reste
À quel point est-ce difficile ?	standard, 62 %	complex 27 %, simple 12 %
Quelle quantité de travail ?	medium, 72 %	long 15 %, short 13 %
Combien de sources ?	several, 71 %	many 14 %, few 9 %, none 6 %

Cette décision a pris 63 ms de temps de modèle et 0,0041 Wh, sans générer le moindre token. Ces chiffres viennent du rapport d’impact que l’API renvoie avec la réponse.

Pourquoi ne pas simplement demander à un modèle de chat de classer la tâche ? Nous avons essayé. En octobre, nous avons testé les deux pour le routage du chat, sur 65 tours de conversation étiquetés à la main. La précision globale était proche : 77 % pour Metis contre 80 % pour un modèle généraliste répondant en JSON. La différence se jouait sur les erreurs et sur l’attente. Le modèle généraliste mettait 2,3 secondes en médiane et sous-estimait l’effort nécessaire à un tour dans 20 % des cas. Metis répondait à trois questions en 230 ms environ et sous-estimait dans 2 % des cas. Un orchestrateur pose ce genre de question en permanence, et la sous-estimation est l’erreur qui coûte cher : la tâche manque de place et échoue. Les probabilités aident aussi, car ce sont des nombres sur lesquels ta logique peut agir, sans rien à analyser.

Voilà donc la place de Metis. Metis juge. Mangrove agit selon ce jugement. Un modèle de langage raisonne à l’intérieur de l’exécution ; Metis en fixe les conditions depuis l’extérieur.

Un travail à la bonne taille

Transcription (traduite)

Toutes les tâches ne méritent pas le même effort. Demande la capitale de la Finlande, et Metis répond simple, et short. Demande un tableau de toutes les sociétés de trois indices boursiers, et il répond complex, et long. Ces notes façonnent l’exécution. La difficulté choisit le modèle : un travail facile n’en réveille donc jamais un grand. La longueur fixe les limites d’appels, de tokens et de temps. La profondeur de recherche fixe jusqu’où l’exécution peut chercher. Une revue de presse a droit à huit recherches, pas dix-sept. Et si une note ne revient pas, l’exécution garde les limites avec lesquelles elle a démarré. Assez de travail, et pas plus.

Difficile et long, ce n’est pas la même chose. Trouver les sites web de 250 entreprises est simple pour chaque élément et long au total. Un interblocage subtil, c’est l’inverse. Mangrove garde donc ces axes séparés, et chacun contrôle quelque chose de différent.

La difficulté choisit le modèle. Pour un agent enregistré, une tâche notée simple va à un modèle plus petit et une tâche notée complex à un modèle plus puissant : un travail facile ne réveille donc jamais un grand modèle. Si tu fixes un modèle pour ton agent, ton choix l’emporte.

La longueur fixe les limites. Une tâche reçoit un budget d’appels au modèle, de tokens et de secondes adapté à sa taille.

La profondeur de recherche fixe jusqu’où l’exécution peut chercher. Celle-ci vient d’une mesure. Avant qu’elle existe, une revue de presse en cinq points demandait de 8 à 17 recherches web et jusqu’à 9 lectures de pages, toutes avec des requêtes différentes, car chaque recherche qui trouvait quelque chose en appelait une autre. Une exécution ne savait pas quand c’était assez.

Profondeur de recherche	Recherches web	Lectures de pages
None	1	1
Few	3	3
Several	8	6
Many	sans plafond	sans plafond

Voilà la neuvième recherche que notre revue de presse s’est vu refuser. L’exécution connaît sa limite dès le départ, et quand elle l’atteint, l’outil répond que le budget est épuisé et lui demande de rédiger ce qu’elle a. Et les notes de Metis pour des tâches très différentes sont vraiment très différentes : « What is the capital of Finland? » est revenu simple (98 %) et short (96 %). Un tableau de toutes les sociétés cotées de l’AEX, de l’AMX et de l’AScX est revenu complex (71 %) et long (93 %).

Si une note ne revient pas du tout, rien ne casse. Une exécution qui ne peut pas être notée garde les limites avec lesquelles elle a démarré. Un classifieur en échec ne dit rien de la tâche : il n’a donc pas le droit de restreindre quoi que ce soit.

Planifier, puis agir

Transcription (traduite)

Une exécution ne commence pas par improviser. Ce qui est certain vient d’abord. Un enregistrement est transcrit, et une image est regardée, avant même que le modèle voie ta question. Une tâche de plus d’une étape reçoit un plan écrit, d’au plus huit étapes, avant que le travail commence. Ce plan est vérifié par rapport aux outils que cette exécution peut utiliser. S’il ne peut pas s’appliquer, la tâche continue sans lui. Puis la boucle agentique prend le relais : jusqu’à vingt tours d’appels d’outils et de lecture des résultats, avec une liste de tâches que tu peux suivre. Des étapes fixes pour ce qui est certain. Du jugement pour ce qui ne l’est pas.

Une exécution ne commence pas par improviser.

Ce qui est certain vient d’abord. Si tu envoies un enregistrement, il est transcrit avant même que le modèle voie ta question. Si tu envoies une image, elle est regardée en premier. Le modèle n’a jamais à décider de faire l’un ou l’autre, et il n’a jamais à recopier un fichier de plusieurs mégaoctets dans les arguments d’un outil : ce serait lent et coûteux, et un seul caractère altéré le corromprait.

Une tâche notée comme comptant plus d’une étape peut ensuite recevoir un plan écrit d’au plus huit étapes, généré avant que le travail commence. Nous en avons fait un appel séparé à dessein. Un plan produit à mi-chemin n’est que le récit de ce qui se passe déjà ; un plan produit d’abord est une déclaration d’intention que tu peux vérifier. Il est validé par rapport aux outils que cette exécution peut utiliser, et toute étape dont l’entrée dépend d’un résultat antérieur est laissée au jugement du modèle. Si la planification échoue, ou si la tâche ne se découpe pas en étapes qui valent la peine d’être fixées à l’avance, le planificateur renonce et l’exécution se poursuit comme elle l’aurait fait sans plan.

Puis la boucle agentique prend le relais : jusqu’à vingt tours d’appels d’outils, de lecture des résultats et de décision sur la suite, avec une liste de tâches que tu peux suivre dans le flux.

Des étapes fixes pour ce qui est certain. Du jugement pour ce qui ne l’est pas.

Ce à quoi il a accès

Transcription (traduite)

Un agent ne vaut que par ce à quoi il a accès. Mangrove cherche sur le web et lit les pages qu’il trouve. Il analyse des documents, regarde des images et transcrit des réunions. Il écrit et exécute du Python dans un bac à sable isolé, pour des calculs, des graphiques et des fichiers Word, Excel et PowerPoint. Il enregistre des valeurs entre deux exécutions, pour que la suivante puisse comparer. Avec ton autorisation, il accède à ton propre travail : Outlook, OneDrive, SharePoint et tout serveur MCP que tu connectes. Il peut rédiger une réponse en brouillon dans Outlook. Il ne peut jamais en envoyer une.

Un agent ne vaut que par ce à quoi il a accès. D’emblée, Mangrove peut :

• Chercher sur le web et lire des pages, en s’en tenant aux passages utiles à ce qu’il cherche.
• Analyser des documents, comme des PDF et des fichiers Word, à partir d’un lien ou d’un fichier envoyé.
• Regarder directement des images, pour que graphiques et mises en page soient vus comme des images et non extraits sous forme de texte.
• Transcrire des réunions, puis travailler à partir de la transcription, avec les intervenants, les décisions et les actions à mener.
• Exécuter du Python dans un bac à sable isolé, pour des calculs, de l’analyse de données et des graphiques, et pour produire de vrais fichiers Word, Excel, PowerPoint et PDF.
• Enregistrer une valeur entre deux exécutions sous un nom, pour que l’exécution de la semaine prochaine puisse se comparer à celle de cette semaine.

Avec ton autorisation, il accède aussi à ton propre travail : recherche et lecture dans Outlook, tes fichiers dans OneDrive et SharePoint, et tout serveur MCP que tu connectes. Il peut enregistrer des fichiers dans OneDrive, et il peut rédiger une réponse en brouillon dans Outlook.

Il ne peut pas en envoyer une. Il n’existe aucun outil d’envoi, et l’endpoint derrière l’outil de rédaction ne peut pas envoyer non plus. Une réponse arrive dans ton dossier Brouillons et t’y attend. C’est une limite que nous avons posée à dessein, et nous préférons l’expliquer plutôt que la retirer.

Ce n’est pas à l’agent de décider qu’il a fini

Transcription (traduite)

La plupart des agents décident eux-mêmes quand ils ont fini. Mangrove ne laisse pas cela au modèle. Chaque plan se termine par une vérification qu’aucun plan ne peut retirer. Cela répond-il entièrement à la question ? Un outil que tu n’as pas utilisé comblerait-il un manque ? Reprendre le travail, ça compte. Se contenter de cocher la liste de tâches, non. Et quand une tâche ne peut pas être faite, l’exécution le dit. Elle se termine comme non effectuée, avec la raison, au lieu d’excuses marquées comme un succès. Si tous les outils qu’elle a appelés ont échoué, l’exécution se termine comme non effectuée, quelle que soit l’assurance de la réponse. Une fin honnête fait partie du travail.

Cette partie de Mangrove est née à force de regarder des agents échouer.

Dans une boucle d’agent simple, le modèle décide quand il a fini : il cesse d’appeler des outils, et la dernière chose qu’il a dite devient la réponse. Mangrove ne laisse pas cela au modèle. Chaque plan se termine par une vérification, et aucun plan ne peut la retirer, car le runtime l’ajoute une fois le plan écrit.

La vérification demande si la réponse couvre entièrement la question, et si un outil que le modèle n’a pas utilisé pourrait combler un manque. Le résultat n’est pas déclaré par le modèle lui-même. Si le modèle reprend le travail et appelle un outil, cela compte comme du travail. S’il se contente de cocher sa liste de tâches, cela ne compte pas : quand nous l’avons mesuré, c’est exactement ce que faisaient certains modèles, qui marquaient chaque élément comme terminé et s’arrêtaient.

Dans l’exécution de notre revue de presse, la vérification a renvoyé l’agent faire deux lectures de pages de plus. L’une a été bloquée. L’autre s’est heurtée au budget de pages. La réponse qu’il a ensuite rédigée le disait.

Reste le mode d’échec dont personne n’aime parler. Sans moyen de signaler un échec, la seule façon de terminer une exécution est une réponse. Une exécution qui n’a rien trouvé se terminerait donc en succeeded, sur des excuses, et on dirait à son propriétaire que tout a fonctionné. Nous l’avons mesuré sur un vrai agent, avec tous les outils disponibles : la plupart des exécutions dont toutes les recherches avaient échoué ont quand même rédigé des excuses en forme de revue de presse.

Mangrove offre au modèle une porte de sortie. Il peut terminer une exécution comme non effectuée, avec une raison rédigée pour la personne à qui elle s’adresse. Et il existe un filet de sécurité pour les modèles qui ne la prennent pas : si une exécution a appelé des outils et qu’ils ont tous échoué, elle se termine en task_not_done, quelle que soit l’assurance de la réponse.

Une fin honnête fait partie du travail.

Des limites qui ne dépendent pas de la bonne conduite

Transcription (traduite)

Les limites d’un agent ne devraient pas dépendre de sa bonne conduite. Mangrove les garde donc dans le runtime, pas dans le prompt. Un outil que cette exécution n’a pas le droit d’utiliser n’est jamais montré au modèle. Si le modèle l’appelle quand même, l’appel est refusé. Les appels, les tokens et le temps sont comptés sur toute l’exécution. Et les limites ne peuvent que se resserrer. Une requête peut demander moins que ce que la plateforme autorise, jamais plus. Quand le budget de tokens est épuisé, le travail n’est pas jeté. L’exécution rédige une dernière réponse et indique ce qu’elle n’a pas atteint. Tu as payé ce travail, tu gardes donc ce qu’il a trouvé.

Tu peux demander gentiment à un modèle de rester dans les limites. C’est une mauvaise façon de faire tourner quoi que ce soit sans surveillance : Mangrove garde donc ses limites dans le runtime.

Un outil qu’une exécution n’a pas le droit d’utiliser n’est jamais montré au modèle. Si le modèle l’appelle quand même, l’appel est refusé de la même façon que pour un outil inconnu. Les appels au modèle, les tokens et le temps sont comptés sur toute l’exécution, vérification finale comprise : rien ne peut donc tourner en boucle gratuitement. Par défaut, une exécution dispose de 100 appels au modèle, 1 000 000 de tokens et 900 secondes, et les limites propres à une tâche peuvent être plus basses : notre revue de presse a tourné avec 60 appels, 600 000 tokens et 600 secondes.

Les limites ne peuvent que se resserrer. Une requête peut demander moins que ce que la plateforme autorise, jamais plus.

Certains de ces détails, seuls de vrais incidents nous les ont appris. Une page aspirée de 1,3 million de caractères a transformé une conversation de 5 000 tokens en une requête de 347 000 tokens : chaque résultat d’outil est donc plafonné à 50 000 caractères, et le modèle est prévenu quand l’un d’eux a été coupé. Le budget de tokens n’est pas non plus un seuil fixe : il réserve la place d’une étape aussi grande que la plus grande que l’exécution a déjà payée, car le prompt grandit à chaque résultat.

Ce qui se passe à la limite est peut-être le plus utile pour quiconque construit des agents. Quand le budget de tokens est épuisé, l’exécution ne meurt pas. La jeter serait l’issue la plus coûteuse qui soit, puisque tu paierais chaque appel pour recevoir un message d’erreur. Au lieu de cela, elle cesse de travailler et fait un dernier appel sans aucun outil disponible, pour ne rien pouvoir lancer de nouveau, puis elle rédige ce qu’elle a et indique ce qu’elle n’a pas atteint.

Tu as payé ce travail, tu gardes donc ce qu’il a trouvé.

Elle agit pour toi, et seulement en tant que toi

Transcription (traduite)

Une exécution agit pour toi. Elle ne peut donc agir qu’en tant que toi. Avant de démarrer, une exécution prend l’identité de son propriétaire et vérifie que c’est la bonne. Si cette vérification échoue, l’exécution ne démarre pas. Les valeurs enregistrées sont liées à ce propriétaire. Les e-mails et les fichiers sont atteints par des références créées pour cette seule exécution. Les outils de tes serveurs connectés sont cloisonnés, et l’exécution a pour consigne de traiter ce qu’ils renvoient comme des données, pas comme des ordres. Python tourne dans son propre bac à sable isolé. Outlook peut enregistrer un brouillon, sans aucun moyen de l’envoyer. Et chaque connexion attend que tu l’actives toi-même. Elle peut faire beaucoup. Elle ne peut le faire qu’en tant que toi.

Une exécution qui peut lire tes e-mails a besoin d’une réponse claire à une question : à qui sont les e-mails qu’elle lit ?

Avant de démarrer, une exécution prend l’identité de son propriétaire et vérifie que l’identité reçue correspond au propriétaire inscrit sur l’exécution. Si elle ne correspond pas, l’exécution ne démarre pas. Il n’y a pas de compte de secours. Le stockage des valeurs enregistrées n’a aucun champ pour dire à qui sont les données : un appel d’outil ne peut donc pas viser celles de quelqu’un d’autre. Les e-mails et les fichiers sont atteints par des références créées pour cette seule exécution : le modèle manipule une référence, pas une boîte aux lettres.

Les serveurs que tu connectes via MCP sont tenus à distance. Leurs descriptions d’outils sont cloisonnées, et l’exécution a pour consigne de traiter ce qu’ils renvoient comme des données, pas comme des ordres. Le worker qui fait tourner ton agent ne voit jamais leurs adresses. Chaque connexion, et chaque droit d’écriture comme l’enregistrement de brouillons ou de fichiers, attend que tu l’actives toi-même.

Nous ne prétendons pas que cela rende une exécution impossible à tromper. Un agent lit des choses écrites par des inconnus, et ce risque ne disparaît pas parce que tu as rédigé un prompt soigné. Nous limitons donc aussi ce qu’une exécution trompée pourrait faire : elle ne peut pas envoyer tes e-mails, son code tourne de façon isolée, et elle ne peut utiliser que ce que tu as connecté.

Une exécution qui peut attendre une électricité plus propre

Transcription (traduite)

Certains travaux n’ont pas besoin de se faire tout de suite. Ajoute un champ, et une exécution peut démarrer jusqu’à vingt-quatre heures plus tard. Mangrove lit la prévision du réseau et trouve le démarrage le plus propre de cette fenêtre. Si attendre fait gagner moins de cinq pour cent, elle démarre tout de suite. Si aucune prévision ne peut être lue, elle démarre tout de suite, là aussi. Une vérification carbone ne retarde jamais une exécution et ne la fait jamais échouer. Dans tous les cas, la réponse t’indique ce qui a été décidé, et le gain obtenu. Le même travail, à une heure plus propre.

C’est la capacité qui en dit le plus sur ceux qui l’ont construite.

Certains travaux n’ont pas besoin de se faire tout de suite. Un rapport hebdomadaire peut bien attendre quelques heures. Ajoute un champ, et une exécution peut démarrer jusqu’à 24 heures plus tard :

{
  "question": "Summarise the EU grid carbon intensity news from this week",
  "greenShiftWindowHours": 8
}

Mangrove lit la prévision d’intensité carbone du réseau sur lequel tournent ses modèles, et retient l’exécution jusqu’au démarrage le plus propre de cette fenêtre. Il fait attention à ce que cela en vaille la peine. Si attendre fait gagner moins de 5 %, l’exécution démarre tout de suite, car en dessous de ce seuil, le retard te coûte plus qu’il ne fait gagner au réseau. Si aucune prévision ne peut être lue, elle démarre tout de suite, là aussi. Une vérification carbone ne retarde jamais une exécution et ne la fait jamais échouer.

La réponse t’indique ce qui a été décidé : held, run_now ou unavailable, le démarrage prévu, l’intensité carbone en gCO₂e/kWh avec et sans attente, et le gain. Sur un réseau déjà propre et stable, la plupart des exécutions démarreront simplement à l’heure. C’est la règle qui joue, et tu peux le lire dans la réponse.

Des agents que tu gardes

Transcription (traduite)

Une exécution, c’est une tâche. Un agent, c’est un travail que tu gardes. Décris le travail dans le chat. GreenPT demande les quelques éléments qu’il lui faut, puis prépare l’agent : ses instructions, sa planification et une tâche pour le tester. Garde-le, et il a sa propre page, avec chaque exécution et chaque résultat. En mode planifié, personne n’est là pour répondre. L’exécution ne reçoit donc aucun moyen de poser une question. Par l’API, c’est un appel pour créer, et une adresse pour exécuter. Un travail décrit une fois, refait encore et encore.

Une exécution, c’est une tâche. Un agent, c’est un travail que tu gardes.

Décris le travail dans le chat de GreenPT, et il te demande les quelques éléments qu’il lui faut : quand le travail doit tourner, comment le résultat doit te parvenir, et si le travail peut attendre une électricité plus propre. Puis il prépare l’agent, avec ses instructions, sa planification et une tâche pour le tester. Rien n’est enregistré tant que tu ne l’as pas accepté. Garde-le, et il a sa propre page, avec chaque exécution et chaque résultat.

Une exécution planifiée n’est pas comme une exécution que tu surveilles, car personne n’est là pour répondre. Une exécution planifiée ne reçoit donc aucun moyen de poser une question. Elle suit ses instructions avec ce qu’elle a, et elle signale ce qu’elle n’a pas pu faire.

Les développeurs obtiennent la même chose en deux appels : un pour créer un agent, et un pour l’exécuter à sa propre adresse.

POST /v1/agent-profiles
POST /v1/agent-profiles/weekly-report/runs

Chaque étape consignée

Transcription (traduite)

Tu ne devrais pas avoir à croire un agent sur parole. Chaque exécution diffuse en continu ce qu’elle fait : chaque étape, chaque appel d’outil et chaque résultat. Elle consigne aussi ce qu’elle a décidé à son propre sujet : comment la tâche a été notée, quel plan elle a suivi et quel budget elle a reçu. Quatorze règles valent pour chaque trace, quoi que choisisse le modèle, et des tests les font respecter. Ses appels au modèle rapportent leur énergie et leurs émissions : une exécution se résume donc à un chiffre, en wattheures. Chaque étape, consignée.

Tu ne devrais pas avoir à croire un agent sur parole.

Chaque exécution diffuse en continu ce qu’elle fait : chaque étape, chaque appel d’outil et chaque résultat. Elle consigne aussi ce qu’elle a décidé à son propre sujet, sous forme d’événements decision : comment la tâche a été notée et avec quelle certitude, quel plan elle a suivi, quel budget elle a reçu, pourquoi elle s’est arrêtée. Si un classifieur a dépassé son délai, la trace le dit, car « jamais classée » et « classée comme générale » sont deux faits différents.

Quatorze règles valent pour chaque trace, quoi que choisisse le modèle : un appel d’outil reçoit toujours une réponse, les étapes ne se chevauchent jamais, un plan vient toujours avant sa mise en œuvre, une exécution ne se termine jamais deux fois. Des tests obligent le runtime à les respecter : une régression apparaît donc comme une règle non respectée et ne peut pas se cacher dans la variation normale d’un modèle.

Et une exécution se résume à un chiffre. Les appels au modèle d’une exécution rapportent leur énergie et leurs émissions via le même rapport d’impact que chaque réponse de l’API GreenPT, et l’exécution garde le total. Notre revue de presse a consommé 1,96 Wh et 0,14 g CO₂e. Sur 21 exécutions terminées d’un benchmark mené sur notre environnement de test, la fourchette allait de 0,49 Wh à 13,61 Wh, avec une médiane de 4,7 Wh. Ces totaux couvrent les appels au modèle dans la boucle propre à l’exécution. La note de Metis et les outils qui ne sont pas des modèles, comme la recherche, n’y figurent pas.

Pourquoi nous pensons que c’est différent

La plupart des frameworks d’agents te donnent des pièces détachées. Mangrove, c’est une exécution complète, avec des partis pris :

• Il juge avant de dépenser. Un modèle de décision dimensionne chaque tâche en quelques millisecondes, sans écrire un mot.
• Il sait quand c’est assez. Les budgets viennent de la tâche, et ils sont appliqués en dehors du modèle.
• Il ne peut pas s’attribuer un succès en douce. Une exécution qui a échoué dit qu’elle a échoué, avec une raison.
• Il garde ce que tu as payé. Un budget épuisé se solde par une réponse qui nomme ses lacunes.
• Il sait ce qu’il a consommé. L’énergie et les émissions accompagnent l’exécution, en Wh et en grammes.
• Il peut attendre. Une exécution peut attendre une heure plus propre, et te dire ce que cela a fait gagner.

Ce que Mangrove ne fait pas

Une exécution, c’est un seul échange. Elle part de zéro, elle ne peut pas être reprise, et une suite est une nouvelle exécution : cite donc la partie de la dernière réponse sur laquelle tu veux construire.

Le coût d’une exécution n’est pas connu au démarrage, car Mangrove décide du nombre d’étapes dont une tâche a besoin. Deux exécutions de la même question peuvent coûter des montants différents.

Une tâche qui demande plus de vingt tours revient moins étoffée au lieu d’échouer. La découper en questions plus ciblées aide.

Où en est Mangrove

Mangrove est en bêta privée, sur les formules Pro, Pro Max, Teams et Enterprise, et les exécutions sont payées avec tes crédits API. Pendant la bêta, certaines capacités décrites dans cet article ne sont pas activées sur tous les comptes. L’exécution de la revue de presse, au début de cet article, vient de notre environnement de test, avec toutes ces capacités activées.

Si tu veux l’essayer, la documentation de Mangrove contient un guide de démarrage rapide et des exemples complets, et tu peux demander un accès sur notre Discord.

Dis-nous ce que tu lui confierais en premier.