Configuração de um agente

Camada funcional

Um agente é definido por: nome, avatar, descrição, instruções (o que ele é e como deve agir), modelo, as capacidades que ele pode usar e os recursos ligados a ele (conhecimento, integrações, skills, servidores MCP, cofre, repositório). Tudo isso é editável depois — exceto a classe.

De quem é o agente não se escolhe no pedido

Todo agente pertence, desde que nasce, à organização e à pessoa autenticada que o criou — nunca a um valor que o próprio pedido de criação ou edição tenta informar. Quem cria ou edita não escolhe a organização; o sistema decide isso pelo contexto de quem está logado. Isso vale igual pela tela e pela ferramenta que um agente com permissão de gerir a plataforma pode chamar.

O resto da validação ainda não é o mesmo nos dois caminhos. A intenção é que o caminho automatizado nunca aceite o que o manual recusaria, e na criação isso já vale. Na edição, o botão "Salvar alterações" da tela ainda grava sem passar pela validação do servidor; só a ferramenta passa por ela. Exemplo medido em 23/09/2026: ligar o ambiente compartilhado num agente de modelo Cursor é recusado pela ferramenta e aceito pela tela. A correção já está em revisão.

O que pode ser alterado

Praticamente tudo, a qualquer momento: nome, avatar, status, instruções; descrição e os repositórios de código de trabalho (até 10, um marcado como principal); cada capacidade, individualmente; o modelo e seus parâmetros; permissões mais finas por área; a visibilidade padrão das conversas; e o tamanho do ambiente de execução.

O que nunca muda

Identidade e privilégio do agente não são editáveis por ninguém: quem é o dono, a que organização ele pertence, quando foi criado, se ele é o agente central da organização. Uma trava no próprio banco de dados garante isso mesmo que uma futura tela ou API esqueça de checar.

A classe do agente é fixa desde a criação. Existem três classes: o agente central da organização (o Oráculo), o App — que constrói e publica sistemas — e o agente comum. Qual classe um agente novo recebe também vem do contexto da criação, nunca de um campo que o próprio pedido possa preencher. É a única defesa estrutural contra um agente comum se autopromover a App. Na prática, isso quer dizer que não é possível transformar um agente comum já existente num App.

Defaults que valem conhecer

• Um agente novo já nasce na versão mais atual do motor de execução; só nasce na anterior se isso for pedido explicitamente, por importação ou migração.
• O modelo é normalizado antes de valer: fora da lista hoje suportada, o sistema usa um padrão seguro.
• Parâmetros finos de modelo (esforço, raciocínio, contexto, modo rápido) só têm efeito com determinados executores; fora deles, são ignorados sem erro.
• O tamanho do ambiente de execução é validado, nunca aceito às cegas: um valor inválido é recusado. Um App nasce com um ambiente maior porque mantém um servidor de desenvolvimento no ar durante a execução — nesse caso, falta de memória não gera erro visível, a conversa simplesmente para de responder.
• A memória do agente vem ligada por padrão; dá para desligar na configuração.
• Ligar a integração com GitHub torna obrigatório pelo menos um repositório de trabalho — não mais um campo único: um agente comum pode ter até 10, um deles marcado como principal. Um App continua limitado a um repositório só, provisionado automaticamente. Ver a página sobre os repositórios de um agente.
• Um agente de núcleo 2.0 pode trocar a máquina nova a cada conversa por um único ambiente compartilhado entre todas as suas conversas — recusa modelo servido pelo executor Cursor e exige um tamanho de pelo menos 2 GB de memória. O que o porteiro recusa não é a mesma coisa que ele garante: os riscos que você aceita ao ligar, e o que não foi verificado, estão em Um ambiente só, dividido por todas as conversas.

Quem pode configurar

Administrador ou proprietário da organização configura qualquer agente dela, sem precisar de mais nada. Quem não tem esse papel só configura um agente se for o dono dele ou se tiver recebido acesso de configuração por compartilhamento. Excluir segue a mesma regra: o dono apaga o seu; administrador ou proprietário apagam qualquer agente da organização. Essa permissão é sempre conferida no momento da ação — a tela só reflete o que a pessoa pode fazer.

Tudo que a tela configura, você também pede ao agente (24/09/2026)

Toda opção que a tela de configuração oferece também se pede ao próprio agente de gestão da organização — com uma exceção de produto: os canais de mensagem (Telegram e WhatsApp) só se configuram pela tela. É paridade do que dá para configurar; a validação ainda difere entre os dois caminhos na edição, como conta a seção sobre a quem o agente pertence, mais acima.

Antes de mudar qualquer coisa, dá para pedir a lista de opções válidas, e ela é a mesma que a tela usa para montar os seletores: os modelos disponíveis, agrupados por motor e com os níveis de esforço que cada um aceita; a galeria de avatares; os tamanhos de computador, com processador, memória e se aquele tamanho já sobe o Docker sozinho; as visibilidades de conversa; os modos de assinatura no GitHub; e o que cada permissão fina do agente pode conter.

A galeria de avatares é a primeira opção, não a única — uma imagem sua, por endereço ou enviada do computador, sempre foi aceita e continua sendo.

O que mudou de fato: antes, um valor que não existia no catálogo era aceito calado. Um modelo inexistente virava Sonnet em silêncio — três agentes ficaram gravados assim —, um avatar fora da galeria passava sem aviso, e uma permissão escrita com erro de digitação era gravada e depois ignorada, o que faz o agente parecer desobediente quando na verdade ele nunca recebeu a permissão. Agora um valor novo fora do catálogo é recusado com mensagem, em vez de aceito e esquecido.

Um detalhe que evita susto: o valor que o agente já tem continua passando, mesmo que tenha saído do catálogo desde então. Salvar reenvia a configuração inteira, e recusar um campo que você nem tocou travaria o Salvar por causa de um valor antigo em outro canto da tela.

Além das opções, também se pede ao agente de gestão:

• Aprovações e cota do agente — com uma trava: um agente não mexe nas próprias aprovações nem na própria cota. A aprovação existe para pôr uma pessoa no caminho, a cota para pôr um teto; deixar o agente alterar as suas esvaziaria as duas.
• Quem tem acesso ao agente — dá para listar, conceder, mudar o nível e retirar. Só vale para quem já é membro da mesma organização.
• Foto, memórias e quem assina os commits no GitHub. Apontar a conta de outra pessoa exige ser administrador da organização.
• Integrações, servidores de ferramentas e a conversa que um agendamento usa.
• Skills, incluindo versões, publicação, importação e quem mantém, e o compartilhamento de um segredo do Cofre — este último só para destino da mesma organização.

Nomenclatura

Na interface, o agente central da organização é sempre chamado de Oráculo, com acento.