Agentes de IA: do prompt único ao loop de planejamento e ação

O salto conceitual dos últimos anos não foi um modelo que responde melhor. Foi um modelo que decide o que fazer em seguida. Essa é a diferença entre um chatbot e um agente, e é uma diferença de natureza, não de grau. No prompt único, o modelo recebe um contexto, produz uma saída e encerra. No agente, a saída de um passo vira a entrada do próximo, e o sistema roda em um loop que só termina quando uma condição de parada é satisfeita. Toda a promessa e todo o problema dos agentes de IA cabem nessa mudança aparentemente inocente: fechar o ciclo.

O prompt único é uma função pura, o agente é um processo

Vale começar pela distinção técnica, porque ela explica o resto. Uma chamada de completions é, na prática, uma função sem estado: você dá um texto, recebe outro, e o modelo não guarda nada. Qualquer memória é ilusão construída por você reenviando o histórico a cada rodada. É previsível justamente porque é curta. O espaço de coisas que podem dar errado é o espaço de uma única geração.

O agente rompe com isso ao introduzir um laço de controle em torno do modelo. Em vez de pedir a resposta final, você pede a próxima ação. O modelo escolhe uma ferramenta, você executa essa ferramenta no mundo real (uma busca, uma chamada de API, um comando de shell, uma escrita em banco), captura o resultado e devolve esse resultado ao modelo como novo contexto. Repete. O modelo deixou de ser o produto e virou o motor de decisão de um processo que se estende no tempo.

Planejar, agir, observar: o loop que muda tudo

O nome do ciclo varia, mas a estrutura é estável. O agente planeja — decide qual é o próximo passo dado o objetivo e o que já sabe. Age — emite uma chamada de ferramenta concreta. E observa — lê o retorno da ferramenta e o incorpora ao seu estado antes de planejar de novo. A linhagem intelectual disso é antiga: é o velho laço sentir-pensar-agir da robótica e do controle, agora com um modelo de linguagem ocupando a caixa de decisão.

O que o modelo de linguagem traz de novo é a capacidade de raciocinar sobre o próximo passo em linguagem natural, em domínios abertos, sem que ninguém tenha codificado a árvore de decisões à mão. É por isso que padrões como intercalar raciocínio explícito com chamadas de ação funcionam: forçar o modelo a verbalizar por que está escolhendo determinada ferramenta, antes de escolhê-la, melhora a qualidade da escolha. A observação, por sua vez, é o único ponto em que o mundo real entra no sistema. Sem ela, o agente é um planejador cego alucinando um ambiente que não existe. Com ela, o agente tem a chance de corrigir rota quando a realidade não bate com o plano.

Esse ponto merece ênfase porque é onde reside quase todo o valor. Um modelo que só planeja é um gerador de listas de tarefas. Um agente que observa de verdade — que lê o stack trace do erro, percebe que o arquivo não existe, nota que a API retornou 403 — pode adaptar. A observação transforma geração de texto em comportamento adaptativo. É a diferença entre escrever um roteiro e improvisar.

Autonomia de longo horizonte é onde a matemática vira contra você

Agora o problema. Um agente útil não dá um ou dois passos; ele encadeia dezenas, às vezes centenas. E confiabilidade sob encadeamento é implacável. Se cada passo tem 95% de chance de estar correto — um número que soaria excelente para uma única resposta — a probabilidade de dez passos consecutivos saírem todos certos é 0,95 elevado a dez, algo em torno de 60%. Estenda para vinte passos e você está abaixo de 40%. A matemática do produto de probabilidades não perdoa: erros não se somam, se compõem. Cada passo adicional multiplica a fragilidade do anterior.

Isso reformula o que entendemos por “horizonte longo”. O gargalo da autonomia estendida não é o agente ser burro demais para planejar cem passos. Modelos atuais planejam cem passos com desenvoltura. O gargalo é que a probabilidade de executar cem passos sem um único erro fatal, num ambiente ruidoso, é baixa — e um único erro fatal no meio de uma cadeia, sem mecanismo de recuperação, contamina tudo que vem depois. O agente age sobre uma premissa falsa que ele mesmo introduziu três passos atrás, e cada nova ação o afunda mais fundo na alucinação.

Some a isso a fragilidade do contexto. O estado do agente vive na janela de contexto, e essa janela é finita e imperfeita. À medida que o loop avança, o histórico incha com retornos de ferramentas, tentativas fracassadas, raciocínios intermediários. Informação relevante do início se dilui. O modelo perde o fio do objetivo original, ou repete uma ação que já falhou porque esqueceu que falhou. Gerência de contexto — o que manter, o que resumir, o que descartar — deixa de ser detalhe de engenharia e vira determinante de sucesso.

Confiabilidade é o gargalo, não a inteligência

Aqui está a tese. O que impede agentes de serem confiados com tarefas econômicas sérias não é falta de capacidade de raciocínio. É falta de confiabilidade ao longo do horizonte. São coisas diferentes, e confundi-las é o erro estratégico mais comum do momento.

Capacidade é o teto do que o sistema consegue fazer no seu melhor dia. Confiabilidade é o piso — o que ele garante fazer sempre, mesmo no pior caso, mesmo quando a ferramenta retorna algo inesperado, mesmo quando o ambiente muda no meio da execução. Uma demo mede o teto. Produção vive no piso. Um agente que resolve a tarefa 90% das vezes é uma demo impressionante e um passivo operacional, porque os 10% de falha em um sistema que age no mundo — que gasta dinheiro, envia mensagens, altera dados — custam caro e exigem um humano vigiando. E se você precisa de um humano vigiando cada passo, você não automatizou nada; apenas trocou o trabalho de executar pelo trabalho de auditar.

É por isso que a fronteira real da engenharia de agentes hoje é menos sobre prompts mais espertos e mais sobre arquitetura de contenção de erro. Verificação de cada passo antes de agir. Capacidade de reconhecer o próprio fracasso e voltar atrás, em vez de seguir em frente sobre destroços. Ferramentas idempotentes, cujo efeito repetido não causa dano, para que um retry seja seguro. Decomposição da tarefa em subunidades curtas o bastante para que a matriz de probabilidades não colapse. Nada disso é glamouroso. Tudo isso é o que separa o protótipo do produto.

Onde o aprendizado por reforço entra — e onde não resolve sozinho

Há uma esperança legítima de que treinar agentes diretamente sobre o loop, e não apenas sobre respostas isoladas, ataque o problema na raiz. Otimizar o modelo pela recompensa da tarefa inteira concluída — não pela plausibilidade de cada token — alinha o incentivo com o que importa. Algoritmos de policy optimization existem justamente para isso: moldar comportamento por consequência, não por imitação.

Mas o reforço não é bala de prata, e por uma razão estrutural. Ele precisa de sinal de recompensa confiável, e em tarefas de horizonte longo o sinal é esparso e ambíguo. Como atribuir crédito a um passo específico numa cadeia de cinquenta, quando só o resultado final é avaliável? O problema de atribuição de crédito temporal, conhecido há décadas, reaparece com força total. Treinar reduz a taxa de erro por passo; não anula a composição exponencial dela. Melhora o piso, não o elimina.

Minha posição

Estamos na fase em que a capacidade dos agentes de IA já ultrapassou nossa capacidade de confiar neles, e essa defasagem, não a inteligência do modelo, é o que define o ritmo real da adoção. As demos vão continuar espetaculares porque medem o teto. A frustração em produção vai continuar porque ela vive no piso. Quem estiver construindo com agentes agora deveria parar de perguntar “o modelo é capaz disso?” — quase sempre é — e começar a perguntar “quantos passos até um erro composto tornar isso um risco?”.

A vantagem competitiva dos próximos anos não vai para quem tem o modelo mais inteligente. Vai para quem projetar os loops mais robustos ao redor dele: horizontes curtos, verificação obsessiva, recuperação de erro embutida, e a humildade de manter o humano no ponto certo do ciclo — não vigiando cada passo, mas guardando as decisões que não podem dar errado. Fechar o ciclo foi a parte fácil. Fazer o ciclo fechar cem vezes seguidas sem quebrar é o problema de engenharia da década.