Permissões, aprovações e rascunhos

Como o ElevenAgents Architect se autentica

O Architect não usa uma conta de serviço separada nem atua como uma identidade diferente. No dashboard da ElevenLabs, as ferramentas dele são executadas no seu navegador, dentro da sua sessão autenticada. Toda leitura ou gravação que ele realiza, desde buscar a configuração de um agente até criar uma branch, é uma solicitação comum feita como se fosse você, sob as permissões do seu workspace.

Isso tem três consequências:

• O Architect só pode fazer o que você pode fazer. Se você não pode editar um agente, o Architect pode lê-lo, mas não pode preparar alterações nele. Se a sua função não permite fazer merge em uma branch protegida, o Architect também não pode fazer merge nela.
• O trabalho dele é registrado em seu nome. As versões que você publica, as branches e as propostas de merge que o Architect cria mostram você como autor. Nada indica que foram criadas pelo Architect.
• Usuários diferentes recebem resultados diferentes. Dois colegas de equipe que pedem ao Architect a mesma alteração podem ter resultados distintos se as funções deles forem diferentes.

O que cada função permite

As funções de acesso ao agente se aplicam ao Architect exatamente como se aplicam a você no dashboard.

Recursos no nível do workspace, como ferramentas, documentos da base de conhecimento e testes, seguem suas próprias permissões de compartilhamento. Consulte O que o Architect pode alterar para saber quais ações se aplicam ao agente e quais se aplicam ao workspace.

Modos de aprovação

Toda conversa com o Architect é executada em um de três modos. Altere os modos pelo botão no compositor ou pressione Shift+Tab para alternar entre eles.

A sua escolha de modo é lembrada no navegador. Não há uma configuração do workspace que imponha um modo para todos. Para exigir revisão de cada alteração em um agente ativo, proteja a branch main dele para que as alterações precisem passar por uma proposta de merge aprovada.

Quais ações pedem confirmação primeiro

No modo Aprovação obrigatória, o Architect prepara alterações na configuração do agente no seu rascunho sem perguntar, porque um rascunho nunca afeta os chamadores ativos. Ele pede confirmação antes de:

• Alterações que têm efeito imediato para chamadores ativos: fazer merge de uma branch e alterar a divisão de tráfego.
• Alterações em recursos compartilhados do workspace: criar, atualizar ou excluir ferramentas, atualizar ou excluir testes e a maioria das alterações na base de conhecimento.
• Ações destrutivas: descartar um rascunho, excluir um procedimento, arquivar um agente ou uma branch.
• Ações no mundo real: realizar uma chamada telefônica de teste.

Leituras nunca pedem confirmação. O aviso de aprovação marca exclusões que não podem ser desfeitas com o rótulo Permanente. A lista completa do que pede confirmação primeiro está em O que o Architect pode alterar.

Três etapas sempre precisam de você, em todos os modos:

• Publicar um rascunho. O Architect abre a caixa de diálogo de publicação, e você seleciona Publicar.
• Aprovar um plano no modo Plano.
• Decidir o que fazer com um rascunho existente. Se a branch já tiver um rascunho que o Architect não criou neste chat, incluindo edições não salvas no editor, o Architect para e pergunta se deve mantê-lo ou descartá-lo antes de preparar qualquer coisa.

Confiar em uma ferramenta durante a sessão

O aviso de aprovação tem uma caixa de seleção Confiar nestas ferramentas nesta sessão. Quando você a seleciona, chamadas posteriores para as mesmas ferramentas nessa sessão são executadas sem perguntar. A confiança termina quando você inicia uma nova conversa. Se você não responder a um aviso de aprovação em cerca de dois minutos, a solicitação expira e o Architect não executa a ação.

Rascunhos, versões e branches

O Architect usa o mesmo modelo de versionamento do restante do ElevenAgents.

“Nada entra em produção sem a sua aprovação” tem um significado preciso:

• As alterações na configuração de um agente são preparadas em um rascunho e chegam aos chamadores ativos somente depois que você publica, em uma branch que recebe tráfego.
• No modo Aprovação obrigatória, ações que afetam o tráfego ativo ou recursos compartilhados aguardam sua aprovação.
• No modo Aprovação automática, o Architect ainda não pode publicar, mas pode fazer merge de branches e alterar divisões de tráfego sem perguntar, dentro das suas permissões.

Algumas alterações fora da configuração do agente passam a valer no workspace assim que são feitas, como criar uma ferramenta ou um documento da base de conhecimento. Elas não afetam o comportamento do agente até que ele as use, o que acontece quando você publica um rascunho que as associa. Recursos do workspace já associados a agentes ativos são a exceção: atualizar uma ferramenta usada por um agente ativo altera esse agente imediatamente. O Architect pede confirmação antes de atualizar ferramentas no modo Aprovação obrigatória.

Histórico de versões e reversão

Cada versão publicada registra o que foi alterado e quem a publicou.

• Ver o que mudou: em Controle de versão > Branches, abra o Histórico de versões de uma branch. Compare qualquer versão com a anterior ou com a versão ativa. Ou pergunte ao Architect, por exemplo: “O que mudou na main na última semana?” Ele lê o histórico da branch e compara as versões para você.
• Ver quem alterou: cada versão mostra o usuário que a publicou. Uma alteração feita pelo Architect mostra o usuário que estava falando com ele.
• Reverter: selecione Reverter para esta versão no histórico de versões. A reversão não remove o histórico. Ela publica a configuração antiga como uma nova versão. Você também pode usar /rollback para que o Architect revise alterações recentes e prepare uma reversão para você publicar.