Imagine ta responsable support un jeudi après-midi, trois heures après le début d'un service où le nouvel assistant IA lui a demandé de confirmer quarante et un appels d'outils. Les six premiers, elle les a lus ligne par ligne, en vérifiant les arguments, en comparant les identifiants avec le ticket. Vers le trentième, elle appuie sur le bouton vert comme tu appuies sur Entrée devant une invite de composer update : par réflexe, les yeux déjà sur la suite. Rien de négligent là-dedans. Les humains font ça avec n'importe quelle invite qui revient assez souvent. Et c'est exactement comme ça que je m'attends à voir beaucoup d'équipes utiliser la toute nouvelle fonctionnalité d'approbation de Laravel AI SDK 1.0.

Petit rappel pour ceux qui ont raté la sortie du 23 septembre. Un outil qui implémente le contrat Approvable et intègre le trait InteractsWithApprovals ne s'exécute plus simplement dès que le modèle le choisit. L'agent s'arrête et te remet les appels en attente, avec les arguments choisis par le modèle. Tu réponds à chacun : tu le laisses passer, tu le refuses avec une raison que le modèle verra, ou tu modifies les arguments avant l'exécution. Ça fonctionne avec prompt, stream, queue et les méthodes de broadcast, donc un agent en file d'attente peut rester suspendu jusqu'à ce que quelqu'un s'en occupe. C'est du bon travail d'ingénierie, et je suis content que ce soit livré avec le framework.

Ma position : Approvable doit être la dernière ligne de ta conception, jamais la première. Si un outil est assez dangereux pour que tu veuilles qu'un humain examine chaque appel, demande-toi d'abord si tu peux le rendre moins dangereux. C'est toujours mieux que de demander à une personne fatiguée de servir de mécanisme de sécurité quarante fois par service. Un outil appelé `DeleteFile` qui accepte n'importe quel chemin, c'est une bombe à retardement. Un outil qui peut seulement déplacer des fichiers d'un dossier de tenant précis vers une corbeille purgée au bout de trente jours n'a généralement besoin d'aucune confirmation, parce que le pire qu'il puisse faire est agaçant et réversible.

La même version te donne un levier plus discret, que je trouve plus intéressant pour ça. Le middleware s'exécute désormais à chaque étape de génération au lieu d'une fois par prompt, et il reçoit un PendingStep que tu peux modifier. Tu peux passer à un autre modèle, retirer des outils de la liste ou réduire le budget de tokens pendant que l'agent tourne. Pour moi, c'est le retrait de capacités élevé au rang de concept à part entière. L'agent a lu la facture dont il avait besoin ? Retire-lui les outils d'écriture pour toutes les étapes suivantes. Le modèle ne peut pas appeler un outil qu'il n'a pas, et personne n'a besoin de cliquer sur quoi que ce soit pour que cette garantie tienne. Les développeurs Go adorent se vanter de la petitesse de leurs interfaces. Voilà notre chance de garder, nous aussi, la boîte à outils d'un agent petite, une étape à la fois.

Maintenant, le contre-argument honnête, parce qu'il est solide. Certaines actions ne deviennent pas sûres parce qu'on les restreint. Un remboursement reste un remboursement. Un e-mail envoyé à un client ne se rattrape pas, même avec un modèle de message soigneusement cadré. Là, un humain doit vraiment regarder, et une pause bien conçue vaut mieux que toutes les approbations bricolées à coups de flag en base de données que j'ai croisées dans des applis Laravel au fil des années. Pouvoir corriger un argument erroné, au lieu de jeter toute l'exécution, donne aussi à la personne qui relit une vraie raison de lire ce qu'elle a sous les yeux. J'accepte tout ça. Mon propos porte sur le volume. L'approbation ne garde son sens que si elle reste assez rare pour qu'on prenne chacune au sérieux.

Il existe aussi une catégorie de risques qu'aucun bouton d'approbation ne peut couvrir. Gabriele Pieretti, qui développe un miroir virtuel pour les salons de coiffure, a écrit sur cette version du point de vue d'une appli qui envoie des photos de clients à Gemini sur Vertex AI dans une région de l'UE. Ce produit ne lance l'appel génératif qu'une fois qu'un consentement explicite existe côté serveur. Quoi que tu penses des détails, la leçon pour nous est simple : certaines règles ont leur place dans ta couche HTTP et ton état de session, bien avant que la moindre boucle d'agent démarre. Si la vérification vit dans un prompt, elle a déjà perdu.

Voici donc, en gros, l'ordre que je suis dans mes propres projets. Rendre l'outil aussi étroit et aussi réversible que le métier le permet. Utiliser le middleware par étape pour retirer tout ce dont l'agent n'a plus besoin. Appliquer les règles strictes en bon vieux PHP avant même d'appeler le modèle. Puis utiliser Approvable pour ce qui reste, et compter combien de fois ça se déclenche. Si une personne voit passer plus d'une poignée d'approbations par jour, je considère ça comme un bug de conception, pas comme une preuve de rigueur.

J'aimerais savoir où tu places cette limite. Si tu fais déjà tourner des agents avec des étapes d'approbation en production, combien de confirmations par personne et par jour peux-tu tenir avant qu'elles deviennent de simples coups de tampon, et qu'as-tu changé quand tu l'as vu arriver ?