Un agent est un système d’action
La différence importante entre un chatbot et un agent n’est pas l’interface. C’est l’autorité. Un agent peut appeler des outils, récupérer des données, conserver un état et exécuter une série de décisions. L’identité, les permissions, la gestion des échecs et l’observabilité deviennent donc des éléments du produit — pas des détails d’infrastructure à ajouter plus tard.
Microsoft Foundry Agent Service propose plusieurs formes de runtime. La bonne question n’est pas de savoir laquelle paraît la plus avancée, mais laquelle fournit le contrôle nécessaire à la mission sans créer une exploitation inutilement lourde.
Trois formes de déploiement
Agents déclaratifs
Les agents déclaratifs sont définis par des instructions, un modèle et des outils, tandis que Foundry exploite le runtime. Ils conviennent aux assistants délimités et aux processus qui ne nécessitent pas d’orchestration personnalisée.
Le runtime géré réduit le travail lié aux conteneurs et à la mise à l’échelle. Il ne remplace pas des instructions versionnées, des tests représentatifs, une conception des permissions et une responsabilité de production.
Agents hébergés
Les agents hébergés empaquettent un code d’agent personnalisé derrière un point de terminaison géré par Foundry. Ils répondent aux besoins d’orchestration spécifique, de frameworks particuliers, de coordination multi-agent ou de protocoles d’interaction non standard.
Cette flexibilité apporte davantage de responsabilité sur le code et ses dépendances. L’organisation reste propriétaire de la logique, même lorsque Foundry exploite l’environnement de conteneur.
Runtimes applicatifs existants
Une équipe peut aussi conserver le code de l’agent dans une application existante et appeler l’API Responses de Foundry pour les modèles et les outils de plateforme. Ce choix est pertinent lorsque l’application dispose déjà d’un modèle mature de déploiement, d’identité et d’observabilité.
Ne migrez pas un runtime stable dans le seul but de rendre le schéma d’architecture plus uniforme.
Définir le cadre opérationnel
Une instruction telle que « sois prudent » n’est pas un contrôle. Le cadre de production doit exister hors du modèle :
- n’exposer que les outils nécessaires à la tâche ;
- valider leurs entrées et sorties par du code déterministe ;
- préserver l’identité de l’utilisateur ou de la charge dans les appels en aval ;
- demander confirmation pour les actions importantes ou irréversibles ;
- limiter la durée, le nombre d’appels, le coût et les enregistrements affectés ;
- rendre les effets de bord idempotents ou récupérables lorsque c’est possible ;
- arrêter et escalader lorsque la confiance, les permissions ou les dépendances sont insuffisantes.
Le système devrait avoir moins d’autorité que la personne qu’il assiste, et non partager un identifiant offrant un accès supérieur.
Concevoir les outils comme des contrats
Le nom et la description d’un outil influencent le comportement du modèle, mais le service récepteur reste la frontière de sécurité. Donnez à chaque outil un objectif étroit et un schéma typé. Rejetez les identifiants ambigus, les champs non autorisés et les transitions d’état impossibles.
Séparez lecture et écriture. Pour les changements sensibles, proposez un aperçu ou une exécution à blanc. Des erreurs structurées doivent permettre une reprise sûre plutôt que d’inciter l’agent à inventer un succès.
Pour un service client, « récupérer le résumé approuvé de la commande » et « demander l’annulation de la commande X » sont plus sûrs qu’un outil générique « exécuter une opération ERP ».
Tracer les décisions, pas un raisonnement caché
Une observabilité utile capture la requête, les versions du modèle et de l’agent, l’outil choisi, les arguments validés, le résultat, la latence, l’usage de jetons, les décisions de politique et le résultat final. Elle ne devrait pas dépendre de la collecte d’une chaîne de pensée privée.
Examinez les traces en échec ou proches de l’échec comme des preuves produit. Une réponse finale correcte après plusieurs tentatives d’outils non autorisées ne constitue pas une trace réussie.
Le contrôle humain doit être opérationnel
« Humain dans la boucle » est souvent écrit sans nommer l’humain, le déclencheur ou le temps de réponse. Définissez :
- l’action nécessitant une approbation ;
- la personne qui reçoit la demande ;
- les preuves qui lui sont présentées ;
- le délai d’attente ;
- le comportement en cas de refus ou d’expiration ;
- le moyen d’arrêter ou d’annuler le processus.
La voie d’escalade doit fonctionner pendant un incident, pas seulement pendant une démonstration.
Le test de production
Avant d’accorder plus d’autonomie, prouvez que l’agent accomplit la tâche délimitée, échoue de manière sûre, préserve l’identité, respecte les limites et laisse une trace vérifiable. Commencez par un rôle consultatif, ajoutez les outils sous confirmation et n’élargissez l’autorité que lorsque l’évaluation et l’exploitation le justifient.
La meilleure architecture d’agent n’est pas la plus autonome. C’est celle qui possède l’autorité minimale nécessaire au résultat.
Référence officielle
Microsoft décrit les agents déclaratifs et hébergés, l’accès direct à l’API Responses, les outils, l’identité et l’observabilité dans la présentation de Foundry Agent Service.