Vous avez fixé les limites de taux. Désormais, votre agent échoue silencieusement.

La semaine dernière, j’ai écrit que votre agent n’échouait pas parce qu’il hallucinait – il échouait à cause des limites de taux. La boîte à outils d'ingénierie de capacité présentée dans cet article (plafonds de concurrence, interruption avec instabilité, modèles de secours, mise en cache) est réelle et fonctionne. Déployez-le et votre agent cesse de mourir.

Ensuite, un commentateur (ANP2) a souligné le point sous-vendu par le message, et il est resté coincé dans ma tête depuis : chacun de ces correctifs ouvre discrètement un trou d'exactitude tout en fermant celui de disponibilité. Cet article, c'est moi qui paie ce fil de commentaires, car la seconde moitié de l'histoire s'avère plus importante que la première.

TL;DR — Un 429 est une panne bruyante : vous le voyez, vous l'alertez, vous le réparez. Les tentatives, les replis et les caches maintiennent l'agent en vie, mais ils le laissent agir sur des résultats qu'il n'a pas récemment obtenus : un accès au cache obsolète, la réponse d'un modèle différent, un effet secondaire de réexécution. Vous avez troqué les échecs bruyants contre des échecs silencieux. La solution consiste à traiter la disponibilité (« puis-je servir cela ? ») et l’exactitude (« puis-je toujours faire confiance au résultat ? ») comme deux portes distinctes – et à propager la confiance à travers la chaîne de l’agent, et pas seulement par appel.

L'échange que vous ne saviez pas avoir fait

Voici la symétrie inconfortable. L’intérêt de mon dernier message était que le mode dominant d’échec de la production n’est pas le modèle erroné, mais la plomberie qui dit non. La boîte à outils de capacité répare la plomberie. Mais regardez ce que fait réellement chaque correctif :

• Une nouvelle tentative relance un appel. Si cet appel a eu un effet secondaire (création d'un ticket, envoi d'un message, validation d'une modification), la nouvelle tentative exécute à nouveau l'effet secondaire. L’agent n’a pas échoué ; il a réussi deux fois, ce qui est en soi une erreur.
• Un modèle de repli répond lorsque le principal est à débit limité. Mais c’est un modèle différent : une formation différente, un calibrage différent, des modes de défaillance différents. La tâche se poursuit sur une réponse que la primaire n'a jamais produite.
• Un accès au cache sert une réponse générée pour une entrée antérieure. Si le monde bougeait – la base de code changeait, les données étaient mises à jour – la réponse mis...
  [Courte citation de 8% de l'article original]