O que é um agente de IA?

Um agente de IA é um modelo de linguagem colocado dentro de um loop, com acesso a ferramentas e um critério de parada. Ele decide uma ação, alguém executa, o resultado volta para o contexto e ele decide de novo — até concluir ou desistir. A diferença em relação a uma chamada comum não está no modelo, está em quem decide o que acontece depois da primeira resposta. Escrever para esse formato exige um prompt agêntico, que é diferente de um prompt de engenharia de prompts comum.

O fechamento do loop é a definição inteira. Sem ele você tem uma chamada com ferramenta, que é útil e é outra coisa. Um sistema que consulta uma API de clima e formata a resposta usa ferramenta e não é agente: quem decidiu chamar a API foi você, no código, antes de o modelo entrar. Vira agente quando a decisão de chamar de novo passa a ser tomada com base no que voltou.

O modelo não executa nada

Esse é o mal-entendido mais comum e vale corrigir antes de qualquer outra coisa.

O modelo devolve uma requisição estruturada: “quero usar a ferramenta buscar_pedido com o argumento id=8842”. Ele não busca nada, não abre conexão, não toca no banco. Quem executa é o seu código, que confere o argumento contra o schema declarado, roda a consulta e devolve o resultado como uma nova mensagem no contexto, marcada como resultado de ferramenta e não como texto do usuário.

O que chega ao seu código nem sempre faz sentido. Ele pode pedir uma ferramenta que não existe mais, porque o catálogo mudou no meio da sessão, ou mandar id="oito mil". O texto que você devolve nesses casos decide se ele se recupera ou entra em ciclo. Erro na consulta fecha o caminho. id precisa ser inteiro, recebi "oito mil" abre.

Essa separação é o que torna agente viável em produção. Entre a decisão do modelo e a ação no mundo existe um ponto onde você aplica permissão, valida argumento, limita escopo e, se for o caso, pede confirmação humana. É ali que se decide que buscar_pedido roda direto e cancelar_pedido para e pergunta. Um agente sem esse ponto é uma demonstração, não um sistema.

A regra tem uma exceção. Algumas APIs executam certas ferramentas do próprio lado, como busca na web e execução de código em sandbox, e devolvem o resultado pronto sem passar pelo seu processo. O ponto de controle continua existindo, só que é do provedor e obedece à política dele. Vale saber quais das suas ferramentas são desse tipo antes de escrever a sua política de permissão.

O que muda em relação a uma chamada única

A primeira consequência dessa figura é o custo, e ela é contraintuitiva. O contexto inteiro é reenviado a cada iteração, então uma tarefa de vinte passos não custa vinte chamadas: custa a soma de contextos que crescem a cada passo. A curva é superlinear. Os números estão mais abaixo, com as premissas na mesa.

A segunda é a latência. Vinte iterações são vinte esperas em série, cada uma somando o tempo do modelo ao tempo da ferramenta. Uma tarefa que levaria três segundos numa chamada leva de um a três minutos num agente, e isso muda o produto: não dá para pendurar um agente atrás de um botão de onde o usuário espera resposta imediata.

A terceira quase não aparece nas comparações. Uma chamada única com temperatura zero é praticamente reproduzível; um agente não é. O resultado da ferramenta muda entre execuções, e uma diferença de uma linha na saída do passo 3 leva a uma trajetória diferente no passo 4. Receber dois caminhos distintos para o mesmo pedido é comportamento esperado, não defeito, e isso desmonta boa parte da estratégia de teste que funciona em software comum.

A quarta é aritmética. Se cada passo tem 95% de chance de sair certo e os erros não se corrigem sozinhos, vinte passos em série terminam com 36% de chance de estar tudo certo. A 99% por passo, sobe para 82%. É por isso que cortar a tarefa em quinze passos em vez de trinta costuma render mais do que trocar de modelo.

Nenhuma das quatro é proibitiva quando a alternativa é trabalho humano. Nenhuma se justifica quando um workflow determinístico resolveria.

Quando vale a pena

A pergunta útil é: você consegue escrever a sequência de passos de antemão?

Se consegue, use um workflow. Ele é mais barato, mais rápido, determinístico e depurável. A maioria dos casos que chegam pedindo “um agente” cai aqui.

Se não consegue, porque o próximo passo depende do resultado do anterior de um jeito que você não enumera, aí agente faz sentido. Investigar um bug, pesquisar até achar resposta, navegar uma estrutura que você não conhece de antemão.

Dois pedidos que chegam parecidos e não são. Emitir a nota de um pedido pago tem sequência fixa: ler o pedido, conferir o CNPJ, calcular imposto, chamar a prefeitura, guardar o XML, avisar o cliente. Cada passo tem condição de erro conhecida, e um modelo decidindo a ordem só acrescenta latência e a chance de ele pular o imposto. Descobrir por que a conciliação de ontem fechou com R$ 340 de diferença não tem sequência nenhuma: o próximo lugar onde olhar depende do que apareceu no anterior.

Um teste rápido: se você conseguir desenhar o fluxograma completo, não precisa de agente. O teste engana num caso, e é frequente: há tarefas cujo fluxo cabe em cinco caixas e cuja variação está toda dentro de uma delas. Extrair dados de fatura é o exemplo. O fluxo é sempre receber, extrair, validar, gravar, e o que não se enumera são os quarenta layouts que chegam. A resposta ali não é agente, é workflow com um passo agêntico dentro. Você mantém o determinismo das quatro caixas e paga o loop só onde ele é necessário.

As seis partes

Modelo, ferramentas e loop com parada são o que define um agente. Sem os três não há agente, e o terceiro é o mais fácil de implementar pela metade. Parada precisa de mais de um critério, e o modelo declarar que terminou é o menos confiável deles. Os outros são teto de passos, teto de tokens, tempo de parede e repetição detectada: quando as três últimas ações foram idênticas, ele não está progredindo, está insistindo.

Memória, permissões e harness são o que separa demonstração de sistema.

A memória existe porque o modelo não tem nenhuma. Entre uma chamada e a seguinte ele não guarda nada, e tudo que parece lembrança é texto que o seu código reenviou. O que sobrevive ao fim da sessão, e em que formato, é escolha sua e de mais ninguém.

As permissões decidem o dano possível quando ele erra, e a pergunta útil não é se ele vai errar. É o que acontece quando errar às três da manhã, sem ninguém olhando. Um agente com credencial de leitura numa réplica erra e você lê o log. O mesmo agente com credencial de escrita no banco de produção erra e você restaura backup.

E o harness, tudo que roda em volta do modelo, costuma explicar mais da diferença entre duas ferramentas do que o modelo escolhido. Quanto de uma saída volta ao contexto, em que posição ela volta, o que acontece quando a janela enche: o modelo não responde nenhuma dessas perguntas, e as três mudam a trajetória.

O padrão que virou base

A estrutura que a maior parte dos agentes segue veio de um trabalho de 2022 que propôs intercalar raciocínio e ação em vez de separá-los¹: o modelo escreve o que está pensando, escolhe uma ação, lê o resultado e repete. Parece óbvio hoje e não era. Até ali, raciocinar e agir eram tratados como etapas distintas, e juntar as duas rendeu bastante: em dois benchmarks de decisão interativa, ALFWorld e WebShop, o padrão superou métodos de imitação e de aprendizado por reforço em 34 e 10 pontos absolutos de taxa de sucesso, com um ou dois exemplos no prompt¹.

Duas evoluções vieram em seguida e continuam relevantes. Uma adicionou reflexão sobre a própria falha: depois de errar, o agente escreve em linguagem natural o que deu errado, e esse texto entra no contexto da tentativa seguinte². O detalhe que importa é onde o aprendizado fica. Não nos pesos, que não mudam, mas num buffer de texto que o seu código guarda, reenvia e você pode editar.

Outra mostrou que o uso de ferramenta podia ser aprendido no treino em vez de descrito no prompt³. O modelo anotava o próprio corpus decidindo onde uma chamada de API ajudaria, a partir de um punhado de demonstrações. É a linha que levou aos modelos que hoje já chegam sabendo emitir pedido de ferramenta sem que ninguém explique o formato.

Vale ler os três com a data à vista. Os placares envelheceram; os mecanismos não.

Por que ele funciona na demo e falha em produção

Esse é o relato mais comum de quem coloca o primeiro agente no ar. A reação padrão é trocar de modelo, e ela raramente resolve, porque as três causas mais comuns não são de modelo.

Contexto. A demo tem tarefa de quatro iterações e ambiente limpo. Produção tem histórico acumulado, e a janela enche. Quando enche, alguma coisa é descartada ou resumida, e some primeiro o que estava no começo. A instrução de nunca alterar pedido com status faturado foi dita uma vez, na iteração 1, e não existe mais na iteração 18. Ele não avisa que esqueceu, age como se nunca tivesse lido. Restrição que vale até o fim ou é reinjetada, ou vira validação dentro da ferramenta.

Permissão. Na demo você está olhando, aprovando cada passo e rodando com a sua própria credencial. Em produção ele roda sozinho, com conta de serviço, e o que era uma pergunta na tela virou uma ação executada. A pergunta deixa de ser “ele consegue fazer” e passa a ser “o que acontece quando ele fizer isso no pedido do cliente errado”.

Ferramenta. Na demo toda chamada devolve 200. Em produção a API devolve 429, ou uma lista vazia que não é erro nenhum, ou um 500 com corpo em HTML. Se a mensagem que volta for falha ao consultar, ele repete a mesma chamada, e repete de novo. Se for 429, tente em 30 segundos, limite de 100 chamadas por minuto, ele espera. Mensagem de erro de ferramenta é texto escrito para um modelo ler, com todos os efeitos de prompt, e quase sempre é escrita como se fosse para um arquivo de log.

Antes de trocar o modelo, leia a trajetória: o que ele recebeu depois de cada ferramenta, não o que o terminal mostrou. A maior parte das falhas atribuídas ao modelo aparece ali como contexto truncado ou saída que não dizia nada.

Quanto custa uma tarefa de vinte passos

Números de ordem de grandeza, com as premissas à vista, porque a forma da conta importa mais do que os valores. Suponha instruções de sistema com 2.000 tokens, um catálogo de cinco ferramentas com 1.200, e cada resultado de ferramenta voltando com 800. Os 3.200 fixos vão em toda chamada, e cada iteração acrescenta ao histórico o pedido do modelo mais o resultado que voltou, perto de 900 tokens.

A primeira chamada custa 3.300 tokens de entrada. A vigésima custa 20.400. A soma das vinte passa de 237 mil, contra 3.300 da chamada única. Vinte passos custam cerca de setenta vezes uma chamada, e é essa razão, não o preço por token, que explica a surpresa na fatura.

O prompt caching corta boa parte disso, e num agente ele corta bem, porque cada iteração começa exatamente com o que a anterior já tinha: o prefixo se repete quase inteiro. Tokens lidos do cache custam uma fração do preço de entrada. O que o cache não muda é a forma da curva. Ele abaixa o patamar e deixa o crescimento onde estava.

Duas decisões mexem nesse número mais que qualquer outra. Quantas ferramentas ficam carregadas, porque o catálogo é reenviado em toda chamada: quarenta custam dez vezes o que custam cinco, e as trinta e cinco que ninguém vai usar custam igual. E quanto de cada saída volta: devolver um grep com 3.000 linhas ou devolver as 20 que importam é a diferença entre encher a janela na iteração 8 e chegar à 25.

Conte os seus em vez de confiar nestes. É uma linha de código dentro do seu próprio loop.

Por onde começar

1. Tente sem agente primeiro. Chamada única, depois cadeia de prompts, depois workflow. Só suba um degrau quando o de baixo falhar num caso real, não num caso imaginado.
2. Comece com duas ou três ferramentas. Catálogo grande confunde o modelo e ocupa contexto em toda chamada. Ferramenta nova entra quando uma trajetória mostrar que ela faltou, não porque pareceu útil no papel.
3. Coloque limite de passos desde o primeiro dia. Vinte é um começo razoável e você ajusta com dado. Um agente sem teto vira uma fatura.
4. Decida o que ele nunca pode fazer sozinho antes de decidir o que ele pode. A lista do proibido é curta e você escreve em dez minutos; a lista do permitido nunca fica pronta.
5. Registre a trajetória inteira. Cada requisição enviada e cada resultado como o modelo o recebeu, não a resposta final. Quando falhar, você vai precisar ver o que ele viu.

O item 5 é o que quase ninguém faz no começo e o que todo mundo quer ter no primeiro incidente.

Footnotes

1. Yao et al. (2022) apresentaram o padrão de intercalar pensamento e ação, que virou a estrutura base da maioria dos agentes, e mediram 34 e 10 pontos absolutos de taxa de sucesso acima de métodos de imitação e de aprendizado por reforço em ALFWorld e WebShop. ↩ ↩²

2. Shinn et al. (2023) adicionaram uma etapa de reflexão verbal sobre a falha, guardada num buffer de memória episódica para a tentativa seguinte, sem atualizar os pesos. ↩

3. Schick et al. (2023) mostraram que o uso de ferramenta pode ser aprendido de forma auto-supervisionada durante o treino, a partir de poucas demonstrações por API, em vez de descrito no prompt. ↩