A Arquitetura de Loop de Agentes

Todo mundo está perguntando "Mas o que é um loop, afinal?" Eis a pergunta que ninguém está fazendo: o que executa o loop?

O discurso sobre IA convergiu para os loops como um primitivo central dos sistemas de agentes. Matt Van Horn (@mvanhorn) traçou a linhagem dos loops de agente desde ReAct até uso de ferramentas, loops de orquestração e loops supervisionando loops. Addy Osmani (@addyosmani) detalhou os blocos de construção dentro dos loops: automações, árvores de trabalho, habilidades, conectores, subagentes. Van Horn destacou a 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: projete o sistema que dá instruções ao agente em vez de você.

Quero levar esses pontos adiante. Durabilidade não é apenas uma propriedade do loop. É toda a camada de execução abaixo dele. 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 formulação de Van Horn) é onde tudo desmorona:

• Loops supervisionando outros loops
• Loops executando em horários agendados, não apenas acionados por um humano
• Loops que sobrevivem a reinicializações de processos, implantações e falhas
• Loops que geram subagentes e aguardam resultados (às vezes horas depois)
• Loops que precisam ser observáveis posteriormente

Isso não é um problema de criação de prompts. É um problema de infraestrutura.

Van Horn cita @runes_leo: "A coisa mais cara 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. Um processo de longa duração em uma VM ou sandbox também não.

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 estava? Já enviou aquela mensagem no Slack? 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 solução não é "melhor tratamento de erros" — é um modelo de execução onde cada etapa é registrada (checkpoint), 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 executa 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 minutos
4  async ({ step }) => {
5    const metrics = await step.run("buscar-metricas-servico", async () => {
6      return await fetchServiceMetrics(); // taxas de erro, latência, memória, CPU
7    });
8
9    const assessment = await step.run("avaliar-saude", async () => {
10      return await callLLM({
11        prompt: `Com base nessas métricas de serviço, classifique a saúde geral do sistema
12                 como "normal", "degradada" ou "crítica". Explique seu raciocínio.
13                 Métricas: ${JSON.stringify(metrics)}`,
14      });
15    });
16
17    if (assessment.status === "degraded" || assessment.status === "critical") {
18      await step.invoke("triagem-incidente", {
19        function: incidentTriage,
20        data: { metrics, assessment, services: assessment.affectedServices },
21      });
22    }
23  }
24);

Toda segunda-feira às 9h, o loop é acionado. 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. Isso é o loop. Não o LLM, o loop em torno do LLM.

Camada 2: A Habilidade (Skill)

Neste contexto, uma habilidade não é um prompt. É um fluxo de trabalho durável. Multietapas, passível de repetição, composá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("buscar-metricas-detalhadas", async () => {
6      return await fetchDetailedMetrics({ services: event.data.services });
7    });
8
9    const deploys = await step.run("buscar-historico-implantacoes", async () => {
10      return await fetchRecentDeploys({ since: hoursAgo(2) });
11    });
12
13    const analysis = await step.run("correlacionar-incidente", async () => {
14      return await callLLM({
15        prompt: `Correlacione estas 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    });
21
22    await step.run("publicar-resumo-triagem", 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    });
32
33    return analysis;
34  }
35);

Esta habilidade busca, classifica e encaminha. É uma unidade de trabalho com tolerância a falhas embutida. 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 as execuções em andamento.

Esta é a camada sobre a qual ninguém fala porque deveria ser invisível. Mas é fundamental.

A maioria das pessoas pensa em agentes como "LLM + ferramentas." A arquitetura de loop de agente reformula isso: agentes são "loops + habilidades + orquestração." O LLM + 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 isso é software rodando em produção; será que tudo realmente sai como planejado?

Sua habilidade de triagem de incidente é acionada e a API de métricas expira. 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 por 30 minutos. Todas as suas repetições se esgotam. E agora? Você também precisa lidar com 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("notificar-falha", async () => {
9        await slack.postMessage({
10          channel: "#agent-ops",
11          text: `⚠️ Triagem de 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 serem esgotadas. Ele publica 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 parou.

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 acontece), 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 do LLM pode ter checkpoint. Agora multiplique isso por 10 ou 30 agentes em todo o seu sistema. Isso é caro.

O checkpoint 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 é executada de forma independente, acionável a partir de um loop ou agente, ou executando em um agendamento, com sua própria lógica de repetição. As habilidades se acumulam.

É um agente consciente da orquestração.

Veja 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 ser executadas 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 ambientes. Ele tem instruções claras.

2. O agente escreve uma habilidade. Duas funções multietapas: um loop de verificação de saúde que executa a cada 30 minutos, extraindo 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 incidente que busca métricas detalhadas e histórico de implantações recentes, correlaciona causas raiz com um LLM e publica um resumo da triagem no Slack com ações recomendadas. Tratamento de erros: se a API de métricas estiver fora, aguarde e tente novamente. Se o LLM falhar, recorra à classificação de gravidade baseada em regras.

3. O agente implanta a habilidade. O agente escreve o código da função que é captado por um processo sidecar. As novas funções são registradas automaticamente. Elas entram no ar imediatamente, sem pipeline de implantação, sem PR.

4. A habilidade é executada 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 executa semanalmente, lê o histórico de execuções do orquestrador e avalia o desempenho:

1export const reviewSkillPerformance = inngest.createFunction(
2  { id: "revisar-desempenho-habilidade" },
3  { cron: "0 10 * * 5" }, // Toda sexta-feira às 10h
4  async ({ step }) => {
5    const runs = await step.run("buscar-historico-execucoes", async () => {
6      return await getInngestRuns({
7        functionId: "incident-triage",
8        since: daysAgo(7),
9      });
10    });
11
12    const analysis = await step.run("analisar-desempenho", 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?
16
17      return await callLLM({
18        prompt: `Revise o desempenho desta habilidade na semana passada.
19                 Taxa de sucesso: ${successRate}
20                 Duração média: ${avgDuration}ms
21                 Incidentes correlacionados com falhas reais: ${incidents.confirmed}/${incidents.total}
22                 Falsos positivos: ${incidents.falsePositives}
23                 Equipe agiu sobre alertas: ${incidents.actedOn}/${incidents.total}
24
25                 Devemos ajustar os limites ou a classificação? Quais mudanças específicas?`,
26      });
27    });
28
29    if (analysis.shouldModify) {
30      await step.invoke("atualizar-habilidade", {
31        function: coreAgent,
32        data: { prompt: `Atualize as habilidades de triagem de incidentes com base nas seguintes alterações 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 continua sinalizando um serviço como degradado, mas a equipe ignora porque os limites são muito sensíveis, o loop de revisão capta 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 escrevendo código é tão bom quanto as proteções em torno dele. O código pode ser verificado quanto ao tipo. O agente pode invocar a própria função para testá-la, pois ele pode interagir com o próprio motor de orquestração. Embora não seja à prova de balas, você está dando ao agente principal a capacidade de depurar as habilidades que ele escreve nativamente dentro do sistema em que opera. O loop de revisão capta problemas que não são captados na depuração inicial.

Levando isso um passo adiante, o agente pode usar hooks onFailure para se autoacionar e 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 (concorrência: { limit: 1, key: "[event.data.service" }]), significando que apenas uma triagem de incidente é executada 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 termine. 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 tarefas.

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 sendo executadas. Troque o modelo subjacente. As habilidades continuam sendo executadas. 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 importa porque, se o desenvolvedor não consegue ver o que o agente implantou, depurar o que quebrou e auditar o que foi executado às 3h da manhã, toda a arquitetura é um grande passivo.

O motor de orquestração armazena cada 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 da manhã? Você pode ver exatamente qual etapa falhou, qual foi a entrada, qual erro foi lançado e quantas vezes ela tentou novamente 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 posteriormente. É inerente à execução durável. Cada step.run() é um checkpoint. Cada checkpoint é observável. Quando a coisa que escreveu o código não é um humano, a observabilidade não é um bônus — é a camada de confiança.

No dia a dia, o fluxo de trabalho do desenvolvedor se parece com isso: verifique o painel de execuções pela manhã. Veja quais habilidades foram executadas durante a noite, quais tiveram sucesso, quais falharam. Se uma habilidade que o agente escreveu está se comportando mal, você pode ler o código diretamente, editá-lo, excluí-lo ou dizer ao agente para corrigi-lo. O agente a escreveu, 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 precisam sobreviver a uma reinicialização."

Aqui está o que durabilidade significa na prática:

"Apenas execute em um contêiner" te dá disponibilidade. 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 recomeça. Cada etapa é reexecutada. Cada chamada de LLM é refeita. O loop parece estar sendo executado, mas está executando às cegas.

Como isso se compara às ferramentas existentes

Algumas ferramentas podem oferecer uma solução "elegante" pronta para uso para este tipo de sistema, ou você pode optar por juntar algumas ferramentas de nível inferior e criar seu próprio sistema. Nenhuma escolha está errada, mas a camada de arquitetura correta 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 seja consciente da 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: É um harness de agente construído sobre a orquestração durável da Inngest que também é consciente da orquestração.

O sistema tem um processo sidecar 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 que se acumula

A publicação recente de Satya Nadella nomeou algo que a indústria vinha sentindo: o fosso não é o modelo — é o loop.

Sua formulação: existem dois tipos de capital. Capital humano, o conhecimento e julgamento que sua equipe construiu ao longo dos 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: eles se acumulam juntos. Cada fluxo de trabalho melhorado gera um sinal melhor. Um sinal melhor produz um comportamento de IA mais preciso. Um comportamento mais preciso libera a atenção humana para trabalho de maior julgamento. Uma máquina de subida de colina.

Isso é o que a arquitetura de loop de agente viabiliza concretamente:

• Cada habilidade durável que o agente implanta é conhecimento institucional codificado como infraestrutura executável. Ela persiste. Ela é executada 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 subida de colina 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, o acúmulo é redefinido 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 de 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 executa os agentes.

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 sidecar é 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 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 única. Se você está construindo loops de agente em produção, defina as três camadas.

Os primitivos existem hoje. Construa de acordo.