L’agent doit vivre dans le workflow
Le pattern de l’assistant DjiniousLab est parlant : le panneau agent vit dans l’application, lit le canvas et le notebook, stream la réponse et montre les appels d’outils comme des cartes structurées.
Dans une app client, le contexte est la fonctionnalité : objet sélectionné, rapport courant, permissions, historique, thème, données métier, procédures et état du workflow.
Concevoir les outils comme une API
Une intégration fiable commence par des outils petits, typés, observables et reliés aux permissions. Les outils de lecture inspectent, les outils de brouillon préparent, les outils d’écriture modifient seulement par des chemins approuvés.
L’utilisateur voit ce qui a été appelé, avec quels arguments, quel résultat est revenu et ce qui a changé. L’équipe peut alors déboguer l’agent comme un vrai flux produit.
L’approbation est de l’UX
Une demande d’approbation doit expliquer ce que l’agent veut faire, pourquoi, quels objets sont touchés, ce qui va changer et si l’action est réversible.
Lire l’état peut être automatique. Envoyer un message client, supprimer des données, modifier un prix ou commander un équipement doit être confirmé ou interdit selon la politique de l’organisation.
Mémoire, évaluation, opérations
La mémoire persistante n’est utile que si elle est visible et limitée : conventions projet, formats préférés, vocabulaire métier, préférences stables. Une mémoire cachée détruit la confiance.
Le travail de production vient ensuite : tests de régression, tâches golden, replay des tool calls, budgets de coût, latence, abus et revue d’incident.