Engenharia de loops: a habilidade que substituiu silenciosamente a engenharia de prompts

Afinal, o que é engenharia de loops?

Comece pelo que está sendo projetado. Um agente de IA, reduzido à sua essência, é "um LLM em um loop while com ferramentas." Ele recebe uma entrada, o modelo raciocina sobre o que fazer, chama uma ferramenta, observa o resultado, e repete até que a tarefa esteja concluída ou um limite seja atingido. Esse ciclo é o loop do agente de IA, e é o único recurso que separa um agente de um chatbot: um chatbot responde em uma única passagem, um agente persiste e se adapta ao longo de muitas etapas.

Engenharia de loops é a disciplina de tornar esse loop confiável. Como Simon Willison colocou ao batizar a prática:

"Minha definição preferida de um agente LLM é algo que executa ferramentas em um loop para alcançar um objetivo. A arte de usá-los bem está em projetar cuidadosamente as ferramentas e o loop que eles vão usar."

Simon Willison, Designing agentic loops (setembro de 2025)

A forma mais clara de ver onde isso se encaixa é observar como o ofício cresceu em camadas. A engenharia de prompts veio primeiro: escrever uma boa instrução. Depois a engenharia de contexto: curar todo o conjunto de tokens que o modelo vê a cada turno, não apenas o prompt. A engenharia de loops fica acima de ambas, projeta o sistema de runtime ao redor do modelo.

A Anthropic descreve a camada intermediária como "a progressão natural da engenharia de prompts", e a mesma lógica se aplica mais um degrau acima:

"Um agente rodando em loop gera cada vez mais dados que podem ser relevantes para o próximo turno de inferência, e essas informações precisam ser refinadas ciclicamente."

Anthropic, Effective context engineering for AI agents

Ou seja, a relação não é competitiva, é aninhada. A engenharia de prompts otimiza uma única chamada. A engenharia de contexto otimiza o estado que o modelo vê a cada turno. A engenharia de loops otimiza a maquinaria que decide se o agente sequer chega a um bom estado. Se você já leu nosso artigo sobre engenharia de prompts, este é o próximo andar.

Por que o loop virou a alavanca, e não o prompt

Durante boa parte de 2023 e 2024, a coisa mais inteligente que se podia fazer era aprender a conversar com o modelo. Isso funcionava porque os modelos respondiam em uma única passagem. No momento em que passaram a rodar em loops, chamar ferramentas e agir ao longo de várias etapas, o prompt deixou de ser o gargalo. O que mais provavelmente quebra um agente hoje não é uma instrução mal formulada, é um loop sem interruptor de desligamento, sem estratégia de memória, ou sem forma de checar o próprio trabalho.

Solomon Hykes, o fundador da Docker, capturou o perigo em uma frase que todo o setor cita hoje:

"Um agente de IA é um LLM destruindo seu ambiente em loop."

Solomon Hykes, via Simon Willison (AI Engineer World's Fair, junho de 2025)

Esse é o reenquadramento. Um modelo mais poderoso em um loop mal projetado é mais perigoso, não menos, porque executa suas más ideias com mais competência. A comunidade de profissionais entendeu isso rápido. No Hacker News, uma das publicações mais votadas sobre o tema tem o título direto de "The canonical agent architecture: a while loop with tools", e outro tópico popular sobre a eficácia desproporcional de um loop de agente LLM está cheio de gente surpresa com o quão bem um loop simples funciona quando o arcabouço ao redor está certo.

A LangChain resumiu isso em uma equação clara: Agente = Modelo + Harness.

"Engenharia de harness é como construímos sistemas ao redor dos modelos para transformá-los em motores de trabalho. O modelo contém a inteligência e o harness torna essa inteligência útil."

LangChain, The anatomy of an agent harness

Chame de engenharia de loops, engenharia de harness, ou codificação agêntica (os rótulos ainda estão se acomodando), a ideia é a mesma: se você não é o modelo, você é o loop, e é no loop que a engenharia agora vive.

As cinco alavancas de um loop bem projetado

Ao percorrer quem está definindo esse campo, Willison, Anthropic, LangChain, Thoughtworks, o loop se decompõe sempre no mesmo punhado de alavancas. Estes são os botões que você realmente gira.

1. Ferramentas (a interface agente-computador). O que o agente pode realmente fazer. A Anthropic passou mais tempo otimizando ferramentas do que o prompt em seu trabalho com o SWE-bench, e cunhou o termo ACI (interface agente-computador), o equivalente do agente a uma UI. Willison prefere comandos de shell simples para agentes de codificação porque "agentes de codificação são muito bons em executar comandos de shell."
2. Condições de parada. Quando o loop tem permissão para encerrar, por sucesso, por um limite máximo de iterações, por um limite de orçamento, ou quando detecta que não está progredindo. Um loop sem lógica de encerramento ou declara vitória cedo demais ou nunca para. Anthropic: "também é comum incluir condições de parada (como um número máximo de iterações) para manter o controle."
3. Gestão de contexto. O que sobrevive entre os turnos. As técnicas aqui são a compactação (resumir e recomeçar perto do limite da janela), a anotação (um NOTES.md que o agente mantém fora do seu contexto), e subagentes que consomem dezenas de milhares de tokens cada, mas retornam um resumo enxuto de 1.000 a 2.000 tokens. O motivo disso importar: a capacidade de recordar se degrada à medida que a contagem de tokens cresce, então é preciso curar ativamente (veja nossa nota sobre o tamanho da janela de contexto).
4. Verificação. Como o loop prova que realmente fez a coisa. Essa é a alavanca mais repetida de todas. Willison diz que o valor de um agente de codificação "é amplamente potencializado por uma suíte de testes boa e que passa de forma limpa." O harness da Anthropic para agentes de longa duração usa uma lista de recursos em JSON com mais de 200 recursos de ponta a ponta, cada um inicialmente marcado como passes: false, de modo que o agente não pode marcar um recurso como concluído sem provar isso.
5. Barreiras de proteção. O que impede o loop de causar danos. Sandboxes, credenciais estritamente delimitadas, e orçamentos. Willison deu ao Claude Code sua própria organização na Fly.io com um orçamento de US$ 5 para que um loop descontrolado não pudesse gastar dinheiro de verdade.

Quando um agente se comporta mal, a solução é quase sempre uma dessas cinco, não um prompt reescrito. Aqui está o diagnóstico rápido a que recorro:

Engenharia de loops, mas para o suporte ao cliente

Aqui está a parte que a maior parte da cobertura focada em codificação deixa passar. A versão mais clara do trabalho de um loop engineer no mundo real não é construir uma CLI de codificação, é rodar um agente de IA em uma fila de suporte real, e digo isso como alguém que constrói esses agentes para viver.

Um ticket de suporte é um loop quase perfeito. O agente percebe a mensagem recebida, raciocina sobre a intenção, recupera o que precisa (histórico de pedidos, documentação, estado da conta), executa uma ação (um reembolso, uma redefinição, uma atualização de ticket), verifica o resultado, e então resolve ou transfere para um humano. A Anthropic destaca o suporte como "um encaixe natural para agentes mais abertos" justamente porque o trabalho precisa tanto de conversa quanto de ação, com um sucesso que "pode ser claramente medido por resoluções definidas pelo usuário."

E cada uma das cinco alavancas se traduz em uma decisão de suporte com a qual os compradores se importam mais do que percebem. Passamos os últimos três anos e meio colocando agentes de IA em filas de suporte reais, e o que decide se um lançamento funciona nunca é a esperteza do prompt. É o loop. A versão mais afiada disso que já ouvi veio de uma líder de CX de uma marca de suplementos DTC no Gorgias e Shopify, rodando cerca de 7.000 tickets por mês, que nos disse em uma ligação:

"A IA nunca vai conseguir responder 100% das perguntas... Eu preciso de uma IA que só lide com os tickets nos quais ela tem confiança e deixe todos os outros em paz."

Isso é um requisito de engenharia de loops em linguagem simples. "Só lide com aquilo que você tem confiança" é uma condição de parada e uma barreira de proteção fundidas em uma só, e foi o único recurso que decidiu a compra deles. Um bot que tenta responder tudo parece impressionante em uma demo e silenciosamente destrói a confiança em produção. Esse é o mesmo padrão de falha por trás da maioria dos problemas de chatbots de IA: sem portão de confiança, então ele responde quando não deveria. É também a linha que separa um agente de verdade de um chatbot baseado em regras, que não consegue fazer esse julgamento de forma alguma.

A alavanca de verificação tem um análogo exato no suporte. Em codificação, você verifica com uma suíte de testes. No suporte, você verifica simulando o agente contra seus próprios tickets passados antes de ele sequer tocar um cliente, observando o que ele teria dito, onde a cobertura é fraca, e o que ele erra. Esse é o equivalente, no mundo do suporte, à disciplina da Anthropic de "200 recursos, todos passes: false", e é por isso que construímos a simulação dentro do agente de helpdesk da eesel em vez de pedir que as equipes descubram isso ao vivo.

Os números confirmam por que a engenharia importa. Em um relatório de referência de 2026, a Notch coloca os chatbots tradicionais entre 10 e 25% de resolução, e as plataformas agênticas (aquelas que "se conectam diretamente a sistemas de CRM, faturamento e sinistros e executam") entre 70 e 85% de resolução de ponta a ponta. A lacuna não é a qualidade do modelo, todos os níveis podem chamar os mesmos modelos de ponta. A lacuna é se alguém projetou o loop ao redor deles. A frase mais afiada do relatório é uma dica de compra: a pergunta honesta a se fazer a um fornecedor é "não qual é a taxa de resolução dele, mas o que ele conta como resolvido."

Você também pode ajustar esse loop em linguagem simples em vez de código, e é essa parte que torna a engenharia de loops acessível a uma equipe de suporte, e não apenas a engenheiros.

Construir o loop você mesmo, ou usar um que já está pronto

Depois que você enxerga a automação de suporte como engenharia de loops, a questão de construir versus comprar fica mais clara. Você pode construir o loop sozinho sobre a API crua da Claude ou da OpenAI, muitas equipes técnicas fazem isso, e os artigos de boas práticas do Claude Code são um ótimo lugar para aprender o ofício. Mas o harness é a parte difícil, e é a parte que você precisa continuar mantendo. O próprio trabalho da Anthropic com agentes de longa duração envolveu uma lista de verificação com mais de 200 recursos, orquestração de subagentes, e lógica de compactação, e isso é só para manter um agente de codificação nos trilhos. Um loop de suporte em produção acrescenta roteamento por confiança, tratamento multilíngue, regras por tipo de ticket, e transferência limpa para humanos.

Um líder de engenharia de uma empresa de hardware cripto, com uma base de conhecimento de mais de 300 artigos, resumiu a conta depois de decidir comprar:

"Poderíamos ter tentado escrever nossa própria aplicação de LLM, mas não queríamos investir nosso tempo nisso. Queríamos algo que não precisássemos manter."

Karel, líder de engenharia na GENERAL BYTES (cliente da eesel)

Essa é a verdadeira troca. O loop agora é o produto, então a pergunta é se você quer ser quem o projeta e mantém, ou se prefere comprar um loop já projetado para o caso de suporte. Se você está avaliando essa segunda opção, nosso panorama do melhor software de helpdesk com IA, o conjunto de exemplos de agentes de IA, e nossa seleção dos melhores agentes de IA são um bom mapa de quem já fez esse trabalho de engenharia e o quão bem.

Experimente a eesel

A eesel AI é, no enquadramento deste post inteiro, um loop que já está projetado para o suporte. Você a conecta ao seu helpdesk (Zendesk, Freshdesk, Gorgias, Help Scout, e mais de 100 outros), e ela aprende com seus tickets e documentos passados desde o primeiro dia. As cinco alavancas já vêm prontas para o caso de suporte: a simulação contra seus tickets históricos é a etapa de verificação, o roteamento baseado em confiança é a condição de parada, e as ações delimitadas somadas às exclusões por tipo de ticket são as barreiras de proteção, tudo configurável em linguagem simples em vez de código.

É por isso que uma equipe como a Gridwise viu a eesel resolver 73% das solicitações de nível 1 no primeiro mês, com o loop rodando supervisionado a princípio e ganhando autonomia conforme a simulação provava que era seguro. Você obtém o loop projetado, e a verificação para confiar nele, sem precisar montar e manter o seu próprio. Você pode começar de graça e simulá-lo contra o seu próprio histórico de tickets antes que um único cliente o veja.