Agente autônomo: os 4 níveis de autonomia na prática

A frase que mais ouço em call de cliente nos últimos meses é: "agora é só dar o problema pro agente e ele resolve". Bonito de slide. Péssimo de roadmap. Quem está rodando agentes em código de verdade já entendeu que a régua não é "o agente faz" ou "o agente não faz". A régua é quem aprova, quem reverte e quem audita cada ação que ele toma.

A própria Anthropic, no estudo de autonomia em produção, mostra que 80% das ações de agentes em código têm algum mecanismo de salvaguarda e 73% ainda passam por algum tipo de envolvimento humano. Apenas 0,8% são irreversíveis. Não é por covardia: é porque autonomia sem gate é prejuízo esperando para acontecer.

Neste post a gente arruma a casa. Vou destrinchar quatro níveis de autonomia — do assistente que só sugere até o agente autônomo que roda sem ninguém na sessão — que você consegue mapear hoje no seu time, com critério objetivo de promoção, exemplos reais (Copilot, Cursor, Claude Code, agentes em CI, mas também atendimento, back-office e dados) e os gates de engenharia que sustentam cada degrau. A escala nasceu do agentic code, termo que uso aqui para quando o agente escreve, executa e testa o próprio código — mas ela vale para qualquer sistema em que um agente age.

TL;DR

• O que é: uma escala prática de níveis de autonomia de agente autônomo, em código e em sistema de produto, com critérios objetivos de aprovação, reversão e auditoria.
• Stack/Modelos citados: GitHub Copilot, Cursor (tab + Composer), Claude Code (default + plan + auto), Claude Opus/Sonnet 4.x, GitHub Actions.
• Para quem: tech lead, staff, head de engenharia ou dev sênior que quer subir o time de nível sem virar manchete por agente que dropou tabela em produção.
• Fonte central: Measuring AI agent autonomy in practice — Anthropic e o 2026 Agentic Coding Trends Report.

O que define um "nível" — e o que NÃO define

Vamos tirar o hype do caminho.

Nível de autonomia em agentic code não é quão "esperto" o modelo é. Opus 4.7 rodando atrás de um humano que aprova cada keystroke é nível 1. Sonnet 4.6 rodando dentro do GitHub Actions, abrindo PR sozinho, é nível 4. Mesmo modelo, comportamentos completamente diferentes.

O que define o nível são três perguntas operacionais:

1. Quem aprova a próxima ação? O dev clica? O dev aprova um plano antes? Ninguém aprova e o agente toca?
2. Quem reverte se der ruim? O dev volta no CTRL+Z? Existe rollback automatizado? O blast radius é local ou bate em produção?
3. Quem audita depois? Tem log? Tem trilha em git? Tem eval rodando contra cada saída? Ou ninguém olha?

Os quatro níveis abaixo são, no fundo, quatro combinações dessas três respostas. Quanto mais alto o nível, mais cara fica a infraestrutura ao redor — não o modelo. Esse é o ponto que a galera vendendo "agente que faz tudo" sempre esquece de contar.

Nível 1 — Assistente (humano sempre no loop)

Exemplo canônico: GitHub Copilot tab completion, Cursor inline tab, autocompletar do Codeium.

O agente sugere. O humano aceita. Não tem ação executada sem o dev tocar no teclado, não tem comando rodado, não tem arquivo modificado fora do que aparece como diff inline.

• Quem aprova: o dev, em cada token aceito.
• Quem reverte: CTRL+Z, ou simplesmente não aceitar.
• Quem audita: ninguém precisa. O humano é a auditoria em tempo real.

Esse nível é o "modo seguro" do agentic code. É também o que a Anthropic chama de HITL puro — human-in-the-loop, com o humano dentro do laço de controle. Funciona bem para tarefas curtas, código boilerplate, scaffolding de testes. É o nível com menor blast radius e o de adoção mais rápida no time.

A armadilha é confundir nível 1 com produtividade alta. Aceitar 200 sugestões de tab por dia te faz digitar mais rápido. Não te faz entregar feature mais rápido. Quem trata Copilot como ChatGPT que escreve linha por linha está deixando ROI na mesa.

Fora do código, o nível 1 é o rascunho sugerido. No atendimento, é a macro que o Zendesk ou o Intercom propõe e o atendente edita antes de enviar. No back-office, é o campo pré-preenchido do lançamento que o analista confere e confirma. Em dados, é o autocomplete de SQL dentro do notebook. Mesma anatomia dos três casos: a saída do modelo só vira ação quando um humano toca. O blast radius é a tela de uma pessoa, e o custo de errar é o tempo dela.

Nível 2 — Copiloto agente (humano aprova bloco)

Exemplo canônico: Claude Code no modo default, Cursor Composer/Agent.

Aqui o agente já planeja em multi-arquivo, propõe diffs maiores, executa comando, lê output de teste e itera. Mas pausa antes de cada ação não-trivial: "posso rodar pnpm test?", "posso editar src/auth/middleware.ts?", "posso commitar?".

• Quem aprova: o dev, por bloco de ação. Cada Edit, Bash, Write passa por um prompt.
• Quem reverte: git, reset, e a memória do dev de qual arquivo o agente mexeu.
• Quem audita: o histórico da sessão + o diff do branch.

Esse é o nível em que a maioria dos times está hoje, e é também o nível em que a relação entre o dev e o agente começa a parecer trabalho de dupla. O dev abandona o teclado, vai pegar café, volta, aprova o próximo passo, intervém quando o agente vai para o caminho errado. A própria Anthropic observa esse comportamento na base de usuários do Claude Code: usuários novos auto-aprovam ~20% das ações; usuários com mais de 750 sessões pulam para mais de 40%, mas em compensação aumentam a taxa de interrupção (de ~5% para ~9%).

Tradução prática: quanto mais maduro o usuário, mais ele migra de HITL (aprovo tudo) para HOTL — human-on-the-loop, onde o humano monitora e intervém quando o agente sai do trilho. É uma transição de papel, não de carga de trabalho.

Custo desse nível: você paga em tokens, em interrupções de fluxo do dev e na fadiga de aprovação. Quem nunca clicou "yes" automático sem ler o prompt do Claude Code que atire o primeiro CTRL+C.

Fora do código, o nível 2 é o agente com tool calling e aprovação por ação. No atendimento, ele consulta o pedido no ERP sozinho — leitura é livre — mas para antes de emitir a segunda via, abrir a devolução ou disparar o e-mail: quem clica é o atendente. No back-office, ele concilia as notas fiscais e devolve as divergências para o analista confirmar uma a uma. Em dados, ele escreve a query e mostra o plano de execução e o dry-run; quem roda é o humano. A linha que separa o nível 1 do 2 fora do código é essa: leitura o agente faz sozinho, escrita passa por aprovação individual.

Nível 3 — Agente supervisionado (humano aprova plano)

Exemplo canônico: Claude Code com plan mode, Cursor com plano explícito, qualquer harness customizado em cima do Claude Agent SDK.

A diferença para o nível 2 é cirúrgica e enorme: a aprovação humana migra do plano de ação em vez da ação isolada. O dev olha o plano completo ("vou criar X, modificar Y, rodar Z, abrir PR"), aprova uma vez, e o agente executa sem pedir licença para cada passo.

• Quem aprova: o dev, no plano, antes da execução.
• Quem reverte: git checkpoint antes do plano + rollback automático em caso de teste vermelho.
• Quem audita: trilha completa em git, log da sessão, e idealmente um eval rodando sobre o resultado.

É aqui que o Claude Code documentado pela InfoQ no anúncio do Auto Mode começa a brilhar. O classificador em dois estágios deixa ações seguras passarem direto e escala apenas o que é incerto. O dev consegue, na prática, "abandonar" a sessão por 20–45 minutos e voltar para revisar o resultado. A própria Anthropic relata que a duração média da sessão autônoma do Claude Code quase dobrou em três meses, de menos de 25 minutos para mais de 45.

Esse nível só existe com infraestrutura ao redor. Sem testes confiáveis, plan mode é roleta. Sem pre-commit hook, é commit envenenado. Sem branch isolado, é conflito garantido. Subir do 2 para o 3 é menos sobre o agente e mais sobre higiene de engenharia.

Fora do código, o nível 3 é o plano de atendimento aprovado antes da execução. O agente devolve o roteiro inteiro — "consultar o pedido, checar o prazo de troca, emitir reembolso de R$ 180, responder o cliente" — o supervisor aprova de uma vez e a supervisão vira amostragem, não fila. No back-office, é o lote de conciliação fechado depois de um único OK, com rollback por lote e trilha de quem aprovou o quê. Em dados, é o pipeline de transformação rodando em staging com testes de contrato (dbt tests, Great Expectations) como régua antes de tocar a tabela final. O padrão é idêntico ao do código: o que sustenta o degrau não é o modelo, é existir um teste automático capaz de dizer se o plano deu certo.

Nível 4 — Agente autônomo (humano só revisa output final)

Exemplo canônico: GitHub Copilot Coding Agent rodando em ambiente efêmero do GitHub Actions, harness próprio em CI/CD que pega issue do backlog e abre PR sozinho, FlakyGuard da Uber corrigindo 197 testes flaky em 6 meses sem intervenção humana por tarefa.

O dev não está na sessão. O agente é acionado por um trigger (issue atribuída, label, schedule, webhook), abre o PR, roda os testes, ajusta até verde, e entrega para review humano só no fim.

• Quem aprova: ninguém durante a execução. O humano aprova o PR final antes do merge.
• Quem reverte: rollback de deploy, revert do PR, kill switch do harness.
• Quem audita: logs estruturados, métricas de custo por job, evals automáticas no output, RBAC granular do que cada agente pode tocar.

Aqui mora a parte que a galera não fala em conferência: o agente nível 4 só funciona em escopos bem delimitados. Bug fix isolado, atualização de dependência, refactor mecânico, geração de boilerplate. Tarefa ambígua continua precisando de humano. O relatório 2026 da Anthropic tem um número que coloca isso no chão: devs hoje usam IA em ~60% do trabalho, mas só conseguem delegar totalmente entre 0% e 20% das tarefas. Os outros 40% que estão no meio é exatamente onde os níveis 2 e 3 vivem.

E custo? No nível 4 você paga em compute (cada job do agente é uma sessão completa), em janela de evals (você precisa medir continuamente), em RBAC (cada permissão que o agente recebe é um vetor de ataque). Não é coincidência que o caso da Rakuten relatado pela Anthropic, com 79% de redução no time-to-market (de 24 para 5 dias úteis), tenha vindo acompanhado de "centenas de agentes internos" com governança específica.

Fora do código, o nível 4 é o agente que fecha o ticket sem ninguém na sessão. No atendimento, ele responde o tier 1 inteiro e escala sozinho quando o valor, a confiança do classificador ou o sentimento do cliente passam do limite configurado — o humano revisa por amostragem e por reclamação, nunca ticket a ticket. No back-office, é a conciliação noturna que aprova automaticamente o que bate centavo a centavo e roteia só as exceções para a fila humana. Em dados, é o agente que detecta quebra de schema na origem, abre o PR no dbt e mergeia se os testes de contrato passarem. Repare que o padrão se repete fora do editor: nível 4 vive em escopo estreito e mensurável, com escalonamento explícito para tudo que sai dele.

Human-in-the-loop sem virar gargalo

O erro mais comum de quem leva isso a sério é achar que human-in-the-loop significa "humano aprova tudo". Isso não é controle, é fila. Numa operação de atendimento com 3.000 tickets por dia, um aprovador por tool call transforma o agente num sistema com throughput de humano e custo de LLM: o pior dos dois mundos. O ponto do HITL nunca foi a quantidade de aprovações. É onde elas ficam.

Onde colocar o humano. A regra que uso é temporal: humano antes da ação irreversível, humano depois da ação reversível. Antes vão reembolso, e-mail para o cliente, migration em produção, deploy, alteração de preço, exclusão de dado. Depois vão rascunho, classificação, sugestão, PR aberto — revisar PR é HITL pós-ação barato, porque o merge já é o gate. Errar esse posicionamento é o que trava o time: aprovação prévia em coisa reversível gera fila sem reduzir risco, e revisão posterior em coisa irreversível não é gate, é auditoria de estrago.

Como aprovar em lote. Aprovação individual só faz sentido no nível 2. Do 3 para cima você agrupa de três formas: por plano (uma aprovação cobre a sequência inteira), por janela (a fila acumula 15 minutos e alguém despacha de uma vez) e por classe de ação (allowlist — read-only passa direto, escrita em tabela sensível sempre pergunta). O ganho é de troca de contexto: despachar 40 ações num painel que mostra diff, evidência e a tool chamada custa menos que aprovar 8 prompts interativos que interrompem o dev no meio de outra coisa. E lote pede teto explícito: auto-aprovação até R$ 200 de reembolso, acima disso item a item.

O critério de risco que define o teto. Autonomia máxima não é propriedade do agente, é propriedade da ação. Pontue cada ação em quatro eixos — reversibilidade, blast radius, custo do erro e detectabilidade — e deixe a pior nota mandar. Bump de dependência semver-minor com suíte verde: reverte com um clique, blast radius no repo, custo baixo, o CI acusa em minutos, cabe nível 4. Migration de schema em produção: irreversível na prática, blast radius de banco inteiro, custo alto, detecção às vezes só no dia seguinte, teto nível 2 — mesmo que o agente escreva a migration perfeita. Por isso o mesmo agente de atendimento pode responder em nível 4 e reembolsar em nível 2. Isso é normal, não é inconsistência.

Dos quatro eixos, detectabilidade é o que quase todo mundo esquece — e é o que mais derruba projeto. Se você não descobre em minutos que o agente errou, você não pode dar autonomia a ele, mesmo que a ação seja perfeitamente reversível: reversível que ninguém percebe vira permanente. Na prática, isso põe tracing por sessão, log estruturado de cada tool call e eval contínuo como pré-requisito de nível, e não como item de roadmap para o próximo trimestre. É a mesma conclusão a que cheguei desenhando a arquitetura de agentes de IA camada por camada: guardrails e observabilidade não são a última camada, são a camada que decide até onde as outras podem ir.

Se o gargalo do seu time não é o modelo e sim o gate, subir de nível exige guardrails e observabilidade — os dois estão no Lab, nos dias 19 e 20 de setembro.

Os quatro gates que sustentam qualquer nível

Não importa o nível em que você está — o que muda de degrau para degrau é a profundidade desses quatro gates. Cada subida exige todos eles em estado mais maduro.

Testes

No nível 1 e 2, teste é a régua que o dev usa antes de aceitar. No nível 3 e 4, teste é a única régua. Se o agente rodou, os testes passaram e o pre-commit aprovou, é porque está bom. Se a sua suíte é flaky ou tem cobertura furada, não suba para nível 3. Você vai estar dando autonomia para uma régua quebrada.

Evals

Teste valida correção de código. Eval valida correção de comportamento do agente. No nível 4, ter um conjunto de casos rodando contra cada saída do agente (LLM-as-a-judge, golden dataset, comparação contra baseline) deixa de ser luxo e vira fundação. Sem eval, você não tem como saber se o agente está degradando ao longo do tempo.

RBAC e blast radius

Quanto mais alto o nível, mais explícito tem que ser o que o agente pode tocar. No nível 1, blast radius é o arquivo aberto. No nível 4, é o repo inteiro, o cluster, o banco de produção. Isolamento por ambiente efêmero, allowlist de comandos, segredos via vault, limite de escrita por path — tudo isso vira pré-requisito, não nice-to-have.

Custo

Custo é o gate que ninguém quer falar e que mata projeto silencioso. Nível 1 cobra mensalidade fixa. Nível 4 cobra por job, por minuto de execução, por tokens consumidos em iteração. Sem budget por sessão, sem limite de retry, sem alerta de gasto, o seu agente nível 4 vai virar um terror financeiro antes de virar um terror de segurança.

Como subir um nível sem queimar o time nem a empresa

Quem tenta saltar do 1 direto pro 4 quebra a cara. A subida saudável é por estágio, e cada subida começa fora do agente, na infraestrutura.

Antes de subir do nível 1 para o 2, garanta que o time tem disciplina mínima de branch isolado e sabe ler um diff grande sem aprovar no automático. O risco aqui é fadiga de aprovação virar carimbo de borracha.

Antes de subir do nível 2 para o 3, exija: suíte de testes verde como linha de base, pre-commit hook que pega o que escapar, e um agente com plano explícito — não plan mode interno, mas plano que o dev leu e validou. Plan mode sem testes fortes é só Russian roulette mais lenta.

Antes de subir do nível 3 para o 4, monte: ambiente isolado por job (container efêmero, sandbox), RBAC explícito por operação, eval rodando sobre cada saída, kill switch acessível ao dev de plantão e budget máximo por job. Comece com um único caso de uso bem definido (ex: bump de dependência semver-minor com testes verdes) antes de soltar para escopo aberto.

Esse processo de subir de nível com critério, montar os gates antes do agente, escolher onde delegar e onde manter humano, é exatamente o tema do workshop ao vivo Harness Engineering com Claude Code, onde a gente constrói um harness próprio em cima do Claude Agent SDK do nível 2 ao 4, com testes, evals, RBAC e o loop autônomo rodando em produção.

FAQ rápido

"Plan mode não é nível 4 já?" Não. Plan mode é nível 3: o dev aprova o plano antes da execução. Nível 4 é o agente sendo acionado por trigger (issue, schedule, webhook) sem dev na sessão.

"Vibe coding entra em qual nível?" Depende do que você chama de vibe coding. Se é o dev mandando "faz aí" no Cursor Composer e aceitando tudo, é nível 2 com gate fraco — risco alto de débito técnico. Se é prompt único disparando harness com testes e plan mode, é nível 3 disfarçado.

"Posso ter níveis diferentes para tarefas diferentes no mesmo time?" Sim, e é o cenário mais comum. Bump de dependência em nível 4. Migration de schema em nível 2. Refactor de domínio crítico em nível 1, com pair programming. A escala não é dogma — é critério por escopo.

"Eval automatizado é mesmo obrigatório no nível 4?" Sim, no momento em que o agente é acionado sem dev na sessão. Sem eval contínuo, você só descobre que o agente regrediu pelo cliente reclamando. Promptfoo, custom judges com LLM-as-a-judge ou golden datasets em CI são as portas de entrada baratas.

O que fica

Os quatro níveis não são uma escada que todo mundo precisa subir. São uma régua para você parar de discutir agentic code em termos de "o agente é mágico" ou "o agente é furada", e começar a discutir em termos de gate, blast radius e auditoria.

Quem está no nível 1 hoje e tenta vender nível 4 internamente vai perder credibilidade. Quem está no nível 3 e segue tratando como nível 2 vai perder produtividade. O ganho real está em saber exatamente em que degrau cada parte do seu fluxo de engenharia mora — e em construir os gates certos para subir um por vez, sem queimar o time nem a empresa.

A próxima onda dos agentes de código não vai ser "modelo mais inteligente". Vai ser "harness mais maduro". E quem vai colher o ganho são os times que pararem de tratar autonomia como configuração de produto e começarem a tratar como decisão de engenharia.