Níveis de autonomia dos agentes

• A engenharia agentiva está se aproximando mais de um projeto operacional do que da escrita de prompts, e é preciso definir, para cada tarefa, a autonomia permitida junto com o método de validação que a sustentará
• Um modelo de escada única é útil para expressar numericamente a confiança em um agente, mas a capacidade de lidar com vários agentes ao mesmo tempo deve ser vista em dois eixos: agency e orchestration
• O modelo de níveis 0 a 5 vai de Assist, em que o agente apenas faz sugestões, até orquestração managed-by-exception, em que humanos intervêm apenas em situações excepcionais; quanto mais alto o nível, mais claros precisam ser objetivo, escopo, evidências, permissões e orçamento
• Em uma análise da Anthropic sobre o Claude Code, dados de cerca de 400 mil sessões e aproximadamente 235 mil usuários mostraram um padrão em que humanos tomam cerca de 70% das decisões de planejamento, enquanto Claude assume cerca de 80% da execução
• O uso maduro de agentes não depende de exibir alta autonomia, mas de aplicar calibrated autonomy de acordo com o risco e o grau de reversibilidade, e de gerenciar o gargalo de validação

---

Da escrita de prompts ao projeto operacional na engenharia agentiva

• O centro da engenharia agentiva está se deslocando da escrita de prompts para o projeto operacional
• Fábricas de software, objetivos, loops, sessões em segundo plano, subagentes, hooks, sandboxes e formas de agentes aprovarem agentes passam a ficar em primeiro plano
• Claude Code e Codex são tratados como produtos representativos dessa mudança
• Engenheiros podem usar baixa autonomia para reduzir riscos e facilitar reversões, e usar autonomia mais alta e frotas de agentes em paralelo para atividades bem definidas ou refatorações em grandes bases de código
• A pergunta central é qual nível de autonomia permitir para cada tarefa e que tipo de validação consegue defender esse nível

Autonomia vista em dois eixos, não em uma escada única

• A escada de eixo único mencionada por Steve Yegge em “Welcome to Gas Town” é útil para expressar em números a confiança em um agente
• No início de 2026, mesmo em um contexto em que o trabalho se deslocava de delegação para orquestração, esse eixo único ainda funcionava como um proxy aproximado para medir risco
• Quando se torna possível executar vários agentes ao mesmo tempo, um único nível não basta para explicar a capacidade multiagente
• Discussões sobre autonomia frequentemente misturam duas perguntas diferentes
  • Até que ponto é possível enviar um único agente para longe do humano
  • Quão bem é possível coordenar vários agentes
• Para separar isso, são necessários dois eixos
  • agency: quão autonomamente um agente executa propostas, tarefas limitadas e alcance de objetivos
  • orchestration: quão bem coordena desde uma única thread até várias árvores de tarefas e trabalho contínuo baseado em backlog, issue tracker e agenda

O significado de agency e orchestration

• Em níveis baixos do eixo de agency, o agente sugere ações candidatas e espera a decisão humana
• Em níveis intermediários, o agente executa uma tarefa específica com escopo limitado e continua relatando o que fez com evidências, para que o humano possa ajustar
• Em agency alta, o agente experimenta, aprende, testa, trata bloqueios, faz perguntas e tenta outras abordagens em direção a um objetivo, retornando tudo isso como evidência
• O nível baixo do eixo de orchestration é um agente e uma thread
• Em níveis intermediários, vários agentes executam objetivos diferentes em worktrees separados
• Em níveis altos, um orquestrador transforma backlog, issue tracker, agenda e filas em trabalho contínuo, e o humano intervém apenas em caso de falha, em um formato de management by exception
• Exemplos de recursos e produtos relacionados incluem
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, subagentes, hooks, checkpoints, formas de delegação e gestão de agentes, sessões em segundo plano, padrões de equipes de agentes, argumento /schedule
  • Codex: threads locais e na nuvem, Goal mode, worktree, Automations, subagentes, painel de revisão, code review no GitHub, hooks, sandbox, Auto-review, rerun

Três eras e seis níveis

• Lida de baixo para cima, a escada parece elevar agency e orchestration ao mesmo tempo
• Os seis níveis se dividem em três eras
  • A era em que o humano está no banco do motorista, e o agente auxilia enquanto espera a operação humana
  • A era em que o agente assume uma tarefa ou objetivo limitado, mas o humano ajusta e valida
  • A era da orquestração, em que o sistema distribui trabalho entre vários agentes, e o humano intervém principalmente quando surgem problemas
• Na engenharia real, é natural alternar entre vários níveis ao longo de um dia

Level 0: Assist

• O agente faz sugestões geralmente boas e às vezes perfeitas, mas a decisão de executar é sempre do humano
• Exemplos incluem autocomplete, sugestões de edição inline e situações em que uma mudança ainda sem dono é discutida no chat
• É adequado para erros de alto custo, mudanças muito pequenas e trabalhos em que o julgamento ainda está sendo formado
• A validação ocorre em sua maior parte localmente

Level 1: Supervised action

• O agente edita ou executa comandos em nome do usuário, mas pede permissão ao humano antes de execuções importantes
• É próximo da postura padrão usada pela maioria das pessoas
• Pode ocorrer em uma sandbox local, com aprovação antes de aplicar mudanças, ou em uma sessão interativa
• Cada aprovação funciona como uma validação independente de que aquela mudança pode ser aplicada
• O principal modo de falha é a fadiga de aprovação
  • Todas as aprovações podem começar a parecer iguais, independentemente do que esteja sendo aprovado
  • É possível responder a isso passando rapidamente pelo diff, seguindo heurísticas, pedindo confirmação a outra pessoa ou permitindo que o agente assuma a responsabilidade
• O Codex Auto-review trata esse problema delegando a aprovação final de condições de fronteira a um agente revisor separado

Level 2: Scoped task delegation

• É o nível em que uma tarefa limitada é passada ao agente
• A tarefa deve ter um objetivo claro, restrições e uma definição de trabalho concluído
• O humano permanece por perto e pode interromper, mas na maior parte do tempo não se envolve diretamente
• É tratado como um nível próximo ao centro na engenharia de software
• A validação se desloca da checagem direta humana para evidências que o agente consegue gerar
  • Testes automatizados aprovados
  • Tipos adequados
  • Sugestões de lint
  • Capturas de tela
  • Procedimentos de reprodução
  • Fontes baseadas em exemplos

Level 3: Goal-driven autonomy

• O agente executa o que for necessário para atingir um objetivo até que determinadas condições sejam satisfeitas
• No modo de prompt, o próprio prompt se torna o objetivo
  • Ex.: “É possível reduzir o time-to-interactive desta página para menos de 1 segundo?”
• No Codex, isso corresponde ao Goal mode, em que o agente repete as etapas plan -> act -> test -> review e para quando não consegue mais satisfazer os critérios de sucesso
• No Claude Code, isso corresponde aos comandos /goal, /loop e /schedule
• Para que esse nível seja útil, a condição de parada precisa ser mensurável de uma forma automatizável
• Objetivos vagos como “melhorar a experiência do usuário de forma geral” ou “tornar a base de código mais testável” não são adequados
• Objetivos mais adequados devem ser concretos, mensuráveis e automatizáveis
  • Encontrar bugs de produção que escapam da análise estática
  • Reduzir tempo de carregamento
  • Garantir uma build TypeScript estrita sem any explícito
  • Classificar todas as dependências para manter apenas dependências compreensíveis e que passem nos testes
• Para encontrar bugs de produção, o agente precisa estar em um ambiente semelhante ao de produção

Level 4: Parallel delegation

• É o nível em que vários agentes trabalham em paralelo
• Cada agente assume uma parte separada da tarefa
• O maior gargalo é a decomposição, ou seja, decidir quais partes delegar
• Recursos de apoio incluem subagentes, sessões em segundo plano, /batch, worktree e equipes de agentes
• O principal modo de falha é o falso paralelismo
  • Se vários agentes trabalham em partes sobrepostas ao mesmo tempo, podem gerar merge conflicts e decisões duplicadas em vez de mais trabalho realizado
• Para operar bem, os agentes precisam estar isolados uns dos outros
  • Cada um deve ter seus próprios arquivos e estado
  • Cada um também deve ter sua própria fila de revisão
• Cada agente gera custo de tokens, proporcional ao número de agentes executados simultaneamente
• Do lado humano, depois de certo número, o custo marginal de adicionar agentes aumenta por causa do imposto de orquestração

Level 5: Managed-by-exception orchestration

• O humano define a definição de sucesso e as políticas a aplicar, e um manager agent desperta conforme gatilhos para distribuir trabalho
• Exemplos de gatilhos incluem nova issue, nova tarefa e relógio
• O manager agent aloca agentes trabalhadores, monitora o progresso, valida entregáveis e tenta novamente em caso de falha
• Quando as condições são satisfeitas, ele escala para um agente mais capaz ou para um humano, agrega os resultados e devolve artefatos de trabalho, como PRs, e evidências a sistemas externos
• Este nível é comparado a uma fábrica
  • A entrada é um issue tracker ou backlog
  • A saída são várias issues ou bugs resolvidos
• Os agentes trabalham em ambientes isolados com limites suficientes e rotas de saída quando necessário
• O que essa fábrica deve fazer é determinado pelo sistema operacional definido pelo manager agent
• A OpenAI propôs uma spec para o Symphony, com um board do Linear no centro
  • Cada issue tem seu próprio workspace de agente
  • O agente verifica se continua avançando em direção ao objetivo definido no arquivo de spec do seu workspace
• A fronteira da orquestração é criar fábricas contínuas de agentes com centenas ou milhares de agentes em operação
• Neste nível, a validação independente se torna ainda mais importante
  • Separação entre implementador e revisor
  • Separação entre executor de testes e QA
  • Separação de verificações de segurança
  • Separação de gates de processo para aceitação

Risco e reversibilidade definem o teto da autonomia

• Em uma pesquisa da Anthropic sobre o Claude Code, em algumas das tarefas mais difíceis o Claude Code fez perguntas de esclarecimento mais de duas vezes mais frequentemente do que usuários o interromperam
• Usuários experientes, definidos como usuários com cerca de 750 sessões, tendiam a usar aprovação automática e interrupções com mais frequência do que usuários com menos de 50 sessões, enquanto acompanhavam o progresso
• Uma análise mais ampla da Anthropic cobre cerca de 400 mil sessões de aproximadamente 235 mil pessoas, de outubro de 2025 a abril de 2026
• Em cada sessão, foi possível identificar decisões como o número de ações solicitadas por prompt pelo usuário, itens aprovados automaticamente e frequência de interrupções
• Humanos tomam cerca de 70% das decisões de planejamento, e Claude executa cerca de 80% do trabalho
• Alta autonomia não significa tirar o humano do loop, mas mudar seu papel de executar cada etapa para definir a próxima direção
• Para julgar se um grande sistema de IA está operando com alta autonomia, são necessárias três perguntas
  • Quão rapidamente é possível saber o que está dando errado
  • Quão limpo é reverter o que está sendo feito
  • O que prova que o que está sendo feito está correto
• Se a resposta for “não dá para saber rapidamente, é difícil reverter e é preciso acreditar no resumo”, então isso não é alta autonomia

Itens que devem entrar no contrato antes de executar um agente

• Antes de toda execução de agente, é necessário um contrato que defina o que ele tentará fazer
• O contrato deve incluir os seguintes itens
  • Objetivo: o resultado a alcançar, não uma atividade ou técnica
  • Escopo: o domínio de trabalho e as técnicas permitidas
  • Não objetivos: o que não está incluído no propósito
  • Ferramentas e permissões: como o agente interage com o mundo externo
  • Condição de parada: quando parar, se possível com variáveis mensuráveis
  • Evidências: testes, capturas de tela, logs, registros de banco de dados etc. que permitam confirmar a conclusão de forma independente
  • Escalonamento: em quais situações alguém intervém, quem intervém e quem executa o agente
  • Orçamento: limites de tempo, esforço e tokens
• Tokens são o orçamento de grandes modelos de IA, e também podem incluir limites para número de tentativas e grau de paralelismo

Métricas tornam a autonomia um pouco mais confiável

• Definir métricas apenas depois do fato pode não ser suficiente
• Métricas podem ser colocadas antes em um documento conciso e tornam a autonomia mais confiável
• Exemplos de métricas que podem ser acompanhadas por nível de autonomia incluem
  • Tempo médio entre intervenções
  • Maior tempo de execução sem supervisão para trabalhos aceitos
  • Proporção entre ações executadas na sandbox e ações escaladas
  • Proporção entre ações aprovadas automaticamente e ações rejeitadas
  • Número médio de ações do agente por instrução humana
  • Taxa de pedidos de esclarecimento
  • Taxa de pedidos de interrupção
  • Tempo de revisão por mudança aceita
  • Taxa de retrabalho por nível de confiança
  • Taxa de vazamento de defeitos por nível de confiança
  • Custo de tokens por mudança aceita
• Um único agente que permanece ocupado com tarefas entregues por humanos se aproxima de Level 4 com dashboard, enquanto um agente conservador que tem intake automatizado, tentativas automáticas e não avança sem evidências suficientes se aproxima de Level 5 com gates reais

Prontidão e escolha do nível de autonomia

• As tarefas devem ser classificadas de acordo com risco e grau de reversibilidade
• A autonomia deve ser aplicada de forma conservadora e elevada apenas quando se acumular evidência que sustente um nível mais alto
• Uma refatoração de motor de pagamentos com testes fortes, agente revisor e caminho de rollback limpo pode sustentar autonomia maior do que uma automação de documentos sem critério de resposta correta
• O nível de autonomia deve seguir o processo de validação, não o nome da tarefa

Quatro antipadrões de autonomia

• Autonomy as status

  • A classificação de autonomia do agente funciona como um distintivo de status sem significado
  • Alta autonomia é tratada como prova de capacidade, não de segurança, e o agente é executado em um nível que a validação não consegue sustentar
  • É preciso elogiar e recompensar quem escolhe o nível correto de autonomia e não ultrapassa limites

• Permission laundering

  • Por causa da fadiga de aprovação, permissões de acesso mais amplas do que o necessário são concedidas a agentes de IA e ferramentas
  • É preciso reforçar limites como perfis de sandbox, raízes de escrita com escopo limitado, listas de comandos permitidos, hooks e Auto-review

• Summary substitution

  • O resumo do trabalho do agente substitui a revisão
  • É preciso anexar o mesmo pacote de evidências que acompanharia uma revisão manual
  • Isso pode incluir diff, testes, logs, capturas de tela, achados do revisor, riscos e lacunas

• Fleet cosplay

  • Dezenas de agentes são executados em paralelo, mas o humano continua coordenando manualmente todas as dependências
  • Estado compartilhado, regras de propriedade e melhor rastreamento de dependências reduzem a necessidade de coordenação manual
  • Limites menores de WIP forçam o foco em codificar e documentar etapas de coordenação, o que pode levar à automação de orquestração

Como subir com segurança

• É proposto um exercício de calibração revisando 10 tarefas recentes que receberam ajuda de agentes
  • O nível de autonomia de cada tarefa
  • Risco
  • Facilidade de reversão
  • Evidências geradas para satisfazer os requisitos de validação
  • Tempo de revisão
  • Se houve retrabalho
  • Se o mesmo nível de autonomia seria adequado na próxima vez
• Deve-se subir um eixo de cada vez
• O ponto de partida é uma única tarefa limitada realizada por um único supervised agent que produz evidências de sucesso defensáveis
• Depois, expandir gradualmente em três direções
  • Paralelizar tarefas exploratórias centradas em leitura
  • Adicionar agentes de escrita em worktrees separados com regras limitadas de propriedade de arquivos
  • Adicionar automação repetitiva e depois orquestração conduzida por agentes com base em issues, voz etc.
• Cada subida de nível exige novas proteções contra novos modos de falha
• Os modos de falha incluem
  • Execução longa de um único agente: drift, corrupção de contexto, comunicação perdida, desvio de objetivo
  • Trabalho em segundo plano: suposições antigas, handoff fraco
  • Trabalho paralelo excessivo: merge conflicts, decisões duplicadas
  • Trabalho repetitivo excessivo: gasto silencioso de tokens, prompts antigos
  • managed-by-exception: filas longas de revisão, fadiga de notificações
• Não se trata de confiar com mais força, mas de estreitar o escopo, obter evidências melhores, criar caminhos de rollback mais baratos, reforçar gates e tornar regras de propriedade mais claras

Usos adequados por nível

• Level 0 é mais adequado para trabalhos delicados e situações em que o julgamento ainda está se formando
• Level 1 é adequado para a maior parte da exploração próxima a limites bem compreendidos
• Level 2 é adequado para a maioria das tarefas limitadas que podem ter dependências desconhecidas e problemas inesperados
• Level 3 é adequado quando é possível expressar condições de sucesso com clareza suficiente
• Level 4 é adequado quando a tarefa pode ser dividida de forma limpa de acordo com condições de sucesso
• Level 5 é adequado depois que a coordenação e a comunicação necessárias entre várias condições de sucesso foram totalmente codificadas

A validação continuará sendo o gargalo

• Apesar do nível atual de confiança e ferramentas, a postura de equipes maduras de engenharia que trabalham com agentes de IA é calibrated autonomy
• No futuro próximo, será necessário projetar loops que saibam quando trabalhar, quando validar e quando perguntar
• A competência do engenheiro continuará em escolher o nível adequado de autonomia e criar padrões e evidências defensáveis que impeçam seu lado obscuro