Clínica Aurora
Un agent qui prend, déplace et annule des rendez-vous dans un système de clinique séparé, et refuse quand une règle métier l’interdit. Le système de la clinique dans lequel il écrit est publié à côté, pour que vous puissiez vérifier l’autre côté vous-même.
Qui a ce problème
Le secrétariat d’une clinique passe la journée à déplacer des rendez-vous. Un agent n’y est utile que s’il écrit dans le système de la clinique, et c’est aussi là qu’il peut faire des dégâts : modifier le mauvais rendez-vous, enfreindre une règle, ou annoncer une modification que le système n’a jamais enregistrée. Cette démo montre ce que fait l’agent dans chacun de ces cas.
Mon rôle
Runtime de l’agent, API de clinique séparée, moteur de règles déterministe et interface opérateur.
Comment l’essayer
- Ouvrez la démo. Il n’y a pas d’inscription, et vous recevez votre propre copie de l’agenda.
- Demandez en langage courant de prendre, déplacer ou annuler un rendez-vous, et confirmez quand l’agent vous le demande.
- Essayez ensuite d’annuler un rendez-vous qui commence dans moins de 24 heures, ou coupez le système de la clinique avec le bouton, et regardez ce que fait l’agent.
Conditions d’utilisation
- Session anonyme avec son propre agenda isolé. Personne ne voit ni ne modifie celui d’un autre.
- Au plus 3 écritures par conversation, imposées par le moteur de politiques.
- Un plafond quotidien de tours et un coupe-circuit, parce que la démo tourne sur une clé d’API payante.
- Rien n’est conservé après l’expiration de la session.
L’accès public comporte des limites d’utilisation pour maîtriser le coût des services d’IA.
Les décisions que j’ai prises
- Deux processus séparés, volontairement. L’agent parle au système de la clinique en HTTP, exactement comme il parlerait au vrai système d’un client. C’est ce qui donne un sens au bouton « Break the system », et c’est pour cela que le système de la clinique a pu être publié avec son propre OpenAPI, que chacun peut inspecter.
- Cinq règles métier vivent dans un moteur de politiques déterministe, pas dans le prompt : une annulation à moins de 24 heures exige un motif enregistré, rien ne se déplace dans le passé, rien ne se déplace sur un créneau pris, rien ne se réserve en dehors des heures d’ouverture, et le nombre d’écritures par conversation a un plafond fixe. Les règles sont un fichier YAML versionné, et la version figure dans chaque ligne d’audit, si bien que des mois plus tard on peut prouver quelle règle a décidé quoi.
- La confirmation avant une écriture est imposée par le runtime, pas demandée dans le prompt. Une écriture ne s’exécute que si la même opération a été proposée à un tour précédent et que la personne a répondu après. Un modèle qu’on a convaincu de sauter l’étape ne peut toujours pas la sauter.
- Aucun outil n’invente de résultat. Si le système de la clinique n’a pas enregistré la modification, l’outil renvoie une erreur typée et l’agent passe la conversation à une personne, au lieu de confirmer quelque chose qui n’a jamais eu lieu. Coupez le système avec le bouton et regardez ce qui se passe.
- La conversation est une machine à états explicite, avec cinq motifs déclarés pour passer la main à une personne. Une transition qui n’a pas été déclarée lève une erreur.
- L’interface est en anglais, et l’agent répond dans la langue dans laquelle vous écrivez, et change en cours de conversation si vous changez.
Les limites qui restent
- Le système de la clinique est un service de démonstration qui simule l’API d’un client. Ce n’est pas un produit commercial pour cliniques.
- L’agent s’occupe de prendre, déplacer et annuler des rendez-vous. Il ne touche ni aux paiements ni aux dossiers médicaux.