Se um agente já resolveu o mesmo problema cinquenta vezes, por que ainda raciocina? Hora de virar código
Os melhores agentes autônomos deveriam tornar partes de si mesmos desnecessárias. Cinco perguntas decidem quando uma tarefa repetida vira playbook testado e quando vale pagar pelo raciocínio.
Ouça este artigo · 4 min
Narração completa do artigo, gerada por IA.
Dois relatos de engenharia publicados em 13 de outubro chegam à mesma ideia por caminhos opostos.
No Azure Networking, da Microsoft, um agente de plantão investiga incidentes de produção, e quando um caminho de raciocínio dá certo vezes suficientes ele vira um playbook determinístico que roda sem chamar o modelo. “O agente vira um mecanismo para descobrir problemas novos, não um imposto permanente sobre os antigos.” Analisamos esse desenho em o agente de rede da Microsoft.
No Google, o Gemini 4 Argon passou uma noite explorando uma base de código de 205 mil linhas e propôs seis otimizações. Os engenheiros ficaram com duas, e o que entrou foi código comum com testes, sem modelo nenhum no caminho em tempo de execução. “O agente explora, o mantenedor subtrai”, como o time resumiu no relato que analisamos em seis propostas, duas aceitas.
Nos dois casos, o produto mais durável do agente não foi uma resposta. Foi um software que tornou a próxima resposta desnecessária.
A tese
A nossa visão, e é uma visão, não um fato medido: um agente autônomo bem operado deveria tornar partes de si mesmo desnecessárias com o tempo. Agentes são a ferramenta certa para problemas novos, ambíguos ou variados demais para especificar. Quando um problema deixa de ser qualquer uma dessas coisas, continuar pagando um modelo para raciocinar sobre ele é um custo e um risco que ninguém escolheu. É mais lento que código, mais caro por execução, mais difícil de testar e muda de comportamento sempre que o modelo é atualizado, o problema que levantamos em a aposentadoria de modelos é a nova depreciação de API.
Isso não faz do raciocínio do agente um desperdício. A exploração foi onde o valor apareceu. O erro é nunca convertê-la.
Cinco perguntas
Para qualquer tarefa que um agente executa repetidamente, cinco perguntas decidem se ela fica com o agente ou vira playbook, regra, modelo menor ou código comum.
| Pergunta | Se sim | Se não |
|---|---|---|
| O mesmo caminho já deu certo muitas vezes? | Candidata a playbook | Continue raciocinando; ainda é descoberta |
| As entradas têm formato estável? | Código consegue interpretá-las | Mantenha um passo de modelo só para interpretar |
| O resultado certo pode ser conferido mecanicamente? | Teste como software | Mantenha revisão humana sobre o agente |
| Um erro seria caro ou difícil de reverter? | Converta antes; código testado é mais seguro | Menos urgência |
| O ambiente muda mais rápido do que o código consegue acompanhar? | Mantenha o agente; regras envelheceriam | Converta |
A quarta pergunta vai contra a intuição. Os times tendem a deixar o trabalho mais arriscado com o modelo mais capaz. Mas quando uma ação arriscada tem um caminho certo conhecido, um playbook testado com uma trava de aprovação é mais seguro do que um modelo que pode seguir outro caminho da próxima vez. Autonomia para ações com consequência é mais fácil de justificar quando a ação é determinística, a lógica por trás de conquistar autonomia por classe de ação.
Como costuma ser a conversão
A conversão raramente tira o modelo por completo. O resultado comum é o que o engenheiro da Microsoft chama de “esqueleto determinístico, recheio probabilístico”: o código decide e executa, e um passo de modelo faz só a interpretação que o código não consegue, como transformar uma saída bagunçada em campos tipados que um passo de validação confere depois. O desenho de contas a pagar da Snowflake fez uma escolha parecida, mantendo determinístico o que deve ser determinístico em volta das partes que precisam de um modelo. Onde ainda há uma decisão, mas não é preciso gerar texto, um modelo de decisão calibrado pode substituir um modelo de fronteira por uma fração do custo.
Transformar isso em prática
Três hábitos tornam isso rotina, e não exceção:
- Registre caminhos de raciocínio, não só resultados. Não dá para converter um padrão que você não enxerga. Grave quais ferramentas o agente chamou, em que ordem e com que resultado, para que caminhos repetidos possam ser encontrados.
- Revise o histórico do agente como um backlog. Uma vez por mês, liste os caminhos de sucesso mais frequentes e passe cada um pelas cinco perguntas. Cada conversão é uma mudança, escrita a partir do histórico do agente e aprovada por um engenheiro, com testes e rollback.
- Devolva as falhas. Quando um playbook encontra um caso que não cobre, mande-o ao agente como problema novo. O ciclo entre descoberta e rotina é o sistema.
Daí sai uma métrica útil: a parcela do trabalho do agente no trimestre passado que hoje roda como software. Se for zero, o agente não está aprendendo nada que a organização guarde. Se subir de forma constante, o agente está fazendo o seu trabalho mais valioso, que é encontrar o trabalho que não precisa mais dele.