Agentes de IA: o que já funciona e o que ainda é demonstração

A demonstração é sempre convincente. O modelo recebe um objetivo, decide sozinho quais ferramentas usar, executa uma sequência de passos e entrega o resultado. Parece que a automação de processos foi resolvida.

Em produção, o comportamento é outro — e a diferença não é de qualidade do modelo. É estrutural, e vale entender por quê antes de investir meses em uma arquitetura que não vai sustentar.

A matemática que explica a frustração

Suponha que cada passo do agente tenha 95% de chance de estar correto. É uma taxa alta, melhor que muita implementação real.

Em três passos encadeados, a chance de a sequência inteira estar certa é 0,95³ — cerca de 86%. Em dez passos, cai para 60%. Em vinte, para 36%.

O problema é que os erros compõem. Um passo errado no meio não é corrigido pelos seguintes; ele vira a entrada deles, e o agente segue construindo com confiança sobre uma base errada.

Isso explica a experiência comum: o agente funciona lindamente em tarefas de dois ou três passos e vira uma máquina de resultados errados a partir de dez. Não é ajuste de prompt que resolve — é a natureza do encadeamento.

O que sustenta produção

Os padrões que funcionam hoje têm uma característica em comum: cadeia curta, com verificação entre os passos.

Uma decisão, uma ferramenta. O modelo escolhe qual ação tomar, o código executa, e o resultado volta para o usuário ou para uma regra. Um passo de julgamento, não vinte.

Classificação e roteamento. O modelo lê a entrada e decide para qual fluxo ela vai. Os fluxos são código determinístico. Isso funciona muito bem, e é o uso mais subestimado.

Extração estruturada. Texto livre entra, campos definidos saem, com validação de esquema. O modelo faz o que faz bem — entender linguagem — e o código faz o resto.

Cadeia curta com confirmação humana entre etapas caras ou irreversíveis.

Fluxo determinístico com etapas de IA. O contrário do agente: o código define a sequência, e chama o modelo nos pontos que exigem interpretação. Menos vistoso, muito mais confiável.

Esse último padrão é o que mais entrega valor real hoje, e é o menos falado — justamente porque não parece autonomia.

Onde a autonomia longa ainda não chega

Vale ser específico sobre os casos que decepcionam:

• Tarefas de muitos passos sem verificação intermediária. O erro composto inviabiliza.
• Decisão irreversível sem confirmação — enviar e-mail, emitir cobrança, alterar dado de cliente, executar comando em produção.
• Objetivo vago. "Melhore nosso processo de atendimento" não tem critério de conclusão, e o agente não sabe quando parou.
• Ambiente que muda durante a execução. O modelo planeja com o estado do começo e não percebe que ele mudou.
• Recuperação de erro. Quando algo falha no meio, o comportamento típico é insistir na mesma abordagem ou seguir como se tivesse funcionado.

Esse último merece atenção especial, porque é o que mais causa dano. Um agente que não reconhece a própria falha continua operando com premissas erradas, e o resultado final parece plausível — o que torna o erro difícil de detectar por quem revisa.

Desenhar para o que funciona

Alguns princípios concretos, que mudam bastante a taxa de sucesso.

Limite o escopo por desenho. Um agente com três ferramentas bem definidas erra muito menos que um com trinta. E dar acesso amplo — "execute qualquer comando" — é convite para o modo de falha mais caro.

Verifique entre passos, com código. A verificação não precisa ser IA. Um esquema validado, uma consulta que confirma o registro, uma regra de negócio conferida — tudo isso custa milissegundos e corta a propagação de erro.

Torne as ações reversíveis, ou peça confirmação. Escrever em rascunho em vez de enviar. Marcar para revisão em vez de excluir. A ação irreversível deve exigir aprovação explícita.

Estabeleça limites duros. Número máximo de passos, tempo máximo, custo máximo. Um laço que não termina é o modo de falha mais comum, e o mais caro.

Registre cada decisão. Qual ferramenta foi chamada, com quais argumentos, qual resultado voltou. Sem esse rastro, depurar comportamento de agente é impossível — e o registro é também o que permite avaliar se ele piorou, como no artigo sobre avaliação.

O custo, que escala diferente

Uma característica que surpreende no primeiro mês de fatura: agente consome muito mais tokens do que a intuição sugere.

Cada passo reenvia o histórico da conversa, incluindo os resultados de ferramenta anteriores. Um agente de dez passos pode consumir dez vezes o contexto de uma chamada simples — e às vezes bem mais, porque o contexto cresce a cada passo.

Duas medidas contêm isso:

• Resumir o histórico em vez de arrastar tudo. Depois de alguns passos, o que importa é o estado atual, não a transcrição completa.
• Truncar resultado de ferramenta. Uma consulta que devolve mil linhas não precisa entrar inteira no contexto — os dez primeiros resultados costumam bastar.

Vale instrumentar por passo, e não só por chamada, para saber onde o consumo se concentra. A infraestrutura de registro descrita no artigo sobre API ou modelo próprio serve exatamente para isso.

A pergunta que evita o projeto errado

Antes de construir um agente, vale responder: o fluxo pode ser descrito como uma sequência de passos conhecida?

Se sim, escreva o fluxo em código e chame o modelo nos pontos que exigem interpretação. Você ganha previsibilidade, custo menor, depuração possível e testes de verdade.

Se não — se o caminho realmente depende do que for encontrado no meio —, aí um agente faz sentido. Mas mesmo assim, com escopo estreito, verificação entre passos e limite de iterações.

Na prática, a maioria dos processos empresariais cai na primeira categoria. Eles parecem exigir autonomia porque são descritos de forma vaga, e não porque a sequência seja de fato imprevisível. Escrever o fluxo explicitamente costuma revelar que ele tem cinco caminhos possíveis, todos conhecidos.

Uma leitura razoável do momento

Agentes de escopo estreito, com poucas ferramentas e supervisão, funcionam e já entregam valor. Triagem, extração, roteamento, geração de rascunho para revisão humana — tudo isso está em produção em muito lugar, funcionando bem.

Autonomia longa sobre processos críticos ainda não está pronta, e a lacuna não é de prompt nem de modelo específico. É de confiabilidade composta e de recuperação de erro, que são problemas em aberto.

A postura que evita frustração é tratar o agente como um estagiário competente e distraído: excelente em tarefas bem definidas, arriscado sem supervisão em cadeia longa, e que precisa de conferência nas ações que não dão para desfazer. Isso não diminui o valor — organiza onde ele está.

Como testar antes de confiar

Agente é especialmente difícil de avaliar, porque o mesmo objetivo pode ser alcançado por caminhos diferentes — e porque a falha costuma ser silenciosa.

Três práticas tornam isso administrável.

Registre a trajetória completa, não só o resultado. Qual ferramenta foi chamada, com quais argumentos, o que voltou, e qual foi o raciocínio declarado. Quando algo sair errado, essa sequência é a única forma de descobrir onde a cadeia se quebrou.

Monte casos com resultado verificável. "Encontre o pedido do cliente X e informe o status" tem resposta checável por consulta ao banco. Executar trinta desses casos antes de cada mudança revela regressão que a leitura de uma conversa não revela.

Meça o número de passos, não só o acerto. Um agente que resolve em três passos e outro que resolve em doze têm a mesma taxa de sucesso e custos muito diferentes. Aumento súbito de passos é sinal de que algo degradou — ferramenta devolvendo erro, descrição ambígua, ou contexto crescido demais.

Vale rodar também alguns casos que não têm solução com as ferramentas disponíveis. O comportamento correto é reconhecer isso e parar; o comportamento comum é tentar indefinidamente ou inventar que resolveu. Descobrir qual dos dois o seu agente faz é mais informativo que qualquer teste de caso feliz.

Onde começar, se for começar

Para quem quer explorar sem apostar o trimestre, existe um caminho de baixo risco.

Escolha um processo interno, repetitivo e cujo erro seja barato. Triagem de chamado, classificação de e-mail recebido, preparação de rascunho para alguém revisar. Nada que fale com cliente, nada que mova dinheiro.

Construa a versão determinística primeiro: o fluxo em código, com o modelo chamado apenas nos pontos que exigem interpretação. Meça quanto tempo isso economiza.

Só depois, se sobrar um ponto onde o caminho realmente varia demais para ser escrito, introduza a decisão do modelo ali — com verificação e limite de iterações.

Esse percurso costuma terminar sem agente nenhum, com o problema resolvido. E quando termina com agente, ele é pequeno, verificável e resolve algo específico — que é exatamente o formato que sobrevive em produção.