VolundOS

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…

Atualizado em 11 de setembro de 2026

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.

Tela de configuração de um agente, com o nome, a descrição e o campo de instruções preenchidos, e as abas de integrações, capacidades, conhecimento e conversas

Aba de capacidades na configuração de um agente, com três capacidades ativas e as demais desligadas

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.

On this page