Long-Running AI Agents: como construir agentes que trabalham por horas sem perder estado

O loop while do tutorial cabe em um request HTTP. O trabalho que o mercado passou a pedir — refatorar um módulo, conciliar um mês, migrar um pacote de integrações — não cabe. Long-Running AI Agents são a evolução natural dos coding agents e de qualquer fluxo enterprise que atravessa janelas, aprovações e sistemas lentos. Sem arquitetura de duração, você só tem um chat que ainda não tomou timeout.

No harness já descrevemos state machine em vez de while do modelo, budgets, checkpoints, HITL. Este artigo fecha o recorte: o que acontece quando o relógio vai para horas ou dias.

O problema não é o contexto de 1M tokens

Janela grande não é duração. Duração é o processo sobreviver a restart, a troca de modelo, a espera humana de 14 horas, a tool que volta amanhã, a cota que acabou às 18h. Contexto é o pacote de um step. Estado durável é o filme inteiro.

Checkpoints e durable state

A cada transição de estado (PLANNING → WAITING_TOOL → WAITING_APPROVAL), persista o mínimo que permite retomar: plano versionado, ponteiros, idempotency keys, budget restante, hash do contexto. Não persista o transcript eterno como se fosse state — isso é memory/log. Event sourcing ajuda: o log de decisões é a verdade; o snapshot é otimização de replay.

Leases, heartbeats, timeouts

• Lease — um worker possui o run. Outro não “ajuda” em paralelo no mesmo side effect.
• Heartbeat — o dono do lease prova que está vivo. Sem pulso, o run volta à fila.
• Timeouts em camadas — tool, step, run, espera humana. Cada um com desfecho explícito, não hang.
• Human escalation — WAITING_APPROVAL não é sleep infinito; é SLA de fila HITL.

Recovery e idempotência

Crash no meio de um POST sem idempotency key duplica pagamento, ticket, deploy. O artigo-pilar já exigia keys em side effects. Em runs longos a probabilidade de redelivery deixa de ser teórica. Recovery replaya eventos, não “pede ao modelo para lembrar onde parou”.

Budgets que atravessam a noite

Budget de tokens por step e por run. Budget de custo em moeda. Budget de calendar time. Quando estoura: FAILED/BUDGET_EXCEEDED com evidência, não um agente “quase terminando” para sempre. Coding agents de oito horas sem teto são um incidente financeiro esperando o fim de semana.

O que o modelo pode esquecer — e o runtime não

Ao retomar, remonte o pacote de Context Engineering a partir do state + memórias autorizadas. Não recarregue 14 horas de log na janela. Compacte. O agente “acorda” com o plano vigente, o último resultado de tool e as restrições — não com a autobiografia.

async function resume(runId: string) {
  const snap = await state.load(runId);
  if (snap.status === "WAITING_APPROVAL") return enqueueHitl(snap);
  if (snap.leaseExpired) await state.acquireLease(runId, workerId);
  const packet = assembleFromCheckpoint(snap);
  return step(packet);
}

Observability de runs longos

Traces que duram dias precisam de span contínuo ou de encadeamento explícito (parent run). Recovery rate, tempo em WAITING_APPROVAL, heartbeats perdidos, custo acumulado. Sem isso, long-running é caixa-preta cara.

EmerAgents

Na fábrica, modernização e integrações não cabem em um request. EmerAgents trata o run como workflow recuperável: o modelo é o trabalhador de um turno; o harness é o expediente. Isso é o que permite background agents sem transformar o cluster em um cemitério de pods zumbis.

Conclusão

Long-Running AI Agents são workflow engines com um componente probabilístico. Checkpoints, leases, heartbeats, timeouts, recovery, budgets, HITL, idempotência, event sourcing e observability não são “nice to have” — são o produto. Quem vende autonomia de horas sem durable state está vendendo uptime até o próximo deploy.