Quand une équipe met la main sur un modèle performant, la première question est toujours "que peut-on lui faire faire d'autre". C'est la mauvaise question pour commencer. La bonne, c'est "que ne doit-il jamais faire, quelle que soit la tournure de la conversation".

Nous construisons chaque agent de production dans cet ordre. Les limites d'abord, les aptitudes ensuite. Non pas par tempérament prudent, mais parce que c'est la limite qui détermine si la chose est sûre à placer devant de vrais utilisateurs et de l'argent réel.

La capacité est facile, la retenue est difficile

Les modèles modernes sont zélés. Demandez de l'aide à l'un d'eux et il va essayer, même quand la réponse honnête serait "je ne sais pas" ou "il faut qu'un humain s'en charge". Laissé à lui-même, un agent citera volontiers une règle qu'il ne connaît qu'à moitié ou promettra quelque chose que l'entreprise ne peut pas livrer.

La capacité est désormais gratuite. La retenue, c'est ce qu'il faut concevoir. Nous commençons donc par tracer des lignes nettes : quelles actions exigent une confirmation, ce que l'agent peut engager au nom de l'entreprise, quelles entrées il doit refuser d'emblée, et à quel moment il doit transmettre à un humain plutôt qu'improviser.

La valeur d'un agent ne tient pas à ce qu'il sait faire. Elle tient à ce qu'il refuse de faire de façon fiable quand il ne le devrait pas.

L'enveloppe d'abord

Nous voyons les choses comme le tracé d'une enveloppe sûre, à l'intérieur de laquelle on ajoute ensuite des capacités. L'enveloppe, c'est l'ensemble des vérités qui tiennent toujours, quoi que tape l'utilisateur. L'agent ne déplace jamais d'argent sans un humain. Il n'invente jamais un fait qu'il ne peut pas étayer. Il ne discute jamais avec un client agacé, il transmet.

Une fois cette enveloppe en place, ajouter des aptitudes devient peu risqué, car chaque nouvelle aptitude vit à l'intérieur des mêmes limites. Sans l'enveloppe, chaque nouvelle aptitude est une nouvelle façon d'échouer. C'est pour cela que greffer les garde-fous à la fin ne marche jamais. À ce stade, les capacités ont déjà façonné le système, et vous colmatez des trous au lieu de les empêcher d'apparaître.

Les garde-fous sont des décisions produit, pas du théâtre de sécurité

La tentation est de traiter les garde-fous comme une case de conformité à cocher. Ils ne le sont pas. Ce sont parmi les décisions produit les plus importantes que vous prendrez, car ce sont elles qui définissent le caractère de l'agent.

Un bot qui refuse proprement et passe la main à une personne inspire confiance. Un bot qui essaie de tout gérer paraît imprudent la première fois qu'il se trompe sur quelque chose d'important. Les utilisateurs ne retiennent pas les cent questions auxquelles un agent a répondu. Ils retiennent la seule fois où il leur a affirmé une fausseté avec aplomb. Le garde-fou est ce qui empêche ce souvenir de naître.

Comment nous les faisons réellement respecter

Des instructions dans un prompt sont nécessaires mais pas suffisantes. On peut faire dévier un modèle d'une instruction. Les lignes qui comptent vraiment sont donc imposées dans le code, hors de portée du modèle.

Une connexion en lecture seule à la base de données ne peut pas être convaincue d'écrire par un prompt. Une étape de confirmation que le modèle ne peut pas sauter se déclenchera toujours. Un schema sur la sortie garantit que les systèmes en aval n'agissent jamais sur du texte libre. Le modèle est une couche de défense. Le système qui l'entoure est la couche sur laquelle vous vous appuyez réellement. Quand une limite compte, nous la plaçons là où le modèle ne peut pas la contester.

Commencer par le non

Si vous construisez un agent, dressez la liste de ce qu'il ne doit jamais faire avant d'écrire la moindre capacité. Décidez où il s'arrête, inscrivez ces limites là où le modèle ne peut pas les outrepasser, et ce n'est qu'ensuite que vous ajoutez ce qu'il peut faire. Les capacités, c'est la partie facile et amusante. La limite, c'est la partie qui vous permet de dormir.