Papéis e permissões

Camada funcional

Correção (27/09/2026): não são mais três papéis, são quatro. Além de proprietário, administrador e membro, existe o colaborador: usa os agentes compartilhados com ele como qualquer membro, mas nunca cria agente nem App. Proprietário decide o que é definitivo — inclusive apagar a organização; administrador gerencia; membro e colaborador usam, com essa única diferença entre os dois.

A matriz

Excluir a organização é a única ação reservada exclusivamente ao proprietário. Atualizar os dados da organização pode ser feito por proprietário ou administrador.

O convite nunca entrega a organização: não se convida alguém diretamente como proprietário. Fora isso, o convite define com qual perfil a pessoa entra — um dos três prontos que se podem convidar, ou um que a organização tenha criado.

Desde 02/10/2026 esses quatro deixaram de ser o teto. Eles continuam existindo, agora como perfis prontos que reproduzem exatamente o que cada cargo podia — então nada muda para quem não mexer. Mas a organização passou a poder criar perfis próprios, ligar e desligar permissão a permissão, e limitar o que cada perfil escolhe. Está em Perfis e permissões por organização.

O colaborador (27/09/2026)

O colaborador existe para quem precisa usar os agentes da empresa sem multiplicar agentes: entra por convite, por domínio de trabalho ou por troca de cargo em Pessoas, e a partir daí é igual ao membro em tudo — conversa com o Oráculo e com os agentes compartilhados com a organização, usa os agentes compartilhados com ele por pessoa ou por time, configura um agente quando recebe compartilhamento de editor ou é gestor do time — menos numa coisa: não cria agente nenhum. Isso vale para o agente comum, para o App e para o "Clonar como novo".

A recusa não depende de por onde você tenta. Ela é conferida no momento da gravação, e não na tela que oferece o botão — então vale igual pela tela de Agentes, pela de Apps, pedindo ao Oráculo ou a um agente de gestão, e também para quem chamar a plataforma por fora, por programa. É uma diferença que importa: uma regra checada só na tela some quando alguém usa outro caminho.

Quem tenta recebe uma recusa curta: "Seu cargo nesta organização não permite criar agentes." Ela é genérica de propósito — a mesma verificação também recusa quem não é da organização, e vai recusar cargos que venham a existir depois. E a interface não fica oferecendo o que vai negar: nas telas de Agentes e Apps, e nas telas vazias de home, área de trabalho e nova conversa, o colaborador vê um convite a pedir compartilhamento, não a "criar o primeiro".

Dois caminhos ficam de fora da regra, de propósito: o revisor de PR, que é uma identidade da própria plataforma ligada por um administrador, e os canais sem pessoa por trás — Telegram, WhatsApp, link público e webhook —, que agem como o dono do agente. Um colaborador conversando por ali não ganha criação por tabela.

Correção (14/09/2026, atualizada em 27/09/2026 com o colaborador): sobre quais PAPÉIS se pode convidar, há uma única exceção — e ela não parte de dentro. Convidar de dentro da organização continua recusando qualquer papel que não seja administrador, membro ou colaborador — a regra acima vale ali por inteiro. A exceção é o nascimento da organização: o primeiro proprietário entra por um convite emitido junto com a criação dela, porque ainda não há ninguém dentro para convidá-lo. É um caminho próprio, separado do convite do dia a dia, e é o único que emite convite de proprietário.

Onde a decisão acontece

A permissão é verificada em duas camadas, e a ordem importa:

1. No banco de dados, que é quem decide de fato. Mesmo que uma tela ou uma rota esqueça de checar, essa camada nega sozinha — é o motivo pelo qual um membro comum nunca recebe dado que não devia, mesmo que algo falhe mais acima.
2. Na interface, que usa essa mesma decisão para mostrar ou esconder as ações. O botão só aparece para quem pode usá-lo, mas a permissão não mora no botão.

Detalhe deliberado: se a verificação de papel falhar por instabilidade, a ação retorna erro — nunca é tratada como ausência de permissão. Negar uma ação de gestão em silêncio, por causa de uma falha transitória, seria pior do que mostrar um erro.

Modo administrador

Proprietário e administrador podem alternar entre ver só o que é seu e ver a organização inteira nas telas de listagem (agentes, conhecimento, times, aprovações).

A preferência sozinha nunca concede acesso: o servidor confirma de novo, a cada ação que amplia o que a pessoa vê, que ela ainda é administradora. Enquanto o modo está ativo, a interface mostra uma barra de destaque no topo, para que ninguém esqueça em que visão está.

Impersonação

Um proprietário ou administrador pode assumir temporariamente a identidade de outro membro, para diagnóstico. Duas garantias verificadas: a ação sempre mira outra pessoa — nunca a própria conta — e o alvo precisa ser membro da mesma organização de quem está impersonando.

As duas valem para a impersonação de dentro da organização, que é a descrita aqui. Quem opera a plataforma tem um caminho próprio, de fora, com regras diferentes — inclusive a de que precisa escrever o motivo, e a de que a entrada fica registrada na trilha da organização visitada. A página sobre a organização como fronteira descreve esse caminho.

Limites conhecidos

Este limite deixou de existir em 02/10/2026, e vale saber o que ele era. Até então os quatro papéis eram o teto: não havia nada entre membro e administrador, e a única granularidade vinha de outros eixos — participação num time, compartilhamento de um agente específico, ou o escopo de uma chave de API. O colaborador, de 27/09, não resolveu isso: ele fica abaixo do membro, não entre os dois.

Com os perfis por organização, esse degrau intermediário passou a ser possível: dá para criar um perfil que faça mais que o membro e menos que o administrador, ligando permissão a permissão. Os outros eixos continuam valendo, e continuam úteis para o que não é papel.