Autorisations, validations et brouillons

Comment ElevenAgents Architect s’authentifie

Architect n’utilise pas de compte de service distinct et n’agit pas sous une autre identité. Dans le Dashboard ElevenLabs, ses outils s’exécutent dans votre navigateur, au sein de votre session connectée. Chaque lecture ou écriture qu’il effectue, de la récupération de la configuration d’un agent à la création d’une branche, est une requête classique effectuée en votre nom, selon les autorisations de votre Workspace.

Cela a trois conséquences :

• Architect ne peut faire que ce que vous pouvez faire. Si vous ne pouvez pas modifier un agent, Architect peut le consulter, mais ne peut pas préparer de modifications. Si votre rôle ne permet pas de fusionner dans une branche protégée, Architect ne le peut pas non plus.
• Son travail est enregistré sous votre nom. Les versions que vous publiez, les branches et les propositions de fusion créées par Architect vous désignent comme auteur. Rien n’indique qu’elles ont été créées par Architect.
• Les résultats varient selon les utilisateurs. Deux collègues qui demandent à Architect la même modification peuvent obtenir des résultats différents si leurs rôles diffèrent.

Ce que permet chaque rôle

Les rôles d’accès aux agents s’appliquent à Architect exactement comme ils s’appliquent à vous dans le Dashboard.

Les ressources au niveau du Workspace, telles que les outils, les documents de la base de connaissances et les tests, suivent leurs propres autorisations de partage. Consultez Ce qu’Architect peut modifier pour savoir quelles actions s’appliquent à l’agent et lesquelles s’appliquent au Workspace.

Modes d’approbation

Chaque conversation avec Architect se déroule dans l’un des trois modes. Changez de mode depuis le bouton dans le composeur, ou appuyez sur Shift+Tab pour les parcourir.

Votre choix de mode est mémorisé dans votre navigateur. Aucun paramètre du Workspace n’impose un mode à tous les utilisateurs. Pour exiger une vérification pour chaque modification d’un agent en direct, protégez sa branche main afin que les modifications passent par une proposition de fusion approuvée.

Actions nécessitant une approbation préalable

En mode Approbation requise, Architect prépare les modifications de la configuration de l’agent dans votre brouillon sans demander votre accord, car un brouillon n’affecte jamais les appelants en direct. Il demande votre accord avant :

• Les modifications qui prennent effet immédiatement pour les appelants en direct : fusionner une branche et modifier la répartition du trafic.
• Les modifications de ressources partagées du Workspace : créer, mettre à jour ou supprimer des outils, mettre à jour ou supprimer des tests, et la plupart des modifications de la base de connaissances.
• Les actions destructrices : abandonner un brouillon, supprimer une procédure, archiver un agent ou une branche.
• Les actions dans le monde réel : effectuer un appel téléphonique de test.

Les lectures ne nécessitent jamais d’approbation. L’invite d’approbation identifie les suppressions irréversibles par le libellé Permanent. La liste complète des actions nécessitant une approbation préalable se trouve dans Ce qu’Architect peut modifier.

Trois étapes requièrent toujours votre intervention, dans tous les modes :

• Publier un brouillon. Architect ouvre la boîte de dialogue de publication, puis vous sélectionnez Publier.
• Approuver un plan en mode Plan.
• Décider du sort d’un brouillon existant. Si la branche contient déjà un brouillon qu’Architect n’a pas créé dans cette conversation, y compris des modifications non enregistrées dans l’éditeur, Architect s’arrête et vous demande de le conserver ou de l’abandonner avant de préparer quoi que ce soit.

Faire confiance à un outil pour la session

L’invite d’approbation comporte une case à cocher Faire confiance à ces outils pour cette session. Lorsque vous la sélectionnez, les appels ultérieurs aux mêmes outils au cours de cette session s’exécutent sans demander votre accord. Cette confiance prend fin lorsque vous démarrez une nouvelle conversation. Si vous ne répondez pas à une invite d’approbation dans un délai d’environ deux minutes, la requête expire et Architect n’exécute pas l’action.

Brouillons, versions et branches

Architect utilise le même modèle de gestion des versions que le reste d’ElevenAgents.

« Rien n’est mis en production sans votre approbation » a une signification précise :

• Les modifications de la configuration d’un agent sont préparées dans un brouillon et n’atteignent les appelants en direct qu’après votre publication, sur une branche qui reçoit du trafic.
• En mode Approbation requise, les actions qui affectent le trafic en direct ou les ressources partagées attendent votre approbation.
• En mode Approbation automatique, Architect ne peut toujours pas publier, mais peut fusionner des branches et modifier la répartition du trafic sans demander votre accord, dans les limites de vos autorisations.

Certaines modifications en dehors de la configuration de l’agent prennent effet dans le Workspace dès qu’elles sont effectuées, comme la création d’un outil ou d’un document de base de connaissances. Elles n’affectent le comportement de l’agent que lorsqu’il les utilise, ce qui se produit lorsque vous publiez un brouillon qui les associe. Les ressources du Workspace déjà associées à des agents en direct constituent l’exception : la mise à jour d’un outil utilisé par un agent en direct modifie immédiatement cet agent. Architect demande votre accord avant de mettre à jour des outils en mode Approbation requise.

Historique des versions et restauration

Chaque version publiée enregistre les modifications effectuées et la personne qui l’a publiée.

• Voir les modifications : dans Contrôle des versions > Branches, ouvrez l’Historique des versions d’une branche. Comparez n’importe quelle version avec la précédente ou avec la version en direct. Vous pouvez aussi demander à Architect, par exemple : « Qu’est-ce qui a changé dans main au cours de la dernière semaine ? » Il lit l’historique de la branche et compare les versions pour vous.
• Voir qui a effectué les modifications : chaque version indique l’utilisateur qui l’a publiée. Une modification effectuée par Architect indique l’utilisateur qui échangeait avec lui.
• Restaurer : sélectionnez Revenir à cette version dans l’historique des versions. La restauration ne supprime pas l’historique. Elle publie l’ancienne configuration comme nouvelle version. Vous pouvez aussi utiliser /rollback pour demander à Architect d’examiner les modifications récentes et de préparer une restauration que vous pourrez publier.