O agente de rede da Microsoft tem uma meta incomum: transformar o raciocínio que deu certo em software comum

“O agente vira um mecanismo para descobrir problemas novos, não um imposto permanente sobre os antigos.”

Essa frase, de um relato de engenharia que a Microsoft publicou em 13 de outubro, é a ideia mais útil sobre agentes operacionais que lemos em algum tempo. Arun Malik, principal software engineer no Azure Networking, descreve um agente de IA que ajuda os engenheiros de plantão a investigar incidentes de rede em produção. Não é anúncio de produto e não traz números de desempenho. O que oferece é um desenho, e uma visão clara de onde o modelo cabe nele.

Quatro fronteiras

A tese de Malik é que “autonomia segura exige uma pilha”, e que o agente é o software determinístico em volta do modelo, sendo o modelo a parte não determinística dentro dele. A pilha tem quatro fronteiras.

Identidade. O agente age em nome do engenheiro que o acionou, “limitado pelas permissões reais dessa pessoa”. Quando uma identidade de serviço é inevitável, vale a mais restrita das duas: “a mais rígida vence”. A política de acesso de cada ferramenta pertence ao time dono da ferramenta e muda por pull request, com esse time como revisor obrigatório.

Ferramenta. Não existe shell livre. As capacidades ficam atrás de uma única interface de ferramentas tipada, com autorização por ferramenta e chamadas estruturadas e registradas em log. Malik rejeita “MCP ou CLI” como falsa escolha: uma CLI em sandbox para trabalho local de baixo risco, MCP para tudo o que cruza uma fronteira de confiança, porque aí ele traz menor privilégio, isolamento de credenciais, auditoria, ganchos de aprovação e limites de taxa.

Mutação. Diagnósticos rodam automaticamente. Escritas em produção param à espera de uma pessoa, e a trava “é aplicada em código no motor de execução, não em prompts”. Pular essa etapa se conquista por procedimento e por tipo de ação, “nunca é concedido porque um modelo é inteligente”.

Tempo. Esta é a novidade.

A quarta fronteira

Quando um caminho de raciocínio dá certo vezes suficientes, ele é convertido num playbook determinístico que roda sem nenhuma chamada ao modelo. O padrão de execução já está pensado para isso: “esqueleto determinístico, recheio probabilístico”. No workflow de recuperação de exemplo, um passo de modelo transforma a saída de um comando em JSON tipado, um passo de asserção valida o resultado e um passo de condição decide. O modelo nunca toma a decisão e nunca segura a credencial de execução.

1. Novo padrão de incidente
2. Agente investiga com ferramentas tipadas
3. Engenheiro aprova qualquer escrita
4. O mesmo caminho dá certo de novo e de novo
5. Playbook determinístico, sem modelo

• Raciocínio do modelo, pago a cada incidente: Agente investiga com ferramentas tipadas · Engenheiro aprova qualquer escrita · O mesmo caminho dá certo de novo e de novo

Incidente e resultadoTrabalho do agente

As consequências vão bem além de redes:

• O custo cai onde está o volume. Incidentes repetidos são a maior parte do plantão. Tirá-los do raciocínio do modelo e passá-los a playbooks elimina o custo de inferência justamente dos casos que dominariam a conta.
• A reprodutibilidade volta. Um playbook se comporta igual toda vez, pode ser testado antes do release e revisado como qualquer outro código. O caminho de raciocínio de um modelo é uma amostra.
• O risco encolhe com a familiaridade. As ações mais frequentes acabam sendo as mais testadas, o oposto do que acontece quando um agente improvisa a mesma correção de um jeito diferente a cada madrugada.
• Trocas de modelo pesam menos. Um playbook não muda de comportamento quando o modelo por trás do agente é atualizado, um risco que descrevemos em a aposentadoria de modelos é a nova depreciação de API.

O que o texto deixa em aberto

Malik não diz quantos acertos são “suficientes”, quem decide a promoção nem como um playbook candidato é testado antes de substituir o raciocínio. São essas as perguntas que uma empresa precisaria responder, e elas se encaixam em processos que a maioria dos times de operações já roda: um playbook proposto é uma mudança, escrita a partir do histórico do agente e aprovada por um engenheiro, com testes e rollback próprios. Defendemos em agentes como autores de mudanças em produção que a gestão de mudanças é onde a autonomia dos agentes é governada. Aqui ela também vira o caminho pelo qual a autonomia deixa de ser necessária.

Dois alertas do texto valem ser guardados. Gerar configuração é a tarefa mais arriscada, porque modelos podem inventar identificadores ou citar políticas que não existem. E “um system prompt ajuda a orientar o comportamento, mas não consegue impor permissões”, já que um texto malicioso em logs ou na saída de ferramentas pode conduzir o modelo.

A pergunta de desenho para os seus agentes de operações

A maioria dos times avalia um agente de operações pela qualidade do raciocínio. O desenho de Malik sugere uma segunda medida: quanto do raciocínio do trimestre passado já virou software neste trimestre. Um agente que resolve o mesmo problema do mesmo jeito pela quinquagésima vez, pagando o custo cheio do modelo, não é autonomia. É um playbook que ninguém escreveu.