Uma matriz para decidir a autonomia

Use esta matriz antes de “liberar um agente”. Se qualquer célula estiver pouco clara, reduza o escopo ou mantenha a tarefa manual.

A resposta não é permanente. Um fluxo pode subir de faixa quando falhas, custo de revisão e sinais de produção sustentam a mudança. Também deve descer quando uma regressão, mudança de domínio ou incidente remove essa confiança.

Quatro falhas comuns — e como diagnosticar

1. Velocidade aparente, fila real

Sintoma: mais PRs entram, mas tempo até a revisão, retrabalho e tamanho dos diffs aumentam.

Diagnóstico: a geração foi acelerada, mas especificação, divisão de trabalho e revisão continuam sendo gargalos. A equipe transferiu carga cognitiva para quem revisa.

Intervenção: limite o tamanho do lote, peça plano antes do diff e revise contra critérios de aceite. Meça tempo até primeira revisão e taxa de mudanças pós-review, não linhas produzidas.

2. Contexto abundante, decisão ausente

Sintoma: respostas citam muitos documentos e ainda tomam decisões incompatíveis.

Diagnóstico: falta uma ordem de autoridade ou um dono para resolver conflito; mais contexto apenas amplifica ambiguidade.

Intervenção: declare fonte de verdade, data de revisão e condição de parada. Converta perguntas repetidas em decisão curta, versionada e ligada à tarefa.

3. Autonomia que não cabe no controle

Sintoma: um agente executa ação fora do propósito, usa credencial ampla ou chega perto de um efeito externo sem confirmação.

Diagnóstico: a política foi escrita como recomendação, não como fronteira técnica. A equipe confiou em instrução onde precisava de permissão, sandbox ou confirmação.

Intervenção: reduza credenciais, separe leitura de escrita, registre tool calls e mova a confirmação para imediatamente antes do efeito. Teste permissão negada como caso de eval.

4. Evals verdes, usuário prejudicado

Sintoma: a suíte passa, mas incidentes, reclamações ou trabalho manual reaparecem em produção.

Diagnóstico: os casos medem uma versão estreita do problema, o grader confunde artefato com resultado, ou o ambiente de avaliação não representa a fronteira real.

Intervenção: investigue transcrições e estado final, não só a resposta textual. Transforme o incidente em caso de regressão; inclua entrada malformada, contexto incompleto, ferramenta indisponível e conflito de instruções.

Evals, métricas e o perigo do incentivo perverso

Uma eval é uma tarefa com entrada, critério de sucesso e lógica de julgamento. Em agentes de múltiplas etapas, a transcrição importa: ela mostra ferramentas, estado intermediário e caminhos que a resposta final pode esconder.¹

Mantenha duas coleções pequenas e vivas:

• capacidade: representa tarefas que o fluxo precisa resolver;
• regressão: contém falhas reais que não podem voltar.

Não premie “percentual de autonomia”, quantidade de tokens, PRs ou linhas geradas. Esses indicadores podem melhorar enquanto o time perde qualidade. Prefira um painel equilibrado:

Pesquisas DORA são úteis como lente para observar entrega e estabilidade como resultados do sistema; elas não provam, isoladamente, o efeito de uma ferramenta de IA.² Esse cuidado evita uma métrica perigosa: “fizemos mais rápido” quando apenas empurramos a conta para produção ou para uma pessoa exausta.

Incidente: responda ao sistema, não ao bode expiatório

Quando um fluxo assistido por IA falhar, retire temporariamente a autonomia daquela classe de ação. Preserve logs, versão de contexto, ferramenta, permissões, entradas e evidências da revisão. Depois faça uma análise sem culpa, mas com responsabilidade clara.

Perguntas úteis para a revisão:

1. Qual resultado observável falhou, e como foi detectado?
2. Que contexto, interface ou decision right estava ausente ou ambíguo?
3. Que controle deveria ter parado, limitado ou tornado reversível a ação?
4. O que muda agora: eval, permissão, fonte de verdade, treinamento, owner ou escopo?
5. Qual sinal permite restaurar autonomia, e quem toma essa decisão?

O objetivo não é produzir um documento ritualístico. É garantir que uma falha deixe o sistema menos propenso a repeti-la. O material do Google SRE sobre incident management enfatiza papéis, comunicação e aprendizado estruturado durante a resposta.³ Para este contexto, isso significa que o incidente não é “erro do modelo”: é evidência sobre o desenho do fluxo.

Onboarding, competências e carga cognitiva

Onboarding AI-native não é uma aula de prompt. É uma prática guiada de responsabilidade distribuída. No primeiro dia, a pessoa acompanha um cartão de delegação real. Na primeira semana, executa um fluxo reversível em sandbox e registra contexto ausente. No primeiro mês, adiciona uma regressão derivada de falha real e participa de uma revisão de autonomia.

As competências evoluem:

• escrever resultados observáveis em vez de pedidos vagos;
• localizar fonte de verdade e declarar incerteza;
• decompor trabalho em etapas revisáveis;
• inspecionar diffs e transcrições pelo efeito, não pelo estilo;
• modelar ameaça, permissão e rollback;
• facilitar discordância respeitosa quando a evidência é insuficiente.

Isso reduz a carga cognitiva apenas quando o sistema também remove escolhas inúteis. Se a pessoa precisa memorizar dez ferramentas, três formatos de prompt e exceções escondidas, a nova camada só aumenta exaustão. Prefira defaults seguros, poucas interfaces previsíveis e uma rota clara de escalonamento.

Exercícios para o seu time

1. Mapa de fronteiras. Escolha um fluxo semanal. Desenhe onde ele cruza produto, código, dados, segurança e operação. Em cada passagem, registre dono, entrada, saída e direito de parar.
2. Falha encenada. Dê ao executor duas fontes conflitantes e uma permissão negada. O critério de sucesso é parar e escalar com a pergunta certa — não contornar a fronteira.
3. Métrica adversarial. Escolha uma métrica de adoção, como PRs por semana. Escreva três maneiras pelas quais ela pode subir enquanto qualidade, segurança ou saúde do time pioram. Adicione um contrapeso ao painel.

Checklist antes de ampliar autonomia

• O resultado é observável e tem dono humano.
• As fontes autorizadas, a ordem de autoridade e a data de revisão estão claras.
• O fluxo diz o que não pode mudar e quando deve parar.
• Ferramentas e credenciais seguem privilégio mínimo; o efeito externo exige confirmação.
• Há casos de capacidade, regressão e falha de permissão/contexto.
• Review e approval seguem impacto e reversibilidade.
• Métricas incluem qualidade, custo humano e sinais de produção, não só velocidade.
• Há rollback, dono de incidente e condição explícita para restaurar autonomia.
• Pessoas podem declarar dúvida ou interromper trabalho sem punição.

Quando não adotar — ou quando manter manual

Não use IA como resposta automática quando o problema ainda não tem objetivo estável, quando a única evidência exige acesso a dados sensíveis sem isolamento, quando não existe rollback aceitável ou quando o volume é baixo demais para pagar a manutenção do fluxo. Também não force adoção em uma equipe já sobrecarregada de revisão: primeiro reduza dívida de contexto, riscos e filas.

Manual não significa atrasado. Para uma decisão rara, irreversível e altamente contextual, a melhor automação pode ser preparar uma análise e preservar a confirmação humana. O critério não é demonstrar modernidade; é melhorar o resultado líquido sem deslocar risco para usuários ou colegas.

Critérios de sucesso

Depois de algumas semanas, uma equipe está evoluindo quando consegue mostrar, em trabalho real:

• tarefas menores com menos reinterpretação durante revisão;
• fontes e decisões encontráveis sem depender de uma pessoa específica;
• autonomia maior apenas em ações reversíveis e bem avaliadas;
• regressões transformadas em controles concretos;
• carga de revisão distribuída, com discordância tratada como sinal útil;
• decisões de expandir, pausar ou reverter apoiadas em evidência, não em entusiasmo.

O objetivo não é delegar tudo. É desenhar um sistema em que pessoas e modelos possam contribuir sem que a velocidade destrua entendimento, accountability ou cuidado. Comece com um fluxo estreito, mantenha a autonomia proporcional à evidência e deixe cada falha melhorar a próxima decisão.

Fontes primárias

• Anthropic — Effective context engineering for AI agents (29 set. 2025)
• Anthropic — Demystifying evals for AI agents (9 jan. 2026)
• OpenAI — Designing AI agents to resist prompt injection
• Google SRE — Incident management and response
• DORA — Research and resources