Na maioria das conversas sobre engenharia de agentes, a ação mudou de dar prompts para operar. Aqui está uma fronteira olhando para a névoa: fábricas de software, metas, loops, sessões em segundo plano, subagentes, hooks, sandboxes, agentes que aprovam agentes. Para muitos criadores do futuro, esse comportamento será incorporado aos produtos desde o primeiro dia: Claude Code e Codex expõem essa mudança diretamente.
Do ponto de vista do engenheiro, você usará baixa autonomia para limitar riscos e aumentar a reversibilidade, mas usará autonomia mais alta para atividades explícitas e frotas de agentes paralelos refatorando com segurança bases de código massivas. A questão central sobre uma ação é sempre: qual nível essa tarefa merece, e qual verificação torna esse nível defensável?
A borda da fronteira é o agente gerente que acorda com seu gatilho, delegando para seus ajudantes enquanto verifica continuamente a saída deles, e retorna apenas com as decisões que devem ser tomadas por um humano. Pessoas usando esse tipo de configuração podem já estar executando centenas ou milhares de agentes, principalmente em bases de código perenes. Como a maioria das reflexões sobre autonomia, como você percebe a escala ainda é diferente para cada um.
A escala mais mencionada é a escada de eixo único de Steve Yegge, citada em "Welcome to Gas Town" e no The Pragmatic Engineer. É uma boa referência se você quiser um número que indique o quão nativo de IA você é: a escada fornece um único número para medir se você conhece sua confiança em um único agente. Aqui está uma versão dela:
No início de 2026, mesmo enquanto o trabalho começava a mudar de delegação para orquestração, isso era um proxy razoavelmente bom para medir risco. Hoje, no entanto, muitos conjuntos de habilidades podem ter maior significado e alavancagem quando você pode executar muitos agentes ao mesmo tempo. Um único degrau não pode ajudar a posicionar a habilidade com múltiplos agentes.
Em vez disso, quase todo debate sobre autonomia que vi confunde duas questões que deveriam ser separadas: o quão longe de nós mesmos estamos deixando este único agente ir, e qual é nossa habilidade em coordenar muitos agentes?
Para capturar essas duas dimensões separadamente, usaremos dois eixos: agência e orquestração.
No eixo da agência, baixo inclui sugerir ações candidatas e aguardar uma decisão.
Médio significa que o agente está trabalhando em uma tarefa específica, mas delimita o que faz, e relata constantemente o que faz junto com evidências, para que você possa continuar direcionando-o.
Na extremidade de alta agência, o agente está trabalhando em direção a um objetivo, experimentando, aprendendo, testando, encontrando maneiras de resolver um problema, encontrando bloqueios, fazendo perguntas, tentando abordagens diferentes, e retorna todo esse trabalho em evidências.
No eixo da orquestração, baixo significa um agente, um fluxo. No médio, você tem vários agentes, cada um trabalhando em sua própria árvore de trabalho, possivelmente em direção a objetivos diferentes, mas isolados. Na extremidade alta, você tem um orquestrador que pode pegar um backlog, rastreador de issues, cronograma ou outra fila, e transformá-lo em trabalho contínuo, e você só precisa intervir quando as coisas falham: "gestão por exceção". Produtos e recursos que incorporam essas ideias incluem:
- Modos /plan, /goal, /loop, /background, /batch, /code-review, /security-review do Claude Code, subagentes, hooks, checkpointing, práticas de delegação e gestão de agentes, sessões em segundo plano, padrões de equipe de agentes, argumentos /schedule
- Threads locais/cloud do Codex, modo Goal, worktrees, Automações, subagentes, painéis de revisão, revisão de código no GitHub, hooks, sandboxing, Auto-review e rerun
Essas capacidades não cabem em uma única escada.
A escalada: três eras e uma única pilha
Se você ler a escada de baixo para cima, está imaginando escalar agência e orquestração ao mesmo tempo. Com efeito, os seis níveis representam três eras separadas pelas quais todos passamos:
Primeiro, você está no banco do motorista, e um agente principalmente apenas ajuda, esperando você dirigi-lo.
Segundo, o agente assume o controle de uma tarefa ou objetivo delimitado, mas você ainda está por perto para dirigi-lo e verificar o que ele faz.
E terceiro, na era da orquestração, o sistema é capaz de comandar o show, despachando trabalho entre muitos agentes, e você precisa intervir principalmente quando as coisas dão errado: "gestão por exceção."
Isso simplifica as coisas, porque a posição vertical na escada captura perfeitamente os dois eixos (a orquestração só entra em ação perto do topo), deixando-a como uma escalada constante através dos degraus. E ainda assim, a escalada ainda faz parte de uma mudança pela qual todos estamos passando.
Um bom dia de engenharia inclui tocar em vários degraus, às vezes mais: é normal alternar entre as eras algumas vezes no decorrer de uma tarefa.
Os seis níveis em detalhe
Nível 0: Assistir
O agente faz sugestões que são principalmente boas e frequentemente perfeitas, mas você sempre decidirá se são boas o suficiente para agir. Pense em autocomplete, sugestões de edição inline, ou ficar em uma sessão de chat discutindo uma mudança da qual ninguém assumiu a responsabilidade ainda. Use para erros custosos, mudanças minúsculas, ou quando você está formando seu próprio julgamento. A verificação ocorre principalmente localmente.
Nível 1: Ação supervisionada
O agente edita ou executa comandos em seu nome, perguntando antes de executar qualquer coisa consequente. Esta é a postura padrão para a maioria das pessoas. Pode ser feito em sandbox local com aprovações antes de aplicar mudanças - onde cada aprovação é uma verificação independente de que a mudança é segura para aplicar - ou em uma sessão interativa. O modo de falha é a fadiga de aprovação; todas as aprovações parecem iguais, independentemente do que estão aprovando. Você pode resolver isso examinando o diff, seguindo algumas heurísticas, verificando com outra pessoa antes de aprovar, ou apenas concordando em deixar o agente ser responsável. O Auto-review do Codex resolve esse problema delegando a aprovação final das condições de contorno a um agente revisor separado.
Nível 2: Delegação de tarefa delimitada
Entregue uma tarefa delimitada ao agente. Essa tarefa terá um objetivo claro, restrições e uma definição funcional de como é o "pronto". Você ficará por perto, capaz de interromper, mas principalmente não envolvido. Este é o centro de gravidade no mundo da engenharia de software. A verificação está se deslocando de você (você pode precisar descansar e dormir) para evidências que o agente pode produzir: testes automatizados aprovados, tipos adequados, sugestões de lint, capturas de tela, passos de reprodução, proveniência por exemplo, etc.
Nível 3: Autonomia orientada a objetivos
O agente faz o que for preciso para alcançar um objetivo, parando apenas quando alguma condição é atendida. No modo prompt, isso significa que o próprio prompt se torna o objetivo (por exemplo, "Você pode reduzir o tempo para interatividade desta página para abaixo de 1 segundo?"). No Codex, este é o modo Goal: o agente percorre as etapas planejar->agir->testar->revisar até parar de atender aos critérios de sucesso. No Claude Code, são os comandos /goal, /loop e /schedule. Para que este nível seja útil, a condição de parada deve ser mensurável de uma forma que possa ser automatizada.
Não peça ao seu agente para ajudar com objetivos vagos e difusos como "melhorar a experiência do usuário em geral" ou "tornar a base de código mais testável." Escolha algo específico, mensurável e automatizado: encontrar bugs em produção que escapam da análise estática, reduzir o tempo de carregamento, garantir que tenhamos uma compilação TypeScript estrita sem "anys" explícitos, triar todas as dependências para manter apenas aquelas que entendemos e que passam em nossos testes, etc. E, finalmente, para encontrar bugs em produção, o agente precisará estar em um ambiente semelhante ao de produção.
Nível 4: Delegação paralela
Trabalhe com muitos agentes em paralelo. Cada agente trabalha em uma fatia isolada da tarefa. O maior gargalo neste nível é a decomposição: definir as fatias certas para delegar. Os suportes incluem: subagentes, sessões em segundo plano, /batch, worktrees, equipes de agentes, etc. O modo de falha é o falso paralelismo: executar muitos agentes em fatias sobrepostas ao mesmo tempo, então, em vez de mais trabalho, você obtém conflitos de merge e decisões duplicadas. Para fazer isso bem, os agentes precisam estar isolados uns dos outros, cada um possuindo seus próprios arquivos e status. Cada um precisa ter sua própria fila de revisão também. E, finalmente, cada agente incorre em um custo - em termos de tokens consumidos - proporcional ao número de agentes executando ao mesmo tempo. No lado humano, o imposto de orquestração faz com que o custo marginal de adicionar um agente aumente depois de alguns.
Nível 5: Orquestração gerenciada por exceção
Defina como é o sucesso e quais políticas devem ser aplicadas. Um agente gerente acordará com base em gatilhos (por exemplo, nova issue, nova tarefa, relógio), despachará agentes trabalhadores, monitorará seu progresso, verificará a saída, tentará novamente em caso de falha, escalará para agentes mais competentes ou humanos quando as condições forem atendidas, agregará resultados e, finalmente, retornará produtos de trabalho (por exemplo, PRs) e evidências para sistemas externos. Pense em fábrica: o rastreador de issues ou backlog é a entrada, e o produto da fábrica é a saída (ou seja, muitas issues corrigidas, bugs). Os agentes trabalham em um ambiente adequadamente isolado com muitas paredes (e, se necessário, saídas de emergência), e apenas um sistema operacional - definido pelo agente gerente - define o que se espera que a fábrica faça.
O design deste sistema operacional é deixado para o humano; a OpenAI propôs uma especificação para o Symphony que tem um quadro Linear no centro: cada issue recebe seu próprio espaço de trabalho do agente, e o agente garante continuamente que está progredindo em direção ao seu objetivo, conforme definido em um arquivo de especificação em seu próprio espaço de trabalho. A revisão humana pode ser feita na altitude onde as evidências são geradas, mas a fronteira (ou seja, o que é mais poderoso no mundo da orquestração) é construir fábricas de agentes contínuas com centenas ou mesmo milhares de agentes. Neste ponto da escalada, torna-se cada vez mais importante ter verificação independente: implementadores e revisores separados, executores de teste e QA separados, verificações de segurança separadas, portões de processo separados para aceitação.
Risco e reversibilidade definem o teto.
Lembro-me de ler um estudo anterior da Anthropic sobre algumas das tarefas mais difíceis com o Claude Code, onde ele pedia esclarecimento mais de duas vezes mais do que os usuários interrompiam. Usuários experientes (~750 sessões vs. menos de 50) eram mais propensos a aprovar automaticamente e interromper, mantendo um olho no progresso.
Eles também fizeram muita análise mais ampla de como as pessoas usam o Claude Code. Eles analisaram ~400 mil sessões de ~235 mil pessoas entre outubro de 2025 e abril de 2026. De cada sessão, eles podiam descobrir as decisões que alguém toma, como quantas ações eles pedem em cada prompt, quais delas eles escolhem aprovar automaticamente, com que frequência interrompem, etc. As pessoas tomam ~70% das decisões de planejamento, mas o Claude faz ~80% da execução. Alta autonomia não é sobre deixar as pessoas de fora do loop, mas sim sobre passar de fazê-las executar cada etapa para fazê-las decidir para qual direção ir em seguida.
Se quisermos determinar se um grande sistema de IA está operando com alta autonomia, as três perguntas que devemos fazer são:
- Com que rapidez saberemos que estamos errados sobre o que ele está fazendo?
- Com que clareza podemos desfazer o que ele está fazendo?
- O que provaria que estamos certos sobre o que ele está fazendo?
Se a resposta para todas as três for: não rapidamente, com grande dificuldade, e confiando no resumo, não é alta autonomia.
Cada execução de um agente deve ser precedida por um contrato que define o que ele está tentando fazer.
O objetivo: o que estamos tentando alcançar (não uma atividade, não a técnica, mas um resultado).
O escopo: em que domínio estamos operando e quais técnicas são permitidas.
Não-objetivos: o que não faz parte do objetivo.
Ferramentas e permissões: como o agente pode interagir com o mundo. Condição de parada: quando parar; idealmente, uma variável mensurável.
Evidências: testes específicos, capturas de tela, logs, registros de banco de dados ou outros indicadores que possam ser usados para confirmar que algo foi feito (independente do agente).
Escalação: quem se envolve em quais circunstâncias (incluindo quem executa o agente).
E orçamento: um limite de quanto tempo, esforço e tokens devem ser dedicados à tarefa (tokens são o orçamento de grandes modelos de IA - você também pode incluir um limite no número de vezes que ele pode tentar a tarefa e um limite no grau de paralelismo).
Métricas tornam a autonomia um pouco mais confiável
Decidir sobre a métrica depois do fato provavelmente não é suficiente. As métricas podem ser colocadas em prática com antecedência, em um documento conciso. E isso faz com que a autonomia pareça mais confiável e torna o salto de fé um pouco mais fácil de dar.
Embora existam muitas maneiras de medir o sucesso, considere rastrear alguma versão dessas métricas para cada nível de autonomia:
- Tempo médio entre intervenções
- Execução não supervisionada bem-sucedida mais longa com trabalho aceito
- Parcela de ações executadas no sandbox vs. escaladas
- Porcentagem de ações aprovadas automaticamente vs. rejeitadas
- Número médio de ações do agente por instrução humana
- Taxa de solicitação de esclarecimento / Taxa de solicitação de interrupção
- Tempo de revisão por mudança aceita
- Taxa de retrabalho em cada nível de confiança
- Taxa de defeitos escapados em cada nível de confiança
- Custo de token por mudança aceita
Tais métricas podem contar uma história: um único agente mantido ocupado por entregas humanas é o Nível 4 com um painel. Um agente conservador, não disposto a prosseguir sem admissão automatizada, novas tentativas e evidências decentes, é o Nível 5 com um portão real.
Pense sobre prontidão
Classifique o trabalho por risco e por quão facilmente ele pode ser desfeito. Aplique a autonomia de forma conservadora, aumentando apenas à medida que as evidências que suportam o nível mais alto se acumulam. Uma refatoração do mecanismo de pagamento protegida por testes fortes e agentes revisores com um caminho de reversão limpo pode suportar autonomia muito maior do que uma tarefa de automação de documentação sem qualquer verdade canônica. O nível de autonomia deve seguir o processo de verificação, não o nome da tarefa.
Quatro antipadrões
Todo sistema pode facilmente cair presa desses quatro antipadrões de autonomia, a menos que sejam vigilantemente evitados.
Autonomia como status - a classificação de autonomia de um agente se torna um distintivo de status sem sentido. Autonomia mais alta é tratada como prova de capacidade, não de segurança, e os agentes são executados mais quentes do que a verificação suporta. Correção: Elogie e recompense aqueles que se estabelecem no nível correto de autonomia e evitam implacavelmente ultrapassar os limites.
Lavagem de permissão - a tirania da fadiga de aprovação nos leva a conceder aos agentes e ferramentas de IA acesso muito mais amplo do que o necessário. Correção: Melhores limites são sempre uma correção, como perfis de sandbox, raízes graváveis com escopo, comandos na lista de permissões, hooks e Auto-review.
Substituição de resumo - o resumo do trabalho do agente substitui a revisão, assumindo que o resumo é suficiente. Correção: Agrupe o mesmo pacote de evidências que nas revisões totalmente manuais (um diff, testes, logs, capturas de tela, descobertas do revisor, riscos, lacunas, etc.), evitando a rendição cognitiva.
Cosplay de frota - dezenas de agentes são executados em paralelo, mas um humano persiste em orquestrar cada dependência manualmente. Correção: Estado compartilhado, regras de propriedade e melhor rastreamento de dependências reduzem gradualmente a necessidade de coordenar manualmente. Limites de WIP menores forçam um foco em codificar e documentar as etapas coordenadas até que a orquestração se torne automatizada.
Um exercício de calibração
Revise as últimas dez tarefas que você realizou com assistência de agente. Para cada tarefa, registre o nível de autonomia exercido, o risco envolvido, a facilidade com que o trabalho poderia ser desfeito, as evidências produzidas para atender aos requisitos de verificação, o tempo de revisão, se algum retrabalho foi necessário e se o nível de autonomia escolhido ainda seria adequado na próxima vez.
Como escalar com segurança
Suba um eixo de cada vez. Comece com um único agente supervisionado para fazer uma única tarefa delimitada que produza evidências defensáveis de sucesso (um nível de autonomia 1, se for organizado o suficiente). Em seguida, expanda gradualmente nas três direções ortogonais. Paralelize tarefas de exploração pesadas em leitura (nível de autonomia 4). Adicione agentes de escrita atuando em worktrees separadas com regras de propriedade de arquivo restritas (nível de autonomia 4). Adicione automações recorrentes, depois orquestração liderada por agente baseada em issues, voz, etc. Cada passo acima na alavanca requer um novo conjunto de mecanismos de segurança (como novos modos de falha).
Nomeie-os: Execuções mais longas de agente único podem levar a desvio, apodrecimento do contexto, comunicação perdida ou objetivos desviados. Trabalho em segundo plano pode levar a suposições desatualizadas e entregas fracas. Muito trabalho paralelo pode levar a conflitos de merge ou decisões duplicadas. Muito trabalho recorrente pode levar a gastos silenciosos de tokens ou prompts desatualizados. Gerenciado por exceção pode levar a longas filas de revisão e fadiga de alerta. A correção não é confiar mais; em vez disso, estreite o escopo, garanta melhores evidências, habilite caminhos de reversão mais baratos, endureça os portões e defina regras de propriedade mais claras.
Use o nível de autonomia:
- O Nível 0 é melhor para trabalho delicado e quando o julgamento ainda está sendo formado.
- O Nível 1 é melhor para a maioria das explorações, se o trabalho for feito perto dos limites do que é bem compreendido.
- O Nível 2 é melhor para a maioria das tarefas delimitadas, sabendo que pode haver dependências desconhecidas e imprevistos.
- O Nível 3 é melhor onde as condições de sucesso podem ser declaradas com clareza suficiente.
- O Nível 4 é melhor quando o trabalho pode ser dividido claramente entre essas condições de sucesso.
- O Nível 5 é melhor quando a coordenação e comunicação necessárias entre as várias condições de sucesso estão totalmente codificadas.
A verificação sempre será o gargalo.
Apesar da bravata atual e das ferramentas atuais, a postura madura de uma equipe de engenharia trabalhando com agentes de IA é autonomia calibrada.
Os gargalos são coordenação, verificação, manutenção, julgamento de produto e aprendizado com incidentes
Num futuro próximo, vamos querer projetar loops que saibam quando trabalhar, quando verificar e quando perguntar - mas a habilidade do engenheiro ainda estará em escolher o nível certo de autonomia e em construir padrões e evidências defensáveis que protejam contra seus cantos mais sombrios.
Nota: A Pangram rotula este artigo como 100% escrito por humanos: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
