AgentLoop

O AgentLoop inicia um processo de motor novo para cada worker e cada sessão de crítico, então nenhum histórico de chat anterior os acompanha. Isso evita a deterioração de contexto, o acúmulo de suposições desatualizadas que torna conversas longas pouco confiáveis. A memória durável é o próprio projeto mais as correções concretas que o crítico escreve, o que evita gastar tokens relendo uma conversa que não para de crescer.

Você coloca sua definição de pronto no GUIDELINES.md. Um crítico novo lê esse arquivo a cada ciclo junto com a saída do worker e os arquivos do projeto. A última linha do crítico é um contrato rígido: ela precisa terminar em PASS, FAIL com notas de correção ou CONTINUE. Um FAIL vira instruções injetadas para o próximo worker, então o retorno se transforma em ação, em vez de um comentário que você tem de repassar na mão. Na avaliação do próprio projeto, um crítico novo encontrou um defeito misto de decodificação percentual depois que os nove testes já tinham passado.

O progresso vive no PLAN.md e no STATE.md, não em uma conversa. Um worker lê o plano e o estado, faz um incremento, atualiza o estado e sai. Como a memória está em arquivos, o loop se mantém delimitado e é mais fácil deixá-lo sem supervisão. Isso também significa que você pode ler os mesmos artefatos com que os agentes trabalham e ver exatamente o que mudou em cada passo.

Cada ciclo, veredicto, transcrição, custo e passagem de arquivo aparece em um painel local. Você cancela uma execução por ali, em vez de caçar um processo, e pode pedir o status ao ChatGPT por uma ponte MCP. Sem adivinhação. Para quem já tentou depurar uma execução de agente sem supervisão depois do fato, ter a linha do tempo registrada é a diferença entre corrigir um problema e chutar o que houve.

O AgentLoop roda o CLI do Codex e o Claude Code como motores intercambiáveis. Você escolhe um por loop no painel, ou por tarefa pela ponte. O projeto mantém o planejamento separado da execução local, e o roteiro aponta para perguntas bidirecionais do agente e loops de pesquisa na sequência.

Para projetos dentro de uma árvore de trabalho do git, o checkpoint automático vem ligado por padrão, então o daemon pode commitar o progresso conforme os ciclos terminam. Falhas repentinas, como uma tarefa travada que atinge o limite de tentativas, não apagam o trabalho já feito. Recuperar é um comando do git de distância, não uma tarde perdida. Isso importa nas execuções noturnas.

Um loop é sequencial de propósito. Tarefas independentes enfileiradas podem rodar até um limite de concorrência, mas um loop nunca vira um enxame paralelo correndo pelo mesmo projeto. É deliberado. Os orçamentos também têm teto. O maxCycles vai de 1 a 50 e o padrão é 3, e o taskRetries limita falhas consecutivas antes de uma tarefa ser marcada como bloqueada e ignorada.