Sous-agents

En mode agentique, le modèle peut déléguer une partie du travail à un agent autonome : un second modèle, avec son propre contexte, qui reçoit une consigne écrite pour lui, travaille avec des outils de lecture (bases de connaissance, requêtes analytiques, web, code), puis rend un compte rendu. Le modèle principal lit ce compte rendu comme il lirait le résultat d’une recherche, et conclut.

À quoi ça sert, et à quoi ça ne sert pas

Nous l’avons mesuré avant de l’écrire, sur les mêmes questions et les mêmes jalons que notre banc d’essai. Trois résultats décident de l’usage :

• Déléguer coûte, en soi. Un agent repart de zéro : environ 10 000 tokens d’amorçage, que son premier tour paie sans cache (ses tours suivants profitent du cache, comme la boucle principale). À modèle égal, découper une demande en agents coûte 1,5 à 2 fois plus qu’une seule boucle, pour la même justesse.
• Le gain vient du modèle délégué. Confier les recherches à un modèle nettement moins cher (par exemple mistral-medium qui délègue à mistral-small) rend la même justesse pour −85 % de coût. Un modèle trop petit pour la sous-tâche, à l’inverse, échoue et coûte plus cher (il boucle).
• La délégation protège des affirmations douteuses. Un agent ne voit pas la question d’origine : il rapporte les faits sans en hériter le biais. Sur une question qui affirme qu’une structure « règle ses factures sans incident », les agents relèvent les impayés que la boucle unique manquait.

Le modèle reçoit ces faits dans la description de l’outil, avec la liste des modèles au moins deux fois moins chers que lui. La règle qu’il applique : déléguer seulement pour confier le travail à un modèle moins cher, pour isoler une vérification, ou pour couvrir plusieurs bases indépendantes en parallèle. Une question simple, il la traite lui-même.

L’activer

Ajoutez agents aux outils de la requête. Il faut au moins une autre ressource (une base, un connecteur, le web ou le code) : un agent sans rien à lire ne servirait à rien.

{
  "model": "mistral-medium",
  "tools_enabled": ["kb:factures", "kb:comptes-rendus", "agents"],
  "messages": [
    { "role": "user", "content": "Fiche complète sur Bimbamjob : facturation 2024, suivi, relation commerciale. Conclus sur le risque." }
  ]
}

Dans l’Assistant, l’outil est disponible aux niveaux de réflexion Approfondi et Maximal, avec un budget de tours propre à chaque agent (cinq et dix). En API, une requête qui pose miraca_niveau suit la même règle : en dessous d’Approfondi, agents est ignoré ; sans niveau, tools_enabled:["agents"] reste honoré. Dans Make et Zapier, cochez « Sub-agents » parmi les outils.

Ce que fait un agent, et ce qu’il ne peut pas faire

Un agent reçoit au plus ce que le modèle principal a lui-même : des bases parmi celles de la requête (déclarées et lisibles par la clé), le web s’il l’a, le code s’il l’a. Jamais plus. Les bases restent confiables à un agent même quand le modèle principal n’a pas reçu les outils de recherche pour ce tour, par exemple sur un message de simple conversation. Une base hors de la requête, ou qui n’existe pas, est refusée avec un message qui le dit : ce n’est pas une panne. Et il n’a que des outils de lecture : il ne modifie pas une base, n’écrit pas de fichier, ne livre rien, ne mémorise rien. Dans un script, l’écriture d’un fichier, de l’espace de travail ou d’un système connecté lui est refusée de la même façon. C’est le modèle principal qui agit. Un agent sans base confiée ne reçoit aucun outil de base de connaissance.

Depuis son script, un agent ne cherche pas sur le web : il utilise l’outil web_search s’il l’a reçu (c’est ce qui permet de facturer ses recherches au même forfait que celles du modèle principal).

La règle vaut aussi pour le code d’un agent : son script ne lit que les bases qui lui ont été confiées, n’interroge aucun système connecté, et n’écrit ni fichier, ni espace de travail, ni donnée d’un connecteur. Un appel hors de ce périmètre est refusé, avec un message qui dit à l’agent de rendre ce qu’il a trouvé.

Si votre organisation restreint les modèles de l’assistant, un agent ne peut tourner que sur un modèle de cette liste, et l’outil ne propose que ceux-là. Une clé API utilisée directement, sans restriction de modèles, garde tout le catalogue.

Un agent tourne souvent sur un autre modèle, parfois chez un autre fournisseur, que le modèle principal. Les réglages propres à un modèle s’appliquent donc au modèle de l’agent : le niveau de réflexion de la discussion s’applique aussi aux agents, traduit pour leur modèle (le raisonnement visé s’il le propose, sinon celui qu’il propose juste en dessous) ; le plafond de sortie tient compte de ce que ce modèle raisonne ou non ; et l’historique d’un agent est allégé avant d’approcher la limite de contexte de SON modèle.

Il ne peut pas non plus déléguer à son tour : la profondeur est de un.

Attendre un agent, et ce qui se passe quand il échoue

Plusieurs agents lancés dans le même tour travaillent en parallèle (au plus quatre). Pendant qu’ils tournent, la discussion montre chaque agent avec sa consigne et son modèle, et une ligne « Un agent travaille, en attente de sa réponse pour continuer ». Le modèle principal reprend quand tous sont revenus.

Chaque agent dispose d’un budget : au plus cinq tours d’outils (dix sur demande), ou, avec un niveau de réflexion, les tours de ce niveau (cinq en Approfondi, dix en Maximal), et le temps qu’il reste à la requête, moins une réserve pour que le modèle principal puisse conclure. Un agent qui atteint son budget est interrompu : il rend ce qu’il a établi, marqué comme partiel, et la liste des outils qu’il a exécutés. Un compte rendu coupé au plafond de tokens de sortie est marqué de la même façon, avec ce motif. Un agent qui rencontre une erreur le dit. Le dernier tour d’un agent est annoncé comme tel (les outils lui sont retirés) ; s’il ne rend alors aucun texte, il est relancé une seule fois, et un agent qui reste vide est signalé en erreur avec le compte rendu partiel de ce qu’il a fait. Dans tous ces cas, le modèle principal est prévenu et ne doit pas combler ce qui manque ; il peut relancer un agent avec une consigne plus précise.

Arrêter une réponse arrête aussi les agents en cours : chacun s’arrête avant son prochain tour (au plus un tour d’agent de retard), sans lancer d’outil de plus. Ce qu’il avait déjà établi est rendu, marqué « arrêté à la demande ». Un outil déjà lancé (un script, la lecture d’une page) va à son terme et reste facturé. Sur une tâche programmée, le coût des agents compte dans le budget pendant qu’ils travaillent : un plafond franchi pendant une délégation arrête la tâche de la même façon.

Ce que vous voyez

Dans le déroulé d’une réponse, chaque agent est une ligne « Délégation à un agent (mistral-small) : « consigne » (revenu en 2 tours) ». Dépliée, elle montre son modèle, ses tours, sa durée, les ressources qu’il a reçues, ses actions (chaque recherche avec sa requête et son nombre de résultats, chaque page avec son adresse) et le début de son compte rendu (2 000 caractères ; le modèle principal, lui, le reçoit en entier). Ce qu’un agent a lu compte comme lu : une base consultée ou une page ouverte par un agent n’est pas redemandée au modèle principal, et les documents qu’il a lus figurent dans les sources de la réponse.

Dans la réponse de l’API, ces éléments sont dans astrolabe_steps : une étape run_agent par agent, avec agent.model, agent.status (ok, interrupted, stopped, error), agent.rounds, agent.seconds, agent.cost_eur et agent.steps (même forme que les étapes du modèle principal).

Facturation et carbone

Les tokens des agents sont compris dans le coût de la requête, une seule fois, comme les tours de la boucle. Le coût de chaque agent est visible dans son étape. Les recherches web d’un agent sont facturées au même forfait que celles du modèle principal.

Le carbone ne suit pas toujours l’argent : un modèle moins cher peut émettre plus par token (c’est le cas de ministral-8b face à gemma). Le carbone de la requête tient compte du modèle réellement employé par chaque agent : astrolabe_usage porte le montant facturé (cost_eur) et, quand des agents ont tourné, la ventilation des tokens par modèle (by_model, une ligne par modèle avec prompt_tokens, completion_tokens et cached_prompt_tokens). Le détail par tour (astrolabe_rounds) ne couvre que les tours du modèle principal ; ceux d’un agent sont résumés dans son étape.