De quem é a credencial usada na conexão

Camada funcional

Um agente conectado a um serviço age lá dentro com alguma credencial. A pergunta é de quem ela é — e ela importa, porque é o nome que fica registrado do outro lado.

Durante muito tempo houve uma resposta só: a conexão guardava uma credencial, autorizada por quem clicou em "Autorizar" primeiro, e todo mundo que usasse aquele agente agia com ela. Num agente de uma pessoa isso não incomoda. Num agente de time, o histórico do serviço passa a dizer que foi sempre a mesma pessoa, mesmo quando não foi.

Hoje a escolha é sua, por conexão:

A tela da conexão ganhou a mesma organização que uma integração tem: uma parte mostra o que aquele servidor sabe fazer, outra mostra de quem é a conta.

Por que o padrão é a conta dedicada

Parece que o padrão natural seria "a conta de quem administra". Não é — e por um motivo simples: as conexões que já existiam guardam uma credencial que ninguém declarou de quem era. Pode ser da pessoa dona, pode ser de uma conta criada só para o agente. "Conta dedicada" é exatamente essa descrição, e é a única escolha que mantém tudo funcionando como funcionava. Marcar as conexões antigas como sendo da pessoa dona faria o sistema procurar uma credencial que não existe, e derrubaria todas elas na primeira execução seguinte.

Duas regras que existem porque o erro contrário já custou caro

1. "Conta de quem está falando" nunca cai na conta de quem administra. Cair seria conveniente, e é o erro clássico: a ação sai, o agente diz que deu certo, e quem agiu no serviço foi outra pessoa. Aqui a conexão fica indisponível e alguém é avisado — nunca em silêncio.
2. Nenhum dos dois modos cai de volta na credencial da conexão. Se caíssem, os três modos seriam dois com nomes diferentes.

Só na conversa pela web existe, de fato, uma pessoa falando. No Telegram, no WhatsApp e nas execuções que partem de um gatilho ou de uma esteira quem "fala" é o próprio sistema — e a tela avisa isso com todas as letras: nesses canais vale a conta de quem administra.

Onde a credencial de cada pessoa fica guardada

Cada pessoa que autoriza tem a credencial dela guardada em separado, cifrada, e fora do alcance do navegador — nem sob o seu próprio login a página consegue lê-la. O que a tela recebe é só a resposta para "estou conectado?", calculada do lado do servidor.

Isso é uma decisão, não um detalhe: guardar as credenciais de todo mundo juntas na conexão elevaria o custo de um único descuido, e tirar o acesso de uma pessoa viraria uma reescrita arriscada.

Quando falta autorização, o agente sabe disso

Sem credencial utilizável, a conexão não entra na execução — e o agente é informado de que ela ficou de fora, e por quê. Sem esse aviso, a ferramenta simplesmente não existiria para ele, e a conclusão seria a errada: "não sei fazer isso", quando a resposta certa é "falta autorizar, e é assim que se resolve".

Na conversa pela web o aviso chega antes: quando o que falta é a sua autorização, o campo de mensagem dá lugar ao pedido de autorizar. Quando o que falta é a autorização de quem administra, você não tem o que autorizar — bloquear a conversa seria um beco sem saída, então quem avisa é o agente, no meio do assunto.

A frase que chega até você nunca cita mecanismo: fala do servidor pelo nome que você deu, e distingue três situações — nunca foi autorizado, a autorização venceu, ou não deu para conferir agora. A terceira é diferente das outras duas de propósito: uma falha momentânea não deve mandar você reautorizar nada.

Servidor que roda por pacote fica de fora

Um servidor executado como pacote roda dentro da máquina do agente, com o login guardado ali — não há credencial de conexão para trocar por pessoa. Nesse caso a escolha simplesmente não tem efeito, em vez de deixar a conexão indisponível: configuração sem efeito não deve derrubar nada.