Un agent n'est utile qu'à la mesure des systèmes qu'il atteint. C'est aussi là qu'apparaît la valeur pour l'entreprise : travailler avec les données d'ERP, de CRM et d'entrepôt.
01. Pas directement à la base
Ne branchez pas un agent directement sur la base de l'ERP. Placez entre les deux une couche de service qui définit les opérations possibles. Cette couche applique droits et règles de gestion.
02. Définir des outils étroits
Plutôt qu'un outil "exécuter du SQL", définissez des outils étroits et intentionnels comme "récupérer les commandes ouvertes du client". Un outil étroit est plus sûr et plus facile à bien employer pour le modèle.
03. Commencer par la lecture
Dans la première version, ne donnez que des outils de lecture : état de commande, consultation de stock, solde client. La valeur apparaît vite et le risque reste proche de zéro.
04. L'étape d'écriture
Lorsque l'écriture s'ouvre, chaque opération doit passer une validation et être idempotente : exécuter deux fois la même requête ne doit pas créer deux enregistrements. Cette protection joue lors des coupures réseau.
05. Fraîcheur des données
L'actualité des données vues par l'agent doit être claire. Un agent alimenté par une base de restitution copiée la nuit répond mal aux questions de stock.
06. Environnement de test
Ne développez pas un agent sur l'ERP de production. Un environnement de test aux données réalistes ramène à zéro le coût des appels erronés, inévitables les premières semaines.