Modos

O que é um modo

Um modo é uma propriedade de um espaço, guardada como uma coluna na linha do espaço. Todas as conversas dentro de um espaço partilham-no, incluindo as threads — uma thread herda o modo do seu espaço como qualquer outra conversa. Por isso, o mesmo agente pode estar em modos diferentes em espaços diferentes ao mesmo tempo, e mudar o modo de um espaço altera o que acontece no turno seguinte sem tocar no agente.

Há exatamente quatro: chat, review, plan, orchestrate. O próprio enum não transporta qualquer política. Tudo o que um modo garante é declarado uma única vez, num perfil de capacidades, a partir do qual cada camada de aplicação projeta:

Superfície de ferramentas — que ferramentas existem sequer nesse modo, expressas como um nível máximo de aprovação, uma lista de autorizações, uma lista de negações e um conjunto de classes de efeito recusadas.
Verbo de saída obrigatório — aquilo que a execução tem de chamar para ter entregado alguma coisa.
Classes de efeito negadas — aquilo que as barreiras de ação recusam de imediato.
Postura da worktree — se é possível escrever na worktree. Isto é imposto retirando da superfície as ferramentas que alteram o estado, e é isso que faz com que se mantenha em qualquer host. Quando o host tem uma sandbox do sistema operativo, a mesma postura também define as regras de escrita do sistema de ficheiros — um modo só de leitura monta a worktree como só de leitura —, mas isso é uma segunda cópia da garantia, não a que faz o trabalho.
Bloco de prompt do sistema — um preâmbulo de capacidades gerado a partir da lista de ferramentas efetivamente materializada, mais orientações escritas à mão.

Cada camada de aplicação projeta a partir desse único perfil, pelo que a superfície de ferramentas, as barreiras, a postura da worktree e o prompt não podem divergir.

Os quatro modos

Chat — apresentado como “Agent”

O modo predefinido e o único sem restrições adicionais: a superfície de ferramentas completa até ao nível de execução, uma worktree onde é possível escrever, nenhuma classe de efeito negada e nenhum contrato de conclusão. Use-o para implementação, correção de bugs, perguntas sobre a base de código e tudo o que seja pontual.

Repare no rótulo: no compositor, o modo é apresentado como “Agent”, e não como “Chat”.

Plano — só de leitura, um único entregável

O modo plano torna a worktree só de leitura e retira por completo as ferramentas de escrita da superfície, pelo que a restrição é estrutural e não apenas instruída. O agente lê, pesquisa e investiga e entrega exatamente uma coisa: uma chamada submit_plan que transporta um grafo de dependências tipado — um objetivo mais nós com chaves, títulos, descrições e as chaves dos nós de que cada um depende.

O plano aparece como uma linha compacta na conversa e abre o Plan Studio num separador ao lado. Aprová-lo compila o grafo numa orquestração, executa o trabalho gerado e devolve o espaço de criação ao modo agente.

Se uma execução em modo plano terminar sem nunca chamar submit_plan, o loop injeta primeiro um lembrete a dizer que o plano não existe até essa chamada ter êxito. O lembrete autoriza explicitamente uma saída honesta do tipo “aqui não é necessário nenhum plano”, porque o modo plano é uma definição do espaço e uma pergunta comum feita dentro dele não deve forçar um plano falso.

Há uma segunda forma de sair, independente: exit_plan_mode. Não é um verbo de saída, mas sim um portão de aprovação rígido — um agente que a chame em vez de submit_plan não entregou nada. A primeira chamada abre uma aprovação duradoura plan_exit e devolve pending, e o espaço continua só de leitura; chamadas repetidas continuam pending em vez de abrirem um segundo portão. Só depois de a aprovação ser concedida é que uma chamada subsequente muda o espaço para chat. Uma rejeição permite ao agente abrir um novo pedido com um plano revisto.

Para sair do modo plano, mude o seletor do compositor (ou use Shift+Tab). exit_plan_mode é decidido com a ferramenta MCP decide_approval. As linhas de “aprovação de agente” da caixa de entrada são outra coisa: pedidos de confirmação por turno de um agente em execução.

Revisão — só de leitura, sem contrato

O modo de revisão destina-se à revisão de PR. Torna a worktree só de leitura, limita a superfície de ferramentas a um nível abaixo do de execução e aplica uma lista de autorizações escolhida a dedo de ferramentas de revisão, de tickets e de comunicação. Um espaço aberto para uma pull request é criado automaticamente em modo de revisão.

A saída do agente são constatações estruturadas — nós de revisão — e, quando uma revisão é finalizada, um veredicto. Um nó tem um tipo (bug, suggestion, recommendation, question ou ticket), uma prioridade de P0 (bloqueia o lançamento) a P3 (desejável), uma confiança autoavaliada, uma âncora opcional (ficheiro mais um intervalo de linhas; as notas sobre todo o repositório não têm nenhuma) e um estado de ciclo de vida que passa de open para consensusReady quando um par — nunca o autor — o confirma. Uma constatação cuja prioridade ou confiança esteja ausente ou fora do intervalo é descartada na fronteira de leitura, em vez de poluir o veredicto.

O veredicto é ship, hold ou block, e os resultados por eixo que nele são integrados só o podem tornar mais severo: um eixo com portão que falhou força block, e um eixo com portão que não pôde ser executado força pelo menos hold. A ausência de provas nunca faz um portão ficar verde.

Ao contrário do plano e da orquestração, a revisão não tem contrato de conclusão. As constatações acumulam-se através de add_review_node e são publicadas por finalize_review, e ambas podem legitimamente ser chamadas zero vezes — um agente de pipeline em execução no modo de revisão pode estar ali para concluir um ticket.

Orquestração — só de leitura, propõe uma equipa

O modo de orquestração transforma um objetivo num plano para toda a equipa. Tal como o modo plano, é só de leitura e não consegue escrever ficheiros; além da superfície de investigação, tem um único verbo privilegiado, propose_orchestration, que emite uma proposta estruturada: funções, uma árvore de subtickets, um passo de síntese e um orçamento. O prompt só menciona as ferramentas que estão na superfície, pelo que o modelo não gasta turnos a narrar contratações ou trabalho de tickets que não pode invocar.

Nada da proposta é executado enquanto não a aprovar. Após a aprovação, um materializador determinista contrata os agentes, cria os tickets e um projeto e executa um pipeline gerado. A aprovação é exclusiva do operador: não existe nenhuma ferramenta MCP para isso, pelo que um agente pode propor, mas nunca aprovar o seu próprio plano. As repropostas iniciadas por agentes estão limitadas por um período de espera de dois minutos, pelo que replaneamentos consecutivos são recusados e recebem a indicação para agrupar. Consulte Orquestração.

Duas regras que vale a pena conhecer

O próprio verbo de saída de um modo nunca pode ser negado. submit_plan e propose_orchestration estão fixados na superfície de ferramentas e são pré-aprovados, ultrapassando tanto o filtro de ferramentas como o portão de aprovação e as barreiras de ação, pelo que o dial de autonomia por espaço não pode silenciar o entregável de um modo. A ask_user do harness está fixada pelo mesmo motivo: é assim que uma execução chega ao operador, pelo que condicioná-la a um portão bloquearia uma execução que precise de perguntar algo. É de nível de leitura, pelo que todos os modos só de leitura a mantêm, e está isenta do invólucro de aprovação — um prompt à frente de outro prompt falha em modo fechado quando não há nenhum aprovador ligado, o que negaria a um agente o ato de perguntar.

Os modos só de leitura não negam acesso à rede nem a segredos. As classes de efeito que a revisão, o plano e a orquestração recusam são as que mudam o mundo: eliminação de ficheiros, escritas fora da worktree, commits, pushes, criação e publicação de PR, escritas de sincronização com fornecedores, instalação de pacotes, criação de processos, mutação do espaço de trabalho e controlo de recintos. A saída de rede e o acesso a segredos ficam deliberadamente nos valores predefinidos — a investigação é precisamente o objetivo de um modo só de leitura.

Escolher e mudar de modo

O seletor de modo do compositor oferece três opções: Agent (chat), Plan e Orchestrate. review não é selecionável pelo utilizador — é definido pelo sistema quando é criado um espaço de revisão de PR e pelos passos de pipeline.

Um nó de pipeline que abre um espaço pode fixar o modo dessa sala com uma chave extras['mode'] (chat, review ou plan). A chave exige correspondência exata: qualquer outra grafia — incluindo orchestrate — é ignorada em silêncio e a sala recebe o valor predefinido do corpo (review no corpo de criação de espaço). Um passo de agente junta-se a uma sala que não criou e não lhe reconfigura as permissões.

A resolução em si é simples. O dispatcher lê a coluna mode do espaço; um despacho sem espaço — uma execução pontual, uma invocação da CLI ou um id de espaço de outro espaço de trabalho, que simplesmente não está no ficheiro de base de dados deste espaço de trabalho — resolve-se como chat. Mudar o modo produz efeito a partir do turno seguinte.

Onde a garantia se verifica de facto

A superfície de ferramentas de um modo é construída e imposta pelo harness integrado. É o único transporte capaz de tornar uma ferramenta invisível em vez de apenas negada, de condicionar cada chamada a um portão antes de esta ser executada e de observar um contrato de conclusão.

No transporte do Claude Code, um modo diferente de chat é passado como --permission-mode plan. O Claude respeita isso por convenção; as suas próprias ferramentas de leitura, escrita e edição são executadas sem serem vistas e os seus comandos de shell só são verificados por um hook que lê a linha de comandos. Para esse transporte, o modo é uma orientação, não uma fronteira do Control Center — consulte O modelo de agentes.

As listas de autorizações restringem as ferramentas de nível de escrita e superiores. O nível de leitura do harness integrado continua a alcançar ferramentas que nenhuma lista nomeia; no Claude Code, uma ferramenta omitida pela lista de autorizações é recusada, tenha o servidor acesso a ela ou não.

Conceitos relacionados

Ciclo de vida do despacho de agentes: onde o modo é resolvido e projetado
O modelo de agentes: que transportes conseguem impor um modo
Barreiras: a política de classes de efeito em que a predefinição de um modo desemboca
Orquestração: o que faz uma proposta de orquestração aprovada
Usar o modo plano: o passo a passo prático