A arte da engenharia de loops (The Art of Loop Engineering)

• Para usar agentes de forma estável em tarefas úteis, um bom modelo não basta; é necessário um harness projetado para o conjunto de tarefas
• O loop de agente mais básico consiste em fornecer contexto ao LLM e chamar ferramentas repetidamente até que a tarefa seja concluída
• A partir daí, agentes mais eficazes são construídos empilhando (stacking) loops de validação, loops orientados a eventos e loops de hill climbing
• Cada camada de loop pode ser instrumentada com primitivas do LangChain, explicadas usando como exemplo um agente de documentação interna
• O verdadeiro potencial não está no modelo em si, mas nos loops construídos ao redor do agente

---

Loop 1: loop de agente

• Um agente é, essencialmente, um modelo que chama ferramentas repetidamente até que a tarefa seja concluída
• O create_agent do LangChain fornece esse loop; ao escolher um modelo e conectar ferramentas (tools), você tem um loop de agente funcional
  • Ferramentas são os elementos que permitem ao agente agir no mundo real
• No exemplo do agente de documentação interna, a primeira etapa do loop recebe uma solicitação de melhoria da documentação; o modelo planeja e rascunha as mudanças e usa ferramentas para clonar o repo, ler arquivos, escrever documentação e abrir um pull request, entre outras ações

Level 2: loop de validação

• O loop de agente executa tarefas, mas nem sempre produz resultados corretos ou consistentes na primeira tentativa; quando a consistência é importante, ele é envolvido por um loop de validação que verifica a saída e, se ela estiver insuficiente, devolve feedback ao modelo
• O loop de validação adiciona um grader para comparar a saída do agente com uma rubrica (rubric) e, em caso de falha, devolver o resultado junto com feedback
  • O grader pode ser determinístico ou do tipo agente, e LLM as a judge é um exemplo típico
  • O RubricMiddleware lida com esse padrão, ou ele pode ser conectado pelo hook after_agent do create_agent
• No exemplo de escrita de documentação, o grader executa testes após cada tentativa para verificar se todos os links funcionam, se todos os checks de CI passam e se o diff ficou limitado ao escopo solicitado, capturando tipos de erro sem revisão manual
• Adicionar validação aumenta a latência e o custo por execução, mas vale a pena na maioria dos usos em produção em que a qualidade é mais importante que a velocidade

Level 3: loop orientado a eventos

• Uma das partes mais importantes do desenvolvimento de agentes é a camada de integrações (integrations layer), que conecta o agente ao ecossistema e permite que ele seja executado em segundo plano
• Um loop orientado a eventos executa o agente quando ocorre um evento, como a chegada de um novo documento, o disparo de uma agenda ou a chegada de um webhook
  • O agente não é algo chamado manualmente, mas um componente que opera continuamente dentro de um sistema maior
• O LangSmith Deployment oferece suporte à infraestrutura de triggers, incluindo cron schedules e webhooks
  • Um exemplo popular de uso de cron são os heartbeats do openclaw, que transformam o agente em um assistente ativo e sempre ligado
• O agente de documentação é executado pelo construtor de agentes no-code Fleet, e os channels e schedules do Fleet lidam com triggers orientados a eventos e por cron
  • Quando uma mensagem chega ao canal Slack #docs-plz, o agente de documentação é executado por meio do canal

Level 4: loop de hill climbing

• Se os três loops anteriores automatizam o trabalho, o quarto loop automatiza a própria melhoria (improvement)
• Toda execução de agente gera um trace que registra o comportamento do modelo, as ferramentas chamadas, o feedback do grader etc.; esse trace contém sinais de alto valor sobre o que funciona e o que não funciona
• O loop de hill climbing executa um agente de análise sobre os traces e, com base no resultado, reescreve a configuração do harness com ajustes melhores
  • Isso inclui ajustes de prompts/ferramentas ou ajustes do grader
  • No LangSmith, esse quarto loop é instrumentado com o agente de análise de traces Engine
• No exemplo do agente de documentação, o engine é executado sobre os traces para detectar problemas; quando vários traces sinalizam um problema potencial, uma issue é aberta solicitando mudanças no prompt ou na ferramenta problemática
• O ponto central é que a seta de retorno não simplesmente volta ao topo; ela entra no sistema e atualiza diretamente o loop de agente, fazendo com que cada ciclo do loop externo torne o loop interno mais eficaz

• Perspectivas futuras

  • A configuração de prompts e ferramentas é a mais fácil de melhorar, mas não é a única opção; equipes que operam modelos open-weight podem conectar o loop de hill climbing ao fine-tuning por RL, usando traces ou resultados de avaliações como sinais de treinamento para melhorar o próprio modelo
  • Contextos auxiliares, como memória e skills recuperadas, também podem ser melhorados da mesma forma; o loop é um padrão, e cabe ao usuário decidir o que otimizar

Supervisão humana e especialização

• Automação não significa remover pessoas do loop; em todas as camadas há pontos em que a supervisão humana agrega valor
  • Um grader automático consegue verificar se links funcionam, mas perceber que o enquadramento está errado para o público-alvo é papel de uma pessoa; julgamentos baseados em contexto, experiência e discernimento são os pontos em que a revisão humana é necessária
• Parte da especialização deve ser codificada nos próprios prompts/ferramentas, mas ações sensíveis, como transações financeiras ou operações em banco de dados, exigem revisão humana em tempo real
• O LangChain facilita instrumentar esses pontos de contato em todos os loops
  • Loop de agente: exigir entrada humana antes de ações sensíveis/chamadas de ferramentas
  • Loop de validação: uma pessoa atua como grader em fluxos de trabalho sensíveis
  • Loop de aplicação: uma pessoa aprova a saída antes de ela ser devolvida ao usuário final
  • Loop de hill climbing: melhorias do harness passam por revisão humana antes do deploy
• Todos os frameworks open-source do LangChain oferecem human in the loop como primitiva de primeira classe

Resumo geral

• Resumo de como os quatro loops se empilham
  • Loop de agente: o modelo chama ferramentas repetidamente até a conclusão da tarefa → automação do trabalho; as primitivas são create_agent e modelos suportados pelo LangChain
  • Loop de validação: pontua a saída com uma rubrica e tenta novamente com feedback em caso de falha → garante qualidade e precisão da tarefa; a primitiva é RubricMiddleware
  • Loop orientado a eventos: eventos disparam execuções de agentes que atualizam sistemas reais → automação de trabalho em grande escala; as primitivas são LangSmith Deployment baseado em triggers cron/webhooks ou Fleet channels
  • Loop de hill climbing: traces de execuções em produção melhoram a configuração do harness por meio de um agente de análise → melhoria do harness; a primitiva é LangSmith Engine
• Isso é o que swyx chama de loopcraft, ou seja, a engenharia de loops na prática; líderes como Steipete, Boris e Andrej chegaram à mesma conclusão de que o potencial dos agentes está nos loops construídos ao redor deles
• Os loops 1 e 2 foram discutidos por muito tempo, mas agora o foco deve se deslocar para os loops 3 e 4, que incorporam agentes ao ecossistema, promovem melhoria contínua com base em critérios e fazem o valor se acumular de forma composta
• Satya destaca os interesses em nível organizacional e observa que empresas que constroem cedo loops de aprendizado nos quais o julgamento humano e o capital em tokens se acumulam de forma composta conquistam uma vantagem difícil de replicar