Engenharia de Loops: por que criar bons agentes de IA vai muito além de escrever prompts

Durante meus estudos sobre Inteligência Artificial, agentes e análise de dados, comecei a perceber uma coisa:

Um bom prompt pode gerar uma boa resposta. Mas uma boa resposta ainda não é um processo confiável.

Imagine que você peça para uma IA:

“Analise esta planilha e crie um dashboard.”

Ela pode produzir algo interessante. Porém, algumas perguntas continuam sem resposta:

• A planilha contém dados sensíveis?
• Os cálculos estão corretos?
• Os filtros realmente funcionam?
• A IA preservou o arquivo original?
• Como ela decidiu que o trabalho estava pronto?
• O que acontece quando encontra um problema?

Foi estudando essas questões que conheci o conceito de Engenharia de Loops, ou Loop Engineering.

Em vez de apenas entregar uma instrução e esperar pelo resultado, nós criamos um processo no qual o agente executa, verifica, corrige e tenta novamente até alcançar uma condição clara de sucesso.

Um prompt pede. Um loop acompanha até o resultado.

Um prompt tradicional pode funcionar assim:

Usuário → Pedido → IA executa → Resposta

Já um loop adiciona uma etapa essencial: a verificação.

Um exemplo prático: da planilha ao Data Viewer

Para entender melhor, imagine uma situação comum: uma empresa envia uma planilha e precisa transformar aqueles dados em informações úteis para tomar decisões.

Em um prompt tradicional, eu poderia simplesmente pedir:

“Analise esta planilha e crie um Data Viewer.”

O problema é que receber uma resposta não significa que o trabalho foi realmente concluído com qualidade. A planilha pode conter dados sensíveis, informações duplicadas, campos vazios ou cálculos incorretos.

Com a Engenharia de Loops, o processo se torna mais seguro e verificável.

Primeiro, o agente preserva o arquivo original e cria uma cópia de trabalho. Depois, identifica e protege dados sensíveis, verifica a qualidade das informações e cria um schema.md, que funciona como um mapa da base de dados.

Em seguida, ele realiza a análise e constrói o Data Viewer. Mas o trabalho ainda não termina: o agente precisa testar os indicadores, conferir os cálculos e verificar se os filtros apresentam os resultados corretos.

Se algum critério falhar, ele identifica o problema, realiza a correção e executa novamente a validação. A entrega acontece somente quando todos os testes forem aprovados ou quando o limite de tentativas for alcançado e for necessária uma revisão humana.

O fluxo abaixo representa esse processo:

Esse exemplo mostra que um loop não é apenas uma sequência automática de tarefas. Ele é um ciclo de execução, verificação e melhoria, criado para que o agente consiga demonstrar, por meio de evidências, que o resultado realmente funciona.

O que aprendi construindo esse exemplo

Ao desenhar esse processo, percebi que a parte mais difícil não é dizer ao agente o que ele deve fazer.

O verdadeiro desafio é definir como ele poderá provar que fez tudo corretamente.

Por exemplo, dizer que o schema.md precisa estar “bem feito” ainda é muito subjetivo. Para transformar isso em um critério verificável, precisei definir que ele deve documentar:

• O nome e a descrição de todas as colunas.
• O tipo de cada dado.
• As regras de transformação aplicadas.
• A existência de valores ausentes ou duplicados.
• A classificação de privacidade das informações.
• Quais campos podem ser utilizados como filtros ou indicado

A mesma lógica vale para o Data Viewer. Não basta dizer que ele deve estar “bonito” ou “funcionando”. O agente precisa testar se os filtros retornam os valores corretos, se os indicadores correspondem aos cálculos da planilha e se nenhuma informação sensível aparece na interface.

Foi aí que comecei a entender uma ideia importante:

Quanto mais clara for a definição de “pronto”, mais confiável será o trabalho do agente.

Autonomia também precisa de limites

Outro aprendizado foi perceber que um agente autônomo não deve tentar resolver tudo sozinho.

No meu exemplo, ele pode identificar um e-mail ou CPF e aplicar uma regra de anonimização conhecida. Porém, deve interromper o processo quando não conseguir determinar se uma informação é sensível ou quando uma transformação puder mudar o significado da análise.

Também é necessário estabelecer um limite de tentativas.

Se o agente repetir o processo diversas vezes sem conseguir reconciliar os cálculos, continuar tentando pode apenas consumir mais tempo e recursos. Nesse momento, o melhor resultado não é inventar uma solução, mas registrar o problema e solicitar uma revisão humana.

Por isso, defini que o loop deve encerrar quando:

• Todos os critérios forem aprovados.
• O limite máximo de tentativas for atingido.
• Duas tentativas consecutivas não apresentarem melhoria.
• Existir algum risco relacionado à privacidade ou à integridade dos dados.

Essa combinação de autonomia com limites torna o processo mais seguro e previsível.

Como começar sem complicar

Uma das recomendações que mais fizeram sentido para mim foi começar pela solução mais simples.

Nem toda tarefa precisa de vários agentes, automações ou processos complexos. Primeiro, podemos escolher uma atividade pequena e responder:

1. O que inicia o trabalho?
2. O que o agente deve fazer?
3. Como o resultado será verificado?
4. O que significa estar concluído?
5. Quantas vezes ele pode tentar?
6. Quando uma pessoa precisa intervir?

Depois, executamos um primeiro piloto, observamos onde o processo falha e transformamos esse aprendizado em uma nova regra para as próximas execuções.

Em vez de criar imediatamente um agente que faça toda a análise de dados, por exemplo, posso começar com um loop menor:

Receber uma planilha, criar uma cópia segura, identificar dados sensíveis e produzir um relatório de qualidade.

Quando essa etapa estiver funcionando de maneira confiável, posso adicionar o schema.md, a análise, os insights e, por último, o Data Viewer.

Minha conclusão até aqui

Antes de conhecer a Engenharia de Loops, eu pensava principalmente em como escrever uma instrução melhor para a IA.

Agora, também penso em como construir um processo no qual ela consiga:

• Executar uma tarefa.
• Verificar o próprio resultado.
• Corrigir os problemas encontrados.
• Tentar novamente dentro de um limite.
• Apresentar evidências do que foi validado.
• Reconhecer quando precisa de ajuda humana.

Ainda estou aprendendo e desenvolvendo esse projeto, mas já consigo enxergar como essa abordagem pode ajudar na criação de agentes de análise de dados, relatórios automáticos e ferramentas de apoio à tomada de decisão.

Um bom prompt pode gerar uma resposta interessante.

Um loop bem construído pode transformar essa resposta em um processo repetível, verificável e mais confiável.

E na sua rotina: qual tarefa poderia deixar de ser apenas um prompt e se transformar em um loop?