Configuração de um agente
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…
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.
Uma regra só, para os dois caminhos
Criar e editar um agente segue a mesma regra, esteja a ação vindo da tela ou de uma ferramenta que um agente com permissão de gerir a plataforma pode chamar. Isso existe de propósito: o caminho automatizado não pode aceitar algo que o caminho manual recusaria.
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.
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.
Nomenclatura
Na interface, o agente central da organização é sempre chamado de Oráculo, com acento.
Compartilhamento e visibilidade do agente
Um agente nasce do dono e pode ser compartilhado com pessoas específicas, com times ou com a organização inteira, cada caminho com um nível de acesso diferente.
Memórias e insights do agente
Dois mecanismos diferentes, que costumam ser confundidos: memória é o que o agente guarda sozinho para lembrar depois; insight é uma leitura que a plataforma produz sobre o agente.