Hoje eu bati o olho em um detalhe raro. O próprio overview do Microsoft Agent Framework manda uma frase que muita empresa finge não ter lido: "If you can write a function to handle the task, do that instead of using an AI agent." Quando a empresa que está empurrando framework de agentes escreve isso na documentação, eu presto atenção. O repositório microsoft/agent-framework estava com 11.949 estrelas quando eu li.
Hoje eu bati o olho em um detalhe raro. O próprio overview do Microsoft Agent Framework manda uma frase que muita empresa finge não ter lido: "If you can write a function to handle the task, do that instead of using an AI agent."
Quando a empresa que está empurrando framework de agentes escreve isso na documentação, eu presto atenção. O repositório microsoft/agent-framework estava com 11.949 estrelas quando eu li. A versão dotnet-1.13.0 saiu no dia 3 de julho. O tema está quente, mas a regra adulta continua a mesma. Nem todo problema merece agente. Às vezes merece só vergonha na cara, além de uma função bem escrita.
Se você lidera tecnologia, operação ou produto, eu acho que a pergunta útil não é "qual framework está bombando". A pergunta útil é outra: como eu separo um piloto sério de um teatrinho caro?
TL;DR
Eu não escolho framework de agentes por logo bonita, demo editada ou thread animada no X. Eu escolho por tarefa certa, alternativa simples, rastro e aprovação humana.
Eu uso o método P.A.R.A. para decidir rápido: Problema, Alternativa, Rastro e Aprovação.
Se o fornecedor ou o time não responde esses 4 pontos em uma reunião curta, eu não libero piloto. Hype sem governança é retrabalho com branding.
O problema
Eu vejo muito time invertendo a ordem das decisões.
Primeiro escolhe o framework. Depois tenta inventar um problema para justificar o investimento. Isso quase sempre termina em piloto bonito e operação triste.
O que eu gostei no material da Microsoft não foi a promessa de multiagente, checkpoint, middleware ou observabilidade. Isso tudo ajuda. O que me chamou atenção foi a honestidade do aviso: se uma função resolve, use a função.
Na prática, esse aviso corta metade da fumaça do mercado. Porque muita tarefa de empresa não precisa de um agente que planeja, conversa com ferramenta, guarda estado e pede intervenção humana. Muita tarefa precisa de um fluxo claro, uma integração simples e alguém dono do processo.
Eu já vi isso acontecer em atendimento, pré-vendas e operação interna. O time se empolga com autonomia antes de definir a tarefa. Aí o agente vira um estagiário motivado: fala muito, roda bastante e erra onde mais dói.
Se você quiser montar base antes de sair comprando stack, eu ligaria este texto com [agente de terminal](/blog/o-que-e-agente-de-terminal), [agente de código](/blog/agente-de-codigo-4-travas-antes-do-primeiro-commit) e [modelo aberto na IA](/blog/modelo-aberto-na-ia-4-filtros-antes-da-troca). Os três ajudam a cortar a parte romântica da conversa.
O método P.A.R.A.
Framework sem método vira coleção cara de SDK. Eu prefiro decidir com um filtro curto.
P de problema
Eu começo pela tarefa, não pela tecnologia.
A pergunta é simples: existe um problema real, repetitivo e caro o bastante para justificar autonomia parcial?
Se a tarefa muda toda hora, depende de contexto que ninguém documentou e nem o gestor sabe dizer o que é um bom resultado, eu não coloco agente. Eu arrumo o processo primeiro.
Um framework de agentes faz mais sentido quando a tarefa tem começo, meio e fim. Exemplo: triar tickets, qualificar leads, revisar documentos, montar rascunhos operacionais ou consolidar dados de várias fontes.
A de alternativa simples
Esse é o filtro que quase ninguém gosta, justamente porque ele salva dinheiro.
Antes de aprovar framework, eu pergunto: uma função, uma automação tradicional ou um workflow com regra fixa já resolveria isso?
A própria documentação do Agent Framework separa bem o jogo. Ela diz para usar agente quando a tarefa é aberta e conversacional. Ela diz para usar workflow quando o processo já tem passos bem definidos. E ela ainda lembra que, se uma função basta, é melhor ficar na função.
Traduzindo para negócio: autonomia é ótima quando a variação da tarefa pede julgamento. Quando não pede, usar agente vira só um jeito mais caro de fazer a mesma coisa.
R de rastro
Se eu não consigo auditar, eu não consigo escalar.
Foi aqui que eu vi valor real no material do framework. O repositório fala de observabilidade com OpenTelemetry, checkpointing, restartabilidade e controle de execução em workflows. Isso é menos sexy do que demo de avatar, eu sei. Também é infinitamente mais útil.
Eu quero saber quem decidiu o quê, em que etapa, com qual ferramenta e com qual saída. Sem isso, o primeiro erro vira caça ao fantasma.
Agente sem rastro não é automação. É superstição com interface.
A de aprovação
Toda empresa diz que quer autonomia. Quase nenhuma topa autonomia sem cerca.
Eu sempre procuro o ponto de aprovação humana antes de falar de escala. O próprio overview do framework coloca human-in-the-loop como parte do desenho de workflows. Isso é um bom sinal.
Se a tarefa mexe com cliente, contrato, preço, dados pessoais ou publicação externa, eu quero um ponto explícito de revisão. Aprovação bem colocada não mata velocidade. Mata desastre. E desastre custa mais caro do que clique extra.
Como aplicar hoje
Eu não esperaria a próxima reunião de inovação para testar isso. Eu faria assim, hoje.
Passo 1: escolha uma tarefa de 15 a 20 minutos
Eu pegaria uma tarefa chata, recorrente e que já acontece pelo menos 10 vezes por semana.
Dá para resumir call comercial, classificar lead inbound, montar resposta inicial para ticket ou comparar propostas em PDF.
Se a tarefa não aparece com frequência, o piloto já nasce fraco.
Passo 2: escreva o processo em 5 linhas
Eu anotaria:
qual é a entrada
qual é a saída esperada
qual erro é inaceitável
qual sistema o agente pode acessar
em que ponto alguém aprova
Se ninguém consegue escrever isso em 5 linhas, eu não compro framework ainda. Eu compro clareza.
Passo 3: passe pelo P.A.R.A.
Eu faria quatro perguntas objetivas:
Problema: essa tarefa dói de verdade ou só parece moderna?
Alternativa: uma função, RPA ou workflow fixo já resolve?
Rastro: eu consigo log, checkpoint e histórico de decisão?
Aprovação: onde a pessoa entra antes de virar ação irreversível?
Se duas respostas vierem tortas, eu congelo o piloto.
Passo 4: rode 20 execuções antes de escalar
Eu não escalo com demo. Eu escalo com repetição.
Rodaria 20 casos reais ou quase reais e mediria três coisas: taxa de acerto útil, tempo economizado e tipo de erro.
Se o agente economiza tempo, mas gera erro caro, ele não economiza nada. Ele só transfere custo para depois.
Resultados esperados
Eu gosto de expectativa simples e sem fantasia.
Se uma tarefa leva 20 minutos e acontece 15 vezes por semana, ela consome 300 minutos semanais. Isso dá 5 horas.
Se o piloto automatiza 80% do trabalho sem aumentar erro crítico, você recupera 4 horas por semana naquela fila. Em um mês típico de 4 semanas, isso vira 16 horas.
Não é milagre. É agenda.
O ganho real, porém, não é só tempo. É decisão melhor. Quando eu documento tarefa, regra de aprovação e rastro antes do piloto, eu descubro mais cedo se preciso mesmo de agente ou se eu estava tentando esconder bagunça atrás de buzzword.
Perguntas rápidas
Framework de agentes é a mesma coisa que agente pronto?
Não. Eu vejo framework como a caixa de ferramentas para montar, orquestrar e governar agentes. Ele não entrega resultado sozinho. Sem tarefa boa, vira bancada cara.
Eu preciso de multiagente no primeiro piloto?
Quase nunca. Eu começaria com um agente ou até com workflow simples. Multiagente cedo demais é o jeito favorito do mercado de complicar tarefa pequena.
Framework de agentes serve só para empresa grande?
Não. Empresa menor também usa. O ponto é outro: a tarefa precisa justificar a complexidade. Time pequeno sente desperdício mais rápido, então esse filtro fica ainda mais importante.
Quando eu devo evitar framework de agentes agora?
Quando o seu problema ainda é processo mal definido, dado bagunçado ou falta de dono. Agente não conserta desorganização. Só documenta o caos em alta velocidade.
Onde eu aprofundo esse assunto?
Eu começaria por três leituras reais que eu usei aqui: o overview da documentação, o repositório no GitHub e a versão dotnet-1.13.0. Depois eu compararia isso com o seu processo de verdade, não com a demo do vendedor.
Conclusão
Eu gosto de framework de agentes quando ele entra para reduzir trabalho manual com regra, rastro e aprovação. Eu desgosto quando ele vira desculpa elegante para não encarar processo mal resolvido.
Se eu tivesse que resumir em uma frase, seria esta: antes de escolher framework, escolha a tarefa certa. O resto é acessório.
Se esse tema está batendo na sua operação, eu sugiro um teste simples ainda hoje. Pegue uma tarefa, passe pelo P.A.R.A. e veja se você precisa de agente, workflow ou só de menos fumaça na reunião.