Budget d’un agent IA : arrêter avant de manquer de ressources

L’agent recherche un dossier, reformule sa question et recommence. Aucun appel ne paraît coûteux isolément ; le parcours accumule pourtant lectures, générations et reprises. Le client attend toujours sa réponse, pendant que deux travailleurs peuvent poursuivre la même mission. La limite indiquée dans le prompt ne sait ni compter ces dépenses ni réserver le temps nécessaire pour annoncer proprement que la mission doit s’arrêter.

En pratique, le budget doit décider si le prochain appel peut partir, avant son dispatch. Il associe compteur d’appels, montant réservé, échéance et état de progression, avec une marge pour la clôture. L’industrialisation et la gouvernance de l’IA rendent cet arrêt explicite : une réponse interrompue doit rester identifiable, et une action d’état inconnu ne doit pas être relancée simplement parce que le budget permet encore une tentative.

Onze scénarios manuscrits dans un registre SQLite local permettent de distinguer dépense confirmée, réserve ouverte et prochain appel admissible. Les unités et durées sont inventées ; aucun modèle, tarif fournisseur ou effet externe n’intervient. Une écriture inconnue reste bloquée même si de l’argent semble disponible. L’accompagnement IA sur mesure de Dawap peut partir de cette frontière pour définir, sur une mission bornée, les consommations à compter et les informations nécessaires à son arrêt.

Pour qui borner une mission plutôt qu’une réponse

Reconnaître le parcours qui peut s’allonger seul

Une assistance qui effectue une recherche unique possède déjà un périmètre d’exécution relativement simple. Une mission d’agent peut enchaîner recherche, interprétation, consultation d’une seconde source et nouvelle proposition. La longueur dépend alors de décisions prises pendant le parcours. Le budget doit couvrir cette chaîne, y compris les tentatives infructueuses, au lieu d’être attaché seulement à la dernière réponse visible dans l’écran.

Le responsable produit doit préciser ce que le client attend à la fin : une information étayée, un brouillon vérifiable ou une action confirmée. La DSI définit les ressources consommables ; le métier détermine le résultat utile. Une limite technique seule peut arrêter la machine sans terminer le service. Il faut aussi nommer la personne ou la file qui recevra une mission interrompue et les éléments déjà acquis.

Écarter les missions dont le droit reste incertain

Un budget suffisant ne rend aucune opération autorisée. Les contrôles d’identité, de ressource et d’arguments doivent rester applicables à chaque action. La réservation ne fournit pas un nouveau droit ; elle confirme seulement que les ressources nécessaires peuvent être engagées selon le contrat retenu. Une proposition interdite doit être refusée même si sa génération a consommé la moitié du plafond disponible.

Le laboratoire traite la limite d’une seule mission fictive et ne connecte aucun SI. L’architecture de production doit préciser l’ordre des contrôles, éviter les appels payants inutiles et reprendre sans perdre le contexte d’autorisation. Une mission qui cherche continuellement une identité plus puissante n’est pas un problème à résoudre par une augmentation de budget. Elle doit rejoindre un refus exploitable et une revue de son périmètre.

Séparer étapes, appels et consommation

Choisir l’unité de chaque compteur

Une étape d’orchestration peut effectuer zéro, un ou plusieurs appels réseau. Un appel logique peut lui-même provoquer des retries dans le SDK. Une limite de cinq étapes ne garantit donc pas cinq requêtes, ni cinq consommations facturables. Le contrat doit indiquer où chaque tentative est comptée, quelles couches peuvent recommencer et comment leurs traces remontent à l’identifiant stable de la mission.

La documentation Graph API de LangGraph décrit des supersteps : des nœuds parallèles peuvent appartenir à la même étape. Elle expose une limite de récursion et des mécanismes pour anticiper sa proximité. Ce compteur ne représente pas, à lui seul, un budget monétaire ou un nombre d’appels fournisseur. Notre registre est indépendant de LangGraph et aucun graphe de ce framework n’est exécuté dans la recette.

Documenter les plafonds sans leur donner une valeur universelle

Le banc accepte au maximum quatre appels et cinq étapes. Chaque admission compte un appel et une étape ; B31-04 initialise directement cinq étapes pour éprouver cette autre limite. Une production devra compter également ses étapes sans appel et les requêtes cachées sous ses bibliothèques. Ces chiffres illustrent une politique, pas une recommandation valable pour tous les modèles, interfaces ou processus.

Les dix unités et cent millisecondes restent une marge d’admission ; le laboratoire ne simule pas leur consommation pendant la clôture. Dans le service réel, cette dernière possède son propre chemin et ses coûts. Si elle exige un appel au modèle, il faut aussi lui réserver une capacité d’appel. Présenter une réponse partielle avec des faits déjà établis peut permettre une clôture plus prévisible qu’une dernière génération improvisée.

Réserver avant de laisser partir l’appel

Comparer engagé, réservé et prochain besoin

Le registre distingue spent, consommation rapprochée, et held, consommation réservée pour une tentative non soldée. Le prochain appel possède une réservation déclarée. Il est admis seulement si spent + held + nouvelle réservation + marge de clôture ne dépasse pas le plafond. Ce contrôle évite d’autoriser plusieurs appels en utilisant le même reliquat encore visible sur une facture ou un compteur asynchrone.

spent + held + next_reserve + 10 <= 100
now_ms + duration_bound_ms + 100 <= 1000
calls < 4
steps < 5
accounting_paused == false

La sortie de ce contrôle est une admission rattachée à une tentative, ou un motif de refus avant dispatch. Le modèle ne peut pas diminuer la réservation pour rendre sa proposition acceptable. L’estimation et les bornes viennent du service d’exécution, avec des règles sur entrées, sorties et outils autorisés. Si aucun majorant crédible n’existe, le plafond devient une politique de limitation avec exposition résiduelle, à déclarer comme telle.

Rapprocher sans effacer le coût des essais

Exemple concret : B31-01 réserve trente unités pour sa première tentative puis constate vingt unités. Le rapprochement retire trente de held et ajoute vingt à spent. Le deuxième appel réserve vingt et en constate quinze. La mission termine donc avec spent=35, held=0 et deux appels. Le coût des recherches reste présent même si une seule action utile est retenue à la fin.

Une consommation supérieure au majorant révèle une borne incorrecte. B31-10 réserve trente puis constate trente-cinq : le registre conserve ce montant et met accounting_paused à vrai. La tentative suivante est refusée. Le contrôle n’annule pas une consommation déjà produite et ne prétend pas avoir empêché ce dépassement de réservation. Il oblige à corriger le contrat et à rapprocher les dépenses avant de continuer.

Garder une marge pour terminer le parcours

Tester la durée restante avant chaque dispatch

Le parcours dispose d’une échéance globale ; un timeout par appel ne remplace pas ce délai. Une chaîne de quatre appels individuellement bornés peut dépasser l’attente acceptable. Le contrôleur compare l’heure courante, la borne déclarée du prochain appel et la marge de clôture. L’égalité est admise dans le banc : à 800 ms, un appel borné à 100 ms laisse encore les 100 ms conservées.

B31-06 arrive à 850 ms et propose 150 ms de travail. Le total avec clôture atteindrait 1 100 ms : deadline_margin refuse l’appel sans consommer de nouvelle unité. B31-11 arrive à 800 ms avec une borne de 100 ms et reçoit admitted. Ce test vérifie une frontière arithmétique sur une horloge simulée. Il ne mesure pas la latence d’un fournisseur ou la durée effective d’une annulation.

Propager le délai dans les dépendances

L’échéance doit être connue des couches qui peuvent attendre : file de travail, connexion réseau, exécution SQL et modèle. Un timeout seulement placé dans l’écran peut masquer un calcul encore actif sur le serveur. Il faut définir ce qui expire, qui cesse d’admettre des travaux et comment la mission retrouve les réponses arrivées après l’abandon de l’attente utilisateur.

La référence Amazon sur timeouts et retries rappelle qu’un échec ou un timeout ne prouve pas l’absence d’effet distant. Elle traite aussi les risques de surcharge dus aux reprises. Notre banc ne simule ni socket ni annulation : son échéance bloque uniquement une nouvelle admission. Il faut éprouver séparément le comportement réel des clients réseau et des opérations distantes.

Arrêter une boucle qui ne progresse plus

Définir une progression observable dans la mission

La réponse « je vais essayer autrement » ne constitue pas une progression métier. Une mission peut chercher une pièce manquante, vérifier une condition ou préparer un brouillon. Elle progresse lorsque l’état pertinent change : nouvelle pièce identifiée, condition établie ou proposition admissible. Les empreintes d’opération doivent inclure les éléments qui rendent une répétition réellement différente, sans conserver inutilement des données sensibles dans le journal.

Dans B31-02, deux tentatives portent la même empreinte same-state. La première coûte vingt unités après rapprochement ; la seconde reçoit no_progress avant admission. Le banc utilise une clé exacte choisie à la main, sans juger le sens d’une réponse. Une production doit traiter les changements de source et les recherches volontairement répétées. Une empreinte trop générale bloquerait un appel légitime après correction des données.

Conserver la cause qui rend la poursuite inutile

La non-progression peut venir d’un document absent, d’un résultat identique ou d’un outil interdit. Ces motifs demandent des reprises différentes. L’arrêt doit conserver le dernier état utile et la condition nécessaire pour continuer, par exemple l’arrivée d’une pièce ou le rétablissement d’une interface. Repartir automatiquement avec un nouveau prompt peut modifier la formulation sans faire disparaître la cause du blocage.

Paradoxalement, augmenter la limite de boucle peut réduire la qualité opérationnelle si cela transforme un blocage clair en longue attente. Le responsable métier préfère parfois un refus rapide accompagné du document manquant à une réponse tardive sans preuve. La mesure doit distinguer arrêt anticipé pertinent et abandon trop strict. Le plafond reste un garde-fou ; le contrat de progression explique pourquoi la prochaine dépense aurait une chance utile.

Compter la reprise et conserver les inconnues

Garder la réservation lorsque la consommation n’est pas établie

Deuxième cas concret : B31-07 réserve trente unités, mais la tentative devient unknown. Le registre ne sait pas combien a été consommé ; held reste trente. La reprise d’une lecture réserve trente unités supplémentaires, puis constate vingt. L’état final contient spent=20 et held=30. Le premier montant n’est ni remboursé ni supprimé parce que l’interface n’a pas livré de réponse.

La réservation inconnue est une exposition maximale selon notre hypothèse, pas une facture confirmée. Elle doit être rapprochée quand une information fiable arrive, avec procédure pour les inconnues durables. La reprise compte un nouvel appel, même si son identifiant métier reste le même. Les retries internes d’un SDK doivent respecter une enveloppe compatible ou remonter au même compteur ; sinon la limite apparente masque des dépenses supplémentaires.

Ne pas déduire le droit de relancer d’un reliquat disponible

B31-08 possède assez d’unités pour une seconde tentative, mais la première écriture a un effet inconnu. effect_unknown refuse la reprise. Le rapprochement de l’effet distant est une condition indépendante du budget : il faut identifier si l’opération a réussi, échoué ou reste indéterminée. Une clé d’idempotence peut aider si l’interface la prend réellement en charge avec les garanties nécessaires ; elle ne doit pas être supposée.

Le laboratoire ne réalise aucune écriture distante et son indicateur d’ambiguïté est fixé manuellement. Il ne prouve pas la sécurité des retries d’un ERP. Le service réel doit classifier les opérations, vérifier les capacités de l’interface et borner tentatives et délais d’attente. L’utilisateur ne doit pas provoquer une nouvelle mission sans lien avec la précédente en cliquant plusieurs fois après un message trop vague.

Partager le registre entre travailleurs

Faire de la réservation une transition atomique

Deux travailleurs qui lisent chacun un reliquat de cent unités peuvent autoriser deux dépenses de cinquante, puis découvrir trop tard que la marge de clôture a disparu. Le registre doit décider et réserver dans une même transition. Une lecture suivie d’une écriture sans contrôle concurrent ne protège pas le plafond. La politique doit aussi résister à une reprise après crash sans recréer une réserve déjà présente.

Le banc utilise BEGIN IMMEDIATE pour la décision et l’écriture SQLite. B31-09 représente deux travailleurs par deux admissions successives dans le même registre : worker-a réserve cinquante, worker-b reçoit budget_margin, car 50+50+10 dépasse cent. Ce résultat vérifie le partage du reliquat après la première admission. Il ne constitue pas un test de course concurrente, de charge distribuée ou de durabilité après panne.

Conserver un identifiant stable lors d’une reprise

Mission, tentative et résultat utile possèdent des identifiants distincts. Une nouvelle tentative consomme le budget de la même mission ; une rediffusion du message de dispatch ne doit pas réserver une seconde fois pour la même tentative. Le laboratoire possède une clé primaire d’identifiant, mais ne fournit pas le protocole complet de rediffusion. En production, cette situation doit devenir un résultat reconnu et récupérable, pas une exception laissée sans traitement.

Un budget par mission peut coexister avec des limites par client, file ou période. Il faut alors préciser qui réserve chaque niveau et comment les réserves sont libérées en cas de refus intermédiaire. Cette orchestration ne doit pas laisser un travail partir entre deux décisions incompatibles. Une protection locale utile ne démontre pas un plafond global : la recette doit couvrir le registre réellement partagé par les travailleurs du service.

Onze scénarios et leurs compteurs observés

Lire les refus avec l’état qui les produit

Chaque scénario démarre dans un registre indépendant. Les refus suivent l’ordre du contrôleur : comptabilité suspendue, effet ambigu, délai, étapes, appels, consommation et progression. Une décision rapporte le premier motif rencontré ; elle n’affirme pas que les limites suivantes seraient satisfaites. Les durées et consommations sont manuscrites, puis les calculs sont exécutés dans SQLite. Les actions utiles sont des étiquettes de recette, sans sortie de modèle évaluée.

Les cas limites doivent être testés de nouveau avec les interfaces effectives : appel encore actif après timeout, SDK qui recommence, consommation arrivée tardivement et réponse après annulation utilisateur. Le banc ne les exécute pas. Son intérêt est de rendre les décisions attendues assez précises pour détecter une différence de comportement lors de cette recette technique, sans confondre une simulation arithmétique et une garantie fournisseur.

Éprouver la reprise sans remettre le compteur à zéro

La recette de production doit interrompre un travail après réservation, après émission et après réponse, puis vérifier ce que la reprise retrouve. Le journal doit conserver montant engagé, réserves ouvertes et état de chaque tentative. Un redémarrage de travailleur ne crée pas une nouvelle mission. Sinon le plafond devient renouvelable à chaque incident, précisément lorsque les reprises ont le plus de chances de se multiplier.

Conservez aussi les cas qui doivent être admis, comme B31-11 à l’égalité exacte. Une correction qui refuse tout peut protéger un compteur et dégrader entièrement le service. Les critères d’acceptation doivent donc porter sur refus et continuité légitime. Les bornes sont révisées avec des observations datées ; leur modification n’efface pas les traces des exécutions qui ont révélé un contrat trop optimiste.

Rapporter le coût à une action réellement utile

Choisir un dénominateur que le métier reconnaît

Un appel terminé n’est pas nécessairement une action utile. B31-03 termine quatre appels et consomme quarante unités sans résultat utile étiqueté. Diviser quarante par quatre donne un coût par appel, pas un coût de résolution. Pour comparer des parcours, il faut définir ce qui vaut une unité utile : brouillon accepté, information vérifiée ou dossier correctement clôturé selon une grille indépendante de la génération.

B31-01 consomme trente-cinq unités pour une action utile fictive ; son ratio vaut trente-cinq. B31-07 a une action utile et vingt unités rapprochées, avec trente encore réservées. Afficher seulement vingt masquerait l’exposition restante. Le tableau de bord doit conserver coût connu et inconnu, avec rapprochement ultérieur. Pour zéro action utile, le coût par action est indéfini, et la dépense du parcours reste visible.

Comparer les arrêts selon leurs conséquences

Un arrêt de budget peut préserver la capacité du service, mais déplacer du travail dans une file humaine. Il faut mesurer âge des missions, reprise nécessaire, temps de vérification et fréquence des abandons, en plus des appels économisés. Une limite moins généreuse peut coûter davantage au métier si elle interrompt systématiquement la dernière vérification. Les décisions doivent être discutées à service rendu comparable et sur une population identifiée.

Le calcul du coût d’un dossier correctement traité couvre cette comparaison économique. Ici, les unités servent uniquement au contrat runtime. Aucun gain de productivité, tarif, coût complet ou taux de succès réel n’est déduit des onze scénarios. Leur distribution choisie à la main n’est pas représentative de la fréquence des incidents en production.

Erreurs fréquentes qui contournent le plafond

Placer la limite dans une couche que l’appel contourne

Demander au modèle de ne pas dépasser quatre appels ne remplace pas un compteur au dispatch. De même, compter seulement les requêtes visibles dans l’orchestrateur ignore les retries autonomes de ses clients. Il faut identifier la frontière qui voit toutes les consommations de la mission et imposer des contrats compatibles en dessous. Une voie d’appel directe sans cette vérification peut rendre la limite facultative.

Autre piège : reporter le contrôle après la réponse, lorsque les dépenses sont déjà engagées. La trace reste utile pour le rapprochement, mais ne constitue plus une admission préalable. Séparez l’instrumentation qui observe et le contrat qui décide. Si le fournisseur ne permet pas un majorant fiable, exposez cette limite et réduisez l’enveloppe par d’autres contraintes vérifiées sur taille, durée, outils et nombre de tentatives.

Confondre interruption et disparition de l’effet

Fermer l’écran, annuler une requête ou perdre une connexion ne garantit pas qu’un travail distant s’est arrêté. Libérer immédiatement toute réserve fait disparaître une exposition encore possible. Relancer une écriture rendue inconnue peut alors cumuler consommation et effet métier. Le contrat de reprise doit distinguer ces deux inconnues, même lorsque la même erreur réseau les a produites au même instant.

L’augmentation systématique du plafond constitue une autre erreur fréquente. Elle peut rendre un incident moins visible tout en conservant boucle, répétition et absence de source. Chaque changement doit préciser le blocage visé, les résultats attendus et les nouveaux risques. L’évaluation compare aussi les missions qui n’avaient pas besoin de cette marge, afin de vérifier qu’elles ne consomment pas davantage sans améliorer leur résultat.

Plan d’action pour un arrêt exploitable

Commencez par une mission limitée dont le résultat peut être reconnu indépendamment du modèle. Le contrat doit nommer entrée, sortie utile, responsable de reprise et interfaces effectivement appelées. Dessinez les chemins de retry, y compris ceux des bibliothèques, puis choisissez le registre qui voit toutes leurs réservations. Le budget d’exécution devient alors une responsabilité du service, avec une preuve de décision à chaque dispatch.

1. Définir la mission et sa clôture. Choisissez ce qui doit être livré et ce qui sera affiché si le parcours s’arrête. Identifiez le propriétaire des missions incomplètes, la file de reprise et les faits à conserver. Ne donnez pas au modèle la responsabilité de décider seul que la limite peut être ignorée pour « terminer correctement ».
2. Fixer des bornes vérifiables. Déclarez appels, étapes, consommation, taille des entrées et sorties, délai global et marge de clôture. Rattachez les majorants aux interfaces disponibles et aux observations de recette. Toute borne incertaine doit être nommée avec son exposition résiduelle, puis corrigée à partir des consommations réellement rapprochées.
3. Admettre et réserver dans le même registre. Utilisez un identifiant stable de mission et un identifiant distinct par tentative. Empêchez deux travailleurs d’engager le même reliquat. Traitez rediffusion, crash et récupération d’une tentative déjà admise ; vérifiez que les consommations inconnues continuent de peser dans la décision suivante.
4. Éprouver les arrêts et leurs reprises. Rejouez limites exactes, dépassement, absence de progression, lecture inconnue et écriture ambiguë. Ajoutez les vrais comportements réseau, SDK et files. Contrôlez la sortie utilisateur, les effets distants et la conservation des réserves, sans remettre les compteurs à zéro lorsque la mission change de travailleur.
5. Suivre le service obtenu. Publiez coût connu, exposition ouverte, arrêts par cause et actions utiles selon une grille métier. Examinez les dossiers repris manuellement et leur attente. Révisez les limites seulement avec une hypothèse et une recette de régression, pour éviter qu’une hausse de budget masque une dégradation de qualité ou de maîtrise.

Le premier seuil acceptable n’est pas nécessairement celui qui réussit tous les cas favorables. Il doit rendre les cas défavorables compréhensibles, limiter leur effet et laisser une reprise possible. L’équipe doit savoir quelle instrumentation manque encore avant l’ouverture, notamment consommation tardive et activité après timeout. Un plafond de laboratoire devient une protection opérationnelle lorsque ces chemins sont testés avec le runtime et les dépendances effectifs.

Conservez enfin une décision datée sur les limites retenues et les exceptions admises. Une exception doit rester une autorisation explicite du service, liée à une mission et à un responsable. Elle ne doit pas devenir un chemin de secours que l’agent apprend à utiliser pour chaque blocage. La supervision doit permettre de distinguer panne, budget insuffisant, source manquante et contrat de mission devenu inadapté.

Guides pour lancement, évaluation et reprise

Rattacher la limite au dossier d’ouverture

Le dossier de lancement d’une assistance IA en production réunit périmètre, responsabilités, observabilité et conditions d’arrêt. Le contrat de budget constitue une pièce de ce dossier. Il doit pouvoir être confronté aux alertes et aux procédures d’exploitation, pour que le support reconnaisse une limite volontaire et sache comment reprendre la mission.

Les évaluations de régression entre versions permettent de discuter un changement de prompt, d’index ou de runtime. Ajoutez aux sorties métier les appels, réserves et motifs d’arrêt. Une version qui répond mieux sur quelques cas peut perdre la maîtrise des parcours longs ; la comparaison doit conserver les scénarios critiques au lieu de se limiter à une moyenne de coût.

Reprendre un état sans réutiliser des faits périmés

La distinction entre mémoire d’agent, état métier et sources courantes complète le registre de consommation. Retrouver les compteurs ne signifie pas que les faits du dossier sont toujours valides. Une reprise doit conserver l’exposition passée tout en revalidant les informations et les droits nécessaires à l’action suivante.

Le registre de budget ne remplace ni contrôle de source ni validation métier. Reliez ces traces par identifiants de mission et de tentative, avec accès adapté et rétention définie. Une investigation doit pouvoir expliquer pourquoi la mission s’est arrêtée sans recopier tous les prompts ou documents dans les métriques. La cohérence entre ces responsabilités rend la reprise plus fiable qu’un simple historique de messages.

Conclusion : gouverner la prochaine tentative

La limite utile intervient avant que le prochain travail parte. Elle tient compte des consommations rapprochées, des réserves encore ouvertes, du délai restant et de la progression attendue. Le contrôle ne promet pas qu’un timeout annule une facture ou un effet ; il conserve ces inconnues jusqu’à leur rapprochement et refuse une reprise qui ne possède pas les conditions nécessaires.

Les onze scénarios distinguent appel, étape et action utile. Ils montrent une clôture à trente-cinq unités, une lecture avec trente unités encore réservées et une écriture dont la reprise est interdite malgré un reliquat suffisant. Ce sont des résultats de contrôleur local sur propositions fictives. Les garanties réseau, de concurrence et de coût fournisseur doivent être éprouvées séparément avant ouverture.

L’industrialisation d’une assistance IA avec des limites vérifiables doit rendre une mission arrêtée exploitable : état, cause et propriétaire de reprise accessibles. Il faut conserver les dépenses passées, rendre l’exposition visible et reconnaître les cas où une tentative supplémentaire ne ferait que prolonger l’attente ou accroître un effet indéterminé.

Pour borner une mission qui accumule recherches et tentatives, notre expertise d’agence IA sur mesure permet de préciser les réservations avant appel, leur rapprochement et la marge de clôture. La recette doit ensuite éprouver les coûts et délais des fournisseurs retenus, ainsi que les travailleurs concurrents. Une réserve non résolue conserve un propriétaire de reprise ; elle ne disparaît pas pour autoriser artificiellement la tentative suivante.