Comment nous avons appris à faire confiance à un agent d'IA pour trier les incidents en production

À 2 h 33 (PDT) un dimanche, une alarme de disponibilité s'est déclenchée pour un modèle de pointe. Les réponses en production se bloquaient en plein flux, et la surveillance a ouvert un ticket automatiquement.

À 2 h 46 (PDT), 13 minutes et 35 secondes plus tard, un diagnostic défendable figurait sur le ticket : des flux se bloquant silencieusement en raison soit d'un bogue en production, soit d'une mise à l'échelle de la capacité, des clients touchés, toutes les hypothèses concurrentes écartées, et une prochaine action recommandée rédigée avec des preuves à l'appui.

L'ingénieur de garde a tapé une seule phrase : « ouvrir l'escalade » ou « corriger le bogue en production ». La véritable contribution consistait à lire le compte rendu final, à soupeser l'appréciation qu'il mettait en évidence, et à décider.

L'enquêteur était un agent d'IA fonctionnant sur Kiro CLI. Ce billet explique comment notre équipe, l'une des équipes de pointe qui repensent la façon dont le travail s'accomplit autour des agents, a appris à confier à un agent une file d'attente de tickets en production, et ce que nous ne le laissons toujours pas faire.

Notre équipe exploite le plan de données de Kiro, le chemin de service qui achemine chaque requête de clavardage agentif depuis l'IDE, le CLI, le web, iOS et Kiro Crew de Kiro vers un parc de modèles (Anthropic, OpenAI, GLM, Qwen, DeepSeek et MiniMax, hébergés sur Amazon Bedrock) répartis sur plusieurs régions, chacun avec ses propres alarmes de disponibilité, de latence, de limitation, de cache et de sonde synthétique.

Quand une alarme se déclenche, quelqu'un doit la trier : est-elle réelle, qu'est-ce qui a cassé, qui est touché? Une baisse de disponibilité peut être un événement de capacité, une attaque frauduleuse, un mauvais déploiement ou une alarme mal réglée, et chaque hypothèse réside dans un groupe de journaux, un compte et un langage de requête différents. Un bon tri, c'est savoir quelles cinq questions parmi cinq cents poser en premier, car chaque résultat détermine la requête suivante.

Le tri est une recherche d'hypothèses, et un agent muni d'outils est conçu exactement pour cela. Des années de runbooks, de wikis d'alarmes et de notes post-incident représentaient déjà un investissement dans le contexte de l'agent. Le travail est à forte composante de lecture : 96,9 % des appels d'outils de l'agent sont des lectures (sûres, réversibles, parallélisables); le reste peut être soumis à approbation. Et le tri se répète : un agent qui consigne ce qu'il a appris fait fructifier les connaissances du système. Un humain fatigué à 3 h du matin ne le peut pas.

Il n'y a pas de cadre d'orchestration, pas de modèle affiné, pas d'environnement d'exécution d'agent sur mesure. Le système, c'est Kiro CLI, le même CLI que nous livrons aux clients, pointé sur nos propres opérations et configuré avec trois types de fichiers simples que nos ingénieurs écrivent et révisent comme du code :

• Une configuration d'agent : le modèle, les outils et un fichier de Steering en markdown contenant des règles opérationnelles, chacune étant un jugement humain posé une seule fois puis appliqué par la suite.
• Model Context Protocol (MCP) serveurs : permettent aux agents de se connecter aux outils (comptes AWS en ReadOnly, journaux, tickets, pipelines, révision de code et Slack).
• Skills et connaissances : la partie intéressante, abordée ensuite.

Autour du harnais se trouve un répartiteur de longue durée qui surveille les files d'attente de tickets et lance une session Kiro CLI headless par ticket. Le modèle est un paramètre d'exécution, pas une décision d'architecture : l'enquêteur principal fonctionne sur le modèle le plus puissant disponible, le travail réparti est confié à un essaim de sous-agents sur des modèles rapides et peu coûteux, et les appréciations véritablement ambiguës sont soumises en parallèle à un conseil de modèles de trois fournisseurs, tout désaccord étant traité comme un signal qu'il faut recueillir plus de preuves.

À l'inverse, un Skill est un guide en markdown pour une seule situation. Le contexte de l'agent ne transporte que l'index de l'ensemble des 107 Skills; quand un ticket correspond, il lit le guide complet de ce Skill précis. Tout entasser dans la requête système échoue vers le dixième runbook, quand le contexte se remplit d'instructions pour les 99 alarmes qui ne se sont pas déclenchées. Voici un exemple d'extrait condensé, rédigé après un incident de limitation de débit :

Les connaissances sont structurées en couches selon leur coût : les faits toujours nécessaires restent chargés, les guides se chargent à la demande, et des centaines d'enquêtes passées compilées reposent dans une archive interrogeable. Cette organisation en couches permet la survie : les longues enquêtes meurent d'épuisement du contexte avant toute autre chose.

Revenons à cette alarme de 2 h 33. Chaque étape que franchit l'agent est journalisée, et chaque affirmation qu'il publie renvoie à la requête qui l'a produite.

La valeur la plus profonde, c'est le travail que personne ne fait à la main. Une semaine plus tôt, une alarme sur un autre nouveau modèle ressemblait à un événement de capacité touchant tout le modèle. En reliant chaque erreur de flux à son enregistrement de routage par ID de requête, l'agent a constaté que 96,5 % des erreurs provenaient de seulement 2 de nos cellules de service isolées; les autres n'avaient aucune erreur. L'hypothèse survivante, « des quotas inégaux d'une cellule à l'autre », a été vérifiée avec des identifiants ReadOnly et a révélé un bogue latent dans une dépendance en amont. Un ingénieur pourrait faire tout cela, mais pas un soir de fin de semaine, en plein incident, sur des dizaines de comptes.

Ce qui améliore ce système chaque semaine, c'est la boucle qui l'entoure : les ingénieurs guident l'agent et organisent ce qu'il apprend.

Quatre mécanismes le font tourner :

• Les corrections deviennent des leçons. Chaque correction est stockée une seule fois et injectée dans chaque session future (des centaines de corrections face à des milliers d'exécutions terminées, ce qui réduit les besoins en mémoire), et l'agent corrige la documentation qui l'a induit en erreur, puisque le bogue de requête provenait d'un bogue de documentation.
• Les enquêtes deviennent des connaissances. Les tickets fermés sont distillés dans l'archive que les sessions futures interrogent en premier.
• L'agent rédige des Skills; des humains les révisent. Après un incident inédit, l'agent rédige un nouveau guide ou un delta; le guide de limitation de débit a gagné son étape par cellule de cette façon, la nuit même. Les ingénieurs et une tâche nocturne organisent la bibliothèque comme une autre base de code.
• Un état partagé entre les agents. Un suivi d'escalade à écriture conditionnelle fait en sorte que dix agents parallèles observant le même incident ne déposent qu'un seul ticket en amont, et non dix.

En revanche, la boucle nous a aussi fait défaut. Le pipeline de capture des leçons acceptait autrefois n'importe quel texte en attente à la fin de la session, si bien que les sessions interrompues écrivaient des commentaires de ticket bruts dans le magasin de corrections tels quels, et les sessions futures les étudiaient à tort comme une sagesse opérationnelle. Le correctif a été la validation par schéma avant l'écriture, plus un élagage nocturne. À moins d'être trié et géré avec soin, un pipeline d'apprentissage accumule les déchets aussi efficacement que les connaissances.

Kiro comptabilise l'agent en crédits, la même unité que nos clients achètent : un mois représentatif a produit environ 250 enquêtes, menées sans surveillance à une médiane de 13,6 minutes. La dépense n'est pas limitée par la retenue, mais par la structure : délais d'expiration de session, détection de blocage, un plafond de concurrence et des modèles peu coûteux pour le travail réparti. Au total, la facture mensuelle équivaut à neuf de nos propres abonnements de premier niveau, et les heures récupérées servent à réviser les comptes rendus, à corriger l'agent et à régler les causes profondes.

Les agents héritent des bogues de votre documentation à la vitesse de la machine. Une seule ligne périmée dans un document de référence s'est propagée dans plusieurs tickets avant qu'un humain ne la repère. Notre correctif n'était pas lié à un meilleur modèle, mais à une nouvelle habitude : quand une session tourne mal, corrigez-la, demandez ce qui l'a induite en erreur, et corrigez ce document. Cinq minutes dépensées une fois valent mieux que cinq minutes perdues chaque semaine.

Les demi-réponses assurées coûtent plus cher que les mauvaises réponses. Une règle de Steering a aidé plus que toute mise à niveau de modèle : l'agent doit tester et écarter les hypothèses concurrentes avant d'énoncer une conclusion. Des vérifications automatiques de l'arithmétique, de l'état des alarmes et des doublons ont ensuite éliminé des catégories entières d'erreurs que les humains devaient auparavant attraper en révision. Les gens font confiance à un résultat qu'ils peuvent vérifier, pas à des affirmations sur l'exactitude.

La concision inspire confiance. Les premiers agents publiaient l'intégralité de leur travail étape par étape dans des fils visibles par les clients. Le contenu était exact, mais l'expérience était bruyante. Désormais, une courte publication va dans le fil visible et tous les détails vont dans le journal de travail. Les équipes partenaires jugent l'agent d'après son pire commentaire, pas sa meilleure enquête.

Il n'existe pas de réglage d'autonomie unique. En une semaine, nous avons corrigé l'agent à la fois vers plus d'autonomie et plus de retenue : « cesse de demander la permission pour rédiger une révision de code; la révision est l'approbation », et « ne résous jamais un ticket et ne change jamais la gravité; seuls les humains le font ». Chaque action a besoin de sa propre règle, et le fichier de Steering de l'agent est la liste de ces règles.

La sécurité vient de l'infrastructure, pas seulement des requêtes. Chaque session sans surveillance est en ReadOnly par défaut au moyen d'une liste d'autorisation de rôles, et une demande de privilèges Admin renvoie une erreur. Chaque identifiant est émis pour une seule session et limité à la tâche que l'agent a déclarée, de sorte qu'une session ne peut appeler que les API qu'elle a demandées.

Aujourd'hui, l'agent fait le tri. De plus en plus, il répare aussi — en rédigeant des révisions de code pour les correctifs et en ajustant des seuils, derrière une révision humaine obligatoire, sur le même harnais. Et parce que tout le système est fait de markdown, de serveurs MCP et d'un Kiro CLI standard, chaque amélioration que nous apportons pour nous-mêmes est pertinente pour le produit que nous livrons.

La rotation de garde existe toujours, mais le travail a changé : vous ne commencez plus les enquêtes à 2 h 33; vous révisez plutôt celles qui sont terminées à 2 h 46. Le téléavertisseur de l'ingénieur de garde devient une file d'attente de décisions pour un travail qu'un agent a déjà fait. Le billet de Swami Sivasubramanian sur les équipes de pointe présente « investir dans le contexte de l'agent » comme la première étape pour les équipes de développement; notre file d'attente de tickets est un exemple d'investissement dans l'agent pour les opérations.

C'est le jour un de la nouvelle vie d'un ingénieur de pointe, et ce n'est que le début.