Todos estão perguntando "O que raios é um loop?" Aqui está a pergunta que ninguém está fazendo: o que faz o loop rodar?
O discurso sobre IA convergiu para loops como um primitivo central de sistemas de agentes. Matt Van Horn (@mvanhorn) traçou a linhagem dos loops de agentes do ReAct ao uso de ferramentas, loops de orquestração e loops que supervisionam loops. Addy Osmani (@addyosmani) detalhou os blocos de construção dentro dos loops: automações, árvores de trabalho, habilidades, conectores, subagentes. Van Horn chegou à durabilidade, argumentando que loops que não sobrevivem a uma reinicialização não são loops. O ponto central de Osmani foi a orquestração: projetar o sistema que dá os comandos ao agente em vez de você.
Quero levar seus pontos adiante. Durabilidade não é apenas uma propriedade do loop. É toda a camada de execução subjacente. O fato importante é que a orquestração durável é fundamental para construir sua arquitetura de loop de agente. Vamos detalhar essa arquitetura.
Onde os loops quebram
Os padrões /loop e /goal lidam bem com trabalho de agente único e sessão única. Um agente faz loop até que uma tarefa seja concluída. Isso cobre muita coisa. Mas o próximo estágio (Estágio 5 na definição de Van Horn) é onde tudo desmorona:
- Loops supervisionando outros loops
- Loops rodando em agendamentos, não apenas acionados por um humano
- Loops que sobrevivem a reinicializações de processo, implantações e falhas
- Loops que geram subagentes e esperam pelos resultados (às vezes horas depois)
- Loops que precisam ser observáveis depois do fato
Isso não é um problema de dar comandos. Isso é um problema de infraestrutura.
Van Horn cita @runes_leo: "O item mais caro na programação de IA não é mais escrever código, é gerenciar o loop do agente." Um while true em um terminal não te dá nada disso. Nem um processo de longa duração em uma VM ou sandbox.
Pense no que acontece quando você executa um loop de agente em um servidor. O processo vai morrer ou reiniciar. Uma implantação, um OOM, uma recuperação de instância spot. O loop reinicia. Mas o que ele estava fazendo? Em qual etapa ele estava? Ele já enviou aquela mensagem no Slack? Ele já invocou o subagente?
Você não sabe. Ele começa de novo. Busca novamente dados que já tinha. Chama o LLM novamente para decisões que já tomou. Envia uma notificação duplicada. Gera um subagente duplicado. Você acorda com três mensagens idênticas no Slack e uma equipe confusa.
A correção não é "melhor tratamento de erros" — é um modelo de execução onde cada etapa é registrada, cada decisão é persistida, e a recuperação significa retomar a partir da última etapa bem-sucedida.
A arquitetura do loop de agente em três camadas
Três camadas. Cada uma mapeia para um primitivo concreto.
Camada 1: O Loop
Um loop é um cron mais um tomador de decisão. Ele roda em um agendamento (ou um gatilho), avalia o estado e decide o que fazer em seguida.
Esta é a definição de Van Horn tornada concreta: o que o cron nunca teve é a decisão no meio. O agente decide, não você. O cron é o batimento cardíaco. O LLM é o tomador de decisão. As etapas são a execução durável que registra o progresso.
1export const infraHealthCheck = inngest.createFunction(2 { id: "infra-health-check" },3 { cron: "*/30 * * * *" }, // A cada 30 minutos4 async ({ step }) => {5 const metrics = await step.run("fetch-service-metrics", async () => {6 return await fetchServiceMetrics(); // taxas de erro, latência, memória, CPU7 });89 const assessment = await step.run("assess-health", async () => {10 return await callLLM({11 prompt: `Dadas essas métricas de serviço, classifique a saúde geral do sistema12 como "normal", "degradada" ou "crítica". Explique seu raciocínio.13 Métricas: ${JSON.stringify(metrics)}`,14 });15 });1617 if (assessment.status === "degraded" || assessment.status === "critical") {18 await step.invoke("triage-incident", {19 function: incidentTriage,20 data: { metrics, assessment, services: assessment.affectedServices },21 });22 }23 }24);
Toda segunda-feira às 9h, o loop dispara. Ele busca dados, pergunta ao LLM se um relatório é justificado e invoca uma habilidade se sim. Se o processo reiniciar entre as etapas, as etapas já concluídas não são reexecutadas. Esse é o loop. Não o LLM, o loop ao redor do LLM.
Camada 2: A Habilidade
Neste contexto, uma habilidade não é um comando. É um fluxo de trabalho durável. Multi-etapas, com repetição, componível, implantável de forma independente.
Van Horn: "O loop é o encanamento. O ativo é a habilidade que ele chama." Esta é a parte que se acumula. Cada nova habilidade que o sistema aprende torna cada loop mais capaz.
1export const incidentTriage = inngest.createFunction(2 { id: "incident-triage", retries: 3 },3 { event: "infra.incident.triage" },4 async ({ event, step }) => {5 const details = await step.run("fetch-detailed-metrics", async () => {6 return await fetchDetailedMetrics({ services: event.data.services });7 });89 const deploys = await step.run("fetch-deploy-history", async () => {10 return await fetchRecentDeploys({ since: hoursAgo(2) });11 });1213 const analysis = await step.run("correlate-incident", async () => {14 return await callLLM({15 prompt: `Correlacione essas métricas de serviço com as implantações recentes.16 Identifique a causa raiz provável e a gravidade.17 Métricas: ${JSON.stringify(details)}18 Implantações recentes: ${JSON.stringify(deploys)}`,19 });20 });2122 await step.run("post-triage-summary", async () => {23 await slack.postMessage({24 channel: "#incidents",25 text: formatTriageSummary({26 analysis,27 affectedServices: event.data.services,28 recommendedActions: analysis.recommendations,29 }),30 });31 });3233 return analysis;34 }35);
Esta habilidade busca, classifica e encaminha. É uma unidade de trabalho com tolerância a falhas integrada. A habilidade pode ser um fluxo de trabalho de IA com um LLM no meio ou código determinístico.
Camada 3: O Orquestrador
O orquestrador é o motor que executa tudo: agenda crons, executa etapas, gerencia repetições, aplica limites de concorrência, armazena o histórico de execuções e implanta novas funções/fluxos de trabalho a quente sem interromper os que estão em execução.
Esta é a camada sobre a qual ninguém fala porque ela deveria ser invisível. Mas é fundamental.
A maioria das pessoas pensa em agentes como "LLM + ferramentas." A arquitetura do loop de agente reformula isso como agentes são "loops + habilidades + orquestração." Os LLMs + ferramentas estão dentro dos loops. LLMs e ferramentas podem ser trocados ou ajustados enquanto a arquitetura permanece. A orquestração viabiliza a arquitetura.
O que acontece quando as coisas quebram
O caminho feliz é fácil. Mas este é um software rodando em produção, será que as coisas realmente saem conforme o planejado?
Sua habilidade de triagem de incidentes dispara e a API de métricas atinge o tempo limite. A leitura teve que ir para o disco e o cache em memória não tinha os dados. A etapa que chama esta API agora tenta novamente e acessa a API de novo. Os dados agora estão parcialmente em cache e a API é concluída. A habilidade continua com a próxima etapa como se nada tivesse acontecido.
Às vezes, pode não ser tão simples. E se uma chave de API expirar, ou seu provedor de hospedagem ficar fora do ar por 30 minutos. Todas as suas tentativas de repetição se esgotam. E agora? Você também precisa lidar com as falhas.
1export const incidentTriage = inngest.createFunction(2 {3 id: "incident-triage",4 retries: 3,5 onFailure: async ({ error, event, step }) => {6 // A função falhou após esgotar as repetições.7 // Ainda temos os dados do evento original. Nada foi perdido.8 await step.run("notify-failure", async () => {9 await slack.postMessage({10 channel: "#agent-ops",11 text: `⚠️ A triagem do incidente falhou: ${error.message}. ` +12 `Será repetida no próximo ciclo de verificação de saúde. ` +13 `Serviços afetados: ${event.data.services.join(", ")}`,14 });15 });16 },17 },18 { event: "infra.incident.triage" },19 async ({ event, step }) => {20 /* a mesma lógica da habilidade acima */21 }22);
O manipulador \onFailure\ é acionado após todas as repetições se esgotarem. Ele posta em um canal de operações para que alguém saiba. O evento é preservado, nada é perdido. A próxima execução agendada continua de onde a falha não conseguiu.
A orquestração durável deve fornecer repetições em nível de etapa para erros transitórios e ganchos de tratamento de falhas para erros não recuperáveis. Sem isso, as coisas quebram (como sempre quebram), e você descobre horas ou dias depois.
Erros transitórios também são caros. Se sua habilidade ou agente repetir desde o início, você estará chamando LLMs várias vezes e queimando tokens desnecessariamente. A chamada LLM pode ser registrada. Agora multiplique isso por 10 ou 30 agentes em todo o seu sistema. Isso é caro.
O registro em nível de etapa não é apenas um recurso de correção. É um economizador de dinheiro.
O agente que constrói suas próprias habilidades
É aqui que fica mais interessante. O sistema não é estático, ele é projetado para evoluir e se estender.
O agente não apenas executa dentro de loops — ele cria novos loops e os registra no motor de orquestração. Cada função implantada é uma habilidade durável que roda de forma independente, acionável a partir de um loop ou agente ou rodando em um agendamento, com sua própria lógica de repetição. As habilidades se acumulam.
É um agente com consciência de orquestração.
Aqui está como funciona. Um agente de IA tem acesso ao SDK de orquestração como uma ferramenta. Ele pode escrever novas funções, registrá-las no motor, e elas começam a rodar imediatamente. O processo do agente recarrega novas funções a quente sem reiniciar ou interromper execuções em andamento.
Vamos percorrer um exemplo concreto:
1. Um humano expressa uma necessidade. O engenheiro diz: "Nossos serviços continuam tendo picos de latência durante a noite e ninguém percebe até de manhã." Este é o gatilho. O agente não precisa inferir um padrão vago a partir de dados ambientais. Ele tem instruções claras.
2. O agente escreve uma habilidade. Duas funções de múltiplas etapas: um loop de verificação de saúde que roda a cada 30 minutos, coletando taxas de erro, latência e uso de recursos, com o LLM classificando a saúde do sistema como normal, degradada ou crítica. E uma habilidade de triagem de incidentes que busca métricas detalhadas e histórico recente de implantações, correlaciona causas raiz com um LLM e posta um resumo da triagem no Slack com ações recomendadas. Tratamento de erros: se a API de métricas estiver fora do ar, aguarde e tente novamente. Se o LLM falhar, volte para a classificação de gravidade baseada em regras.
3. O agente implanta a habilidade. O agente escreve o código da função que é capturado por um processo secundário. As novas funções são registradas automaticamente. Elas ficam ativas imediatamente, sem pipeline de implantação, sem PR.
4. A habilidade roda autonomamente. A cada 30 minutos, o motor aciona a verificação de saúde. Se algo estiver errado, ele invoca a habilidade de triagem. Nenhum humano no loop. Totalmente durável.
5. O agente itera com base no sinal. Esta é a parte que as pessoas ignoram, então deixe-me ser específico sobre o que "iterar" significa. O agente não percebe padrões magicamente. Ele tem um loop de revisão separado: uma função acionada por cron que roda semanalmente, lê o histórico de execuções do orquestrador e avalia o desempenho:
1export const reviewSkillPerformance = inngest.createFunction(2 { id: "review-skill-performance" },3 { cron: "0 10 * * 5" }, // Toda sexta-feira às 10h4 async ({ step }) => {5 const runs = await step.run("fetch-run-history", async () => {6 return await getInngestRuns({7 functionId: "incident-triage",8 since: daysAgo(7),9 });10 });1112 const analysis = await step.run("analyze-performance", async () => {13 const successRate = runs.filter(r => r.status === "completed").length / runs.length;14 const avgDuration = average(runs.map(r => r.duration));15 const incidents = await fetchIncidentOutcomes(); // Os incidentes correlacionaram-se com falhas reais?1617 return await callLLM({18 prompt: `Revise o desempenho desta habilidade na última semana.19 Taxa de sucesso: ${successRate}20 Duração média: ${avgDuration}ms21 Incidentes correlacionados com falhas reais: ${incidents.confirmed}/${incidents.total}22 Falsos positivos: ${incidents.falsePositives}23 Equipe agiu com base nos alertas: ${incidents.actedOn}/${incidents.total}2425 Devemos ajustar os limites ou a classificação? Quais mudanças específicas?`,26 });27 });2829 if (analysis.shouldModify) {30 await step.invoke("update-skill", {31 function: coreAgent,32 data: { prompt: `Atualize as habilidades de triagem de incidentes com base nas seguintes mudanças propostas: ${analysis.proposedChanges}` },33 });34 }35 }36);
A "revisão" é uma função. Ela lê o histórico de execuções, verifica se os incidentes se correlacionaram com falhas reais e alimenta esse sinal para o LLM. Se a verificação de saúde continuar sinalizando um serviço como degradado, mas a equipe ignorar porque os limites são muito sensíveis, o loop de revisão captura isso e a habilidade é atualizada para ajustar a classificação. Não é mágica. Um cron job com um LLM no assento de decisão.
E quanto à validação? O agente que escreve código é tão bom quanto as proteções ao seu redor. O código pode ser verificado por tipo. O agente pode invocar a função para testá-la, pois é capaz de interagir com o próprio motor de orquestração. Embora não seja à prova de falhas, você está dando ao agente principal a capacidade de depurar as habilidades que escreve nativamente dentro do sistema em que opera. O loop de revisão captura problemas que não são capturados na depuração inicial.
Levando isso um passo adiante, o agente pode usar ganchos onFailure para acionar a si mesmo para avaliar uma determinada falha. É um loop de feedback que continua melhorando.
E quanto a conflitos? Controles de fluxo, especificamente, controles de concorrência ou singletons lidam com o caso simples (concurrency: \{ limit: 1, key: "[event.data.service" }]), significando que apenas uma triagem de incidente roda por vez por serviço. Mas a questão mais profunda é: e se duas verificações de saúde detectarem problemas no mesmo serviço simultaneamente? O orquestrador as coloca em fila. A segunda triagem espera até que a primeira seja concluída. Sem alertas duplicados, sem condições de corrida. Isso não é teórico. É o mesmo primitivo de concorrência que você usaria em qualquer fila de trabalhos.
O agente não está apenas executando tarefas. Ele está construindo infraestrutura para si mesmo. Cada habilidade durável persiste além da conversa que a criou. Mate o processo do agente e reinicie-o. As habilidades continuam rodando. Troque o modelo subjacente. As habilidades continuam rodando. O agente é efêmero — sua saída é durável.
Visão geral do sistema de arquitetura de loop de agente
A visão do desenvolvedor
Isso é importante porque, se o desenvolvedor não puder ver o que o agente implantou, depurar o que quebrou e auditar o que rodou às 3h da manhã, toda a arquitetura é uma grande responsabilidade.
O motor de orquestração armazena toda execução, cada etapa, cada entrada, cada saída, cada repetição. Uma habilidade que o agente implantou na terça-feira passada e que falhou às 4h? Você pode ver exatamente qual etapa falhou, qual foi a entrada, qual erro foi gerado e quantas vezes repetiu antes de desistir. Rastreamentos completos até o nível da etapa são a saída do próprio motor de orquestração.
Isso não é um painel adicionado depois do fato. É inerente à execução durável. Cada step.run() é um ponto de verificação. Cada ponto de verificação é observável. Quando a coisa que escreveu o código não é um humano, a observabilidade não é um luxo — é a camada de confiança.
No dia a dia, o fluxo de trabalho do desenvolvedor se parece com isto: verificar o painel de execuções pela manhã. Ver quais habilidades rodaram durante a noite, quais tiveram sucesso, quais falharam. Se uma habilidade que o agente escreveu estiver se comportando mal, você pode ler o código diretamente, editá-lo, excluí-lo ou dizer ao agente para corrigi-lo. O agente o criou, mas você é o dono. O agente e suas habilidades ainda são um jardim que você deve cuidar.
Por que a durabilidade é fundamental
Van Horn: "Essas coisas têm que sobreviver a uma reinicialização."
Aqui está o que durabilidade significa na prática:
Requisito
O que significa
Por que o loop while básico falha
Repetição independente de etapa
Se a etapa 3 de 5 falhar, repita a etapa 3, não as etapas 1 e 2
Uma reinicialização do loop reexecuta tudo do zero
Ciclo de vida do subagente
Gerar uma tarefa filha, esperar por ela (talvez horas), cancelar se o pai for cancelado
Nenhum gerenciamento de ciclo de vida pai-filho integrado
Entrega garantida de eventos
Se um evento for disparado enquanto o agente estiver inativo, ele ainda deve ser processado
Eventos são perdidos se o processo não estiver em execução
Observabilidade pós-fato
Ver o que aconteceu depois: cada etapa, cada decisão, cada repetição
Logs são sua única opção, e são efêmeros
Implantação a quente sem tempo de inatividade
Implantar uma nova versão de função sem interromper execuções em andamento
A reinicialização do processo mata tudo
Controle de concorrência
Executar apenas N instâncias de uma habilidade por vez
Nenhum primitivo de concorrência integrado
"Apenas execute em um contêiner" te dá tempo de atividade. Não te dá correção. Um contêiner que reinicia após uma falha traz o processo de volta, mas todo loop em andamento começa de novo. Cada etapa é reexecutada. Cada chamada LLM é refeita. O loop parece estar rodando, mas está rodando às cegas.
Como isso se compara às ferramentas existentes
Algumas ferramentas podem oferecer uma solução "bonita" pronta para este tipo de sistema, ou você pode optar por juntar algumas ferramentas de nível inferior e criar seu próprio sistema. Nenhuma das escolhas é errada, mas a camada de arquitetura certa deve permitir que você e seu agente evoluam ao longo do tempo. Flexível, dinâmico, durável.
Primitivos de execução duráveis que se encaixam bem para um agente, que um agente pode escrever facilmente, e a observabilidade e APIs para observar e permitir que o próprio agente tenha consciência de orquestração.
Um exemplo funcional
Estamos testando esses padrões internamente na Inngest e você pode ver um conceito disso no repositório do projeto "utah" aqui: https://github.com/inngest/utah: É uma estrutura de agente construída sobre a orquestração durável da Inngest que também tem consciência de orquestração.
O sistema tem um processo secundário que permite ao agente principal escrever e editar funções da Inngest em seu próprio espaço de trabalho, estendendo-se com "habilidades" (no contexto deste artigo). Em breve, planejamos fornecer um sistema completo com loops iniciais como exemplos, mas as ideias ali podem demonstrar os conceitos deste artigo de forma mais clara.
O loop de acumulação
A publicação recente de Satya Nadella nomeou algo que a indústria vinha sentindo: o fosso não é o modelo — é o loop.
Sua definição: existem dois tipos de capital. Capital humano, o conhecimento e julgamento que sua equipe construiu ao longo de anos. E o que ele chama de capital de token, os fluxos de trabalho de IA, padrões de decisão e habilidades aprendidas que uma empresa constrói sobre modelos de base.
A tese: estes se acumulam juntos. Cada fluxo de trabalho melhorado gera um sinal melhor. Um sinal melhor produz um comportamento de IA mais nítido. Um comportamento mais nítido libera atenção humana para trabalhos de maior julgamento. Uma máquina de escalada.
Isso é o que a arquitetura do loop de agente viabiliza concretamente:
- Cada habilidade durável que o agente implanta é conhecimento institucional codificado como infraestrutura executável. Ela persiste. Ela roda quer um humano esteja observando ou não.
- Um loop de revisão acionado por cron que avalia o desempenho da habilidade e itera. Essa é a máquina de escalada tornada real. Não um diagrama de volante em uma apresentação. Uma função com um gatilho cron.
- Se suas habilidades morrerem na reinicialização do processo, a acumulação é redefinida para zero. Durabilidade é o que faz o investimento persistir.
O ponto chave de Nadella: "Uma empresa deve ser capaz de trocar um modelo 'generalista' sem perder a experiência de 'veterano da empresa' construída em seu sistema de aprendizado." Esse é o padrão da biblioteca de habilidades. Funções duráveis não se importam qual LLM as chama.
Construa de acordo
A conversa tem sido sobre o que os agentes fazem: loops, ferramentas, raciocínio, engenharia de contexto. A próxima conversa é sobre o que faz os agentes rodarem.
Três camadas: loop, habilidade, orquestrador. O loop é a unidade de trabalho. A habilidade é o ativo. O motor de orquestração é o que torna ambos duráveis. O padrão de processo secundário é o modelo: um agente escreve suas próprias habilidades duráveis, as implanta, revisa como elas se saem e itera. Não é um experimento mental. É um modelo funcional.
Construímos a Inngest para ser o motor de orquestração para isso: step.run(), step.invoke(), gatilhos cron, fluxo de controle orientado a eventos, controles de concorrência e observabilidade completa em nível de etapa. Mas o padrão de arquitetura é maior do que qualquer ferramenta individual. Se você está construindo loops de agente em produção, defina as três camadas.
Os primitivos existem hoje. Construa de acordo.
