Nommer le résultat avant la technologie
Une équipe veut transformer les demandes reçues en réponses utiles. Avant de choisir un agent, elle devrait définir cette utilité : une réponse complète, une source identifiable, les informations manquantes signalées et une prochaine étape claire. Il s’agit d’un exemple hypothétique, pas du résultat d’un projet. Si la tâche ne peut être décrite et évaluée, le mot agent ne la rendra pas plus claire. Il peut simplement masquer l’incompréhension derrière une interface convaincante.
Quand le parcours est connu
Anthropic distingue les flux prédéfinis des agents qui choisissent dynamiquement leurs étapes et leurs outils. Dans notre exemple, classer la demande, consulter une source désignée et rédiger une proposition peuvent former un flux facile à suivre. Une personne peut vérifier la proposition avant son envoi. La question pratique est de savoir si une situation importante échappe à cette succession, et non si le flux paraît assez sophistiqué.
Quand il faut découvrir l’étape suivante
Supposons que les demandes soient très variées et que les informations nécessaires ne deviennent évidentes qu’après une première vérification. Un agent pourrait choisir la source à consulter ensuite ou la question à poser à l’utilisateur. La valeur proposée réside dans l’adaptation du parcours. Pour l’évaluer, l’équipe devrait observer quand les choix dynamiques donnent une meilleure réponse que le parcours fixe, et quand ils ajoutent seulement des détours inutiles.
Intégrer les limites au produit
Microsoft recommande le niveau de complexité qui satisfait les besoins, en tenant compte du coût et du temps. Dans une expérimentation, cela devient concret : combien de vérifications sont acceptables, que peut consulter le système et quand doit-il demander de l’aide ? Préparer une réponse et avoir le droit de l’envoyer sont deux choses à distinguer. Consigner le motif d’arrêt et les informations manquantes rend le comportement compréhensible pour l’utilisateur, autant que pour l’équipe technique.
Comparer les variantes sur la même tâche
Une évaluation utile pourrait soumettre les mêmes exemples à un appel de modèle simple, à un flux et à un agent. Critères proposés : réponse correcte et complète, informations inventées, interventions humaines, coût et délai jusqu’au résultat. Inclure des demandes ambiguës ou impossibles à traiter avec les données disponibles. Sans cette comparaison, des étapes supplémentaires peuvent sembler être un progrès simplement parce qu’elles sont visibles. L’architecture mérite d’être élargie lorsqu’une amélioration observée justifie l’effort d’exploitation et de maintenance. Répéter la comparaison après des changements montre aussi si une nouvelle version conserve l’avantage initialement observé par l’équipe.