Loops de agentes de IA: do while ao controle de produção

English summary: A reliable AI agent is not a larger prompt. It is a governed control loop over explicit state, bounded tools, fresh observations, durable checkpoints, retry policies, evidence, and stop conditions. This guide builds the smallest executable loop first, then hardens it with state machines, budgets, deadlines, cancellation, leases, idempotency, human approval, evals, tracing, safety, cost controls, ownership, and reversibility.

Published: July 2026
Reading time: 24 minutes
Keywords: #AIAgents #AgentLoops #LLMEngineering #StateMachines #Evals #Observability #TypeScript

O agente concluiu a tarefa — e o banco ficou com duas cobranças.

Nada “misterioso” aconteceu. A chamada expirou depois de o pagamento ser processado, o loop interpretou silêncio como falha e tentou de novo. O prompt podia ser excelente; o sistema de controle era ruim.

Esta é a tese do guia: um agente confiável não é um prompt que pensa por mais tempo; é uma máquina de estados que transforma objetivo e evidência em ações limitadas, sob orçamento, até uma condição explícita de parada.

Vamos construir primeiro a menor versão que torna essa tese visível. Depois vamos trocar o brinquedo por controles de produção.

Rode o loop mínimo em 60 segundos

Dependências: Node.js 20+ e tsx. Salve como agent-loop.ts:

npm install --save-dev tsx typescript
npx tsx agent-loop.ts

type Phase = 'running' | 'verifying' | 'succeeded' | 'failed' | 'cancelled';
type Action = 'read_spec' | 'apply_patch' | 'run_eval';

type Evidence = {
  source: 'tool' | 'eval';
  claim: string;
};

type State = {
  phase: Phase;
  step: number;
  toolCalls: number;
  facts: string[];
  evidence: Evidence[];
  completed: Action[];
  idempotencyKeys: Set<string>;
  deadlineAt: number;
  cancelled: boolean;
};

const limits = { maxSteps: 6, maxToolCalls: 3 };

function initialState(): State {
  return {
    phase: 'running',
    step: 0,
    toolCalls: 0,
    facts: [],
    evidence: [],
    completed: [],
    idempotencyKeys: new Set(),
    deadlineAt: Date.now() + 10_000,
    cancelled: false,
  };
}

function nextAction(state: State): Action | 'stop' {
  if (!state.completed.includes('read_spec')) return 'read_spec';
  if (!state.completed.includes('apply_patch')) return 'apply_patch';
  if (!state.completed.includes('run_eval')) return 'run_eval';
  return 'stop';
}

function execute(action: Action): { fact?: string; evidence: Evidence } {
  if (action === 'read_spec') {
    return {
      fact: 'VIP customers receive a 15% discount',
      evidence: { source: 'tool', claim: 'spec read before write' },
    };
  }

  if (action === 'apply_patch') {
    return {
      evidence: { source: 'tool', claim: 'patch applied to discount.ts' },
    };
  }

  return {
    evidence: { source: 'eval', claim: 'VIP=15%; regular=0%; regression passed' },
  };
}

function run(): State {
  let state = initialState();

  while (state.phase === 'running' || state.phase === 'verifying') {
    if (state.cancelled) return { ...state, phase: 'cancelled' };
    if (Date.now() >= state.deadlineAt) return { ...state, phase: 'failed' };

    const action = nextAction(state);
    if (action === 'stop') {
      const passed = state.evidence.some(
        (item) => item.source === 'eval' && item.claim.includes('regression passed'),
      );
      return { ...state, phase: passed ? 'succeeded' : 'failed' };
    }

    if (state.step >= limits.maxSteps || state.toolCalls >= limits.maxToolCalls) {
      return { ...state, phase: 'failed' };
    }

    const key = `discount-fix:${action}:v1`;
    if (state.idempotencyKeys.has(key)) return { ...state, phase: 'failed' };

    const result = execute(action);
    const keys = new Set(state.idempotencyKeys).add(key);

    state = {
      ...state,
      phase: action === 'run_eval' ? 'verifying' : 'running',
      step: state.step + 1,
      toolCalls: state.toolCalls + 1,
      facts: result.fact ? [...state.facts, result.fact] : state.facts,
      evidence: [...state.evidence, result.evidence],
      completed: [...state.completed, action],
      idempotencyKeys: keys,
    };

    console.log(`step=${state.step} action=${action} phase=${state.phase}`);
  }

  return state;
}

const finalState = run();
console.log(`final=${finalState.phase} evidence=${finalState.evidence.length}`);

Output esperado:

step=1 action=read_spec phase=running
step=2 action=apply_patch phase=running
step=3 action=run_eval phase=verifying
final=succeeded evidence=3

O exemplo não chama um LLM, não persiste estado e não produz efeito externo. Isso é deliberado. A política nextAction é o lugar que um modelo poderia ocupar; o restante existe para que a decisão do modelo não controle também os limites, a verdade e a parada.

Observe a ordem: ler, alterar, avaliar, parar. A conclusão não nasce da frase “terminei”. Ela nasce de uma transição autorizada por evidência.

A intuição pump: um agente é um controlador de tráfego aéreo

Pense menos em “assistente inteligente” e mais em uma torre de controle.

A torre mantém uma visão do estado, recebe observações, autoriza movimentos e impede duas aeronaves de ocuparem o mesmo recurso. Ela trabalha com janelas de tempo, donos, procedimentos de exceção e confirmação. Uma instrução eloquente do piloto não substitui radar, clearance nem separação.

O agente tem o mesmo problema estrutural:

• o modelo propõe a próxima ação;
• a máquina de estados decide se essa ação é válida agora;
• o contrato da tool limita o efeito possível;
• a observação atualiza o estado com proveniência;
• o avaliador decide se existe evidência suficiente;
• o orçamento, o deadline ou o cancelamento podem encerrar o run;
• um humano assume quando a decisão excede a autoridade delegada.

Em uma frase: o modelo decide dentro do loop; ele não é o loop.

Essa separação também explica quando não usar um agente. A Anthropic distingue workflows, cujos caminhos são definidos em código, de agentes, que dirigem dinamicamente o uso de tools. A mesma publicação recomenda começar pela solução mais simples e aceitar mais latência e custo apenas quando a flexibilidade trouxer ganho mensurável (fonte primária).

Workflow, agente ou nenhum dos dois?

Não promova um workflow a agente porque o diagrama parece mais moderno. Promova quando casos reais exigirem escolha dinâmica e os evals mostrarem vantagem sobre o caminho determinístico.

A máquina de estados é o contrato de controle

Um loop de produção não deveria aceitar transições implícitas. Modele estados terminais, estados pausáveis e a razão de cada mudança.

cancelled não é uma falha transitória. Não faça fallback, retry ou troca de provedor depois de um cancelamento. waiting_human também não é running: o processo deve persistir, liberar recursos quando possível e retomar do checkpoint correto.

Nove invariantes para cada iteração

Máquina de estados diz quais transições são possíveis. Invariantes dizem o que precisa continuar verdadeiro antes e depois de cada transição. Para loops que alteram software, use estes nove gates:

Se um invariante falha, a iteração não “quase passou”. Ela volta a running com uma hipótese nova, vai para waiting_human quando falta autoridade ou termina em failed quando não há recuperação segura. O gate aplicável deve ser definido pelo contrato: um loop editorial pode usar revisão e pipeline de publicação onde um loop de código usa PR e CI.

Estado: registre o suficiente para decidir, não tudo que foi dito

Histórico de chat não é estado operacional. Ele mistura instrução, hipótese, observação, texto irrelevante e possivelmente conteúdo hostil.

Um estado útil separa pelo menos:

Três regras evitam boa parte da corrupção de estado:

1. Output de tool é observação, não verdade automática.
2. Memória recuperada é contexto candidato, não instrução de maior autoridade.
3. Resumos nunca substituem evidência bruta quando uma decisão precisa ser auditada.

O paper ReAct mostrou o valor de alternar raciocínio, ação e observações do ambiente (paper). Para produção, acrescente proveniência, validade temporal e política: o ambiente também pode estar errado, desatualizado ou comprometido.

Observação e memória: retenção tem função e prazo

“Memória” não deveria ser um bucket único.

• Working state: dados necessários para a decisão atual; pequenos e mutáveis.
• Event log: sequência append-only de decisões, chamadas, respostas e transições.
• Checkpoint: snapshot versionado suficiente para retomar com segurança.
• Artifact store: patches, relatórios, arquivos e outputs grandes, referenciados por hash.
• Long-term memory: preferências ou conhecimento reaproveitável, com origem, escopo e expiração.
• Policy memory: regras e permissões; não pode ser rebaixada a texto recuperado pelo modelo.

Antes de inserir memória no contexto, pergunte: quem escreveu, quando, para qual objetivo, com qual confiança e se ainda vale. Antes de persistir, aplique minimização e redaction. O guia de human-in-the-loop do OpenAI Agents SDK documenta serialização e retomada de RunState, e alerta que contexto serializado deve ser tratado como dado persistido, inclusive quanto a segredos (documentação).

Tools são APIs: contratos estreitos vencem descrições criativas

O modelo não deveria adivinhar semântica operacional. Toda tool com side effect precisa declarar:

• schema de entrada e saída;
• pré-condições e pós-condições;
• permissões e owner;
• classe de side effect;
• timeout e deadline herdado;
• comportamento sob cancelamento;
• política de retry por classe de erro;
• chave de idempotência ou justificativa para não tê-la;
• compensação ou procedimento de reversão;
• dados permitidos em logs e traces;
• evidência devolvida.

Uma tool chamada refund é ambígua. create_refund_request com output pending_approval informa intenção, limite e próximo estado.

{
  "name": "create_refund_request",
  "owner": "payments-platform",
  "sideEffect": "write_pending_request",
  "reversible": true,
  "requiresApproval": true,
  "timeoutMs": 30000,
  "retryOn": ["timeout_before_ack", "rate_limited"],
  "neverRetryOn": ["validation_error", "permission_denied"],
  "idempotencyScope": "tenant:order:intent-version",
  "output": {
    "requestId": "string",
    "status": "pending_approval",
    "evidenceRef": "string"
  }
}

A descrição negativa é parte do contrato: “cria solicitação pendente; não movimenta dinheiro”. Guardrails determinísticos devem validar o contrato antes e depois da execução.

Budgets, deadlines e cancelamento são sinais diferentes

Não trate todos como maxSteps.

Um timeout é especialmente perigoso: ele diz que o caller não recebeu confirmação, não que o efeito não ocorreu. Antes de repetir, consulte por idempotency key ou reconcilie o estado externo.

Retry: classifique primeiro, durma depois

Retry sem hipótese apenas repete o acidente. A AWS documenta timeouts, retries, backoff com jitter e a necessidade de tornar retries seguros com APIs idempotentes; a Stripe documenta idempotency keys para evitar a duplicação de operações em tentativas repetidas (AWS, AWS sobre APIs idempotentes, Stripe).

Backoff controla pressão; idempotência controla duplicação; reconciliação resolve resultado desconhecido. São três mecanismos diferentes.

Leases e ownership: um run, um escritor autorizado

Quando workers podem retomar ou disputar a mesma tarefa, uma chave idempotente por tool não basta. Você também precisa saber quem tem autoridade para avançar o estado.

Uma lease deve carregar runId, ownerId, versão/fencing token, acquiredAt, expiresAt e regra de renovação. Cada escrita compara o fencing token atual. Worker com lease expirada pode terminar uma computação, mas não pode publicar o resultado.

Kubernetes usa objetos Lease para coordenação, heartbeats e leader election (documentação oficial). O padrão é útil como referência, mas a implementação do seu agente ainda precisa definir relógio, consistência, renovação, expiração e fencing.

Ownership também precisa existir no plano organizacional:

“O agente decidiu” não é uma linha aceitável de ownership.

Checkpointing: retome o run, não a confusão

Checkpoint seguro acontece depois de uma transição confirmada, não no meio de um side effect desconhecido. Persista:

• versão do objetivo, policy, prompt e tool registry;
• fase e última transição confirmada;
• evidências e artifacts por referência;
• budget consumido e restante;
• attempts e idempotency keys;
• lease/fencing token;
• aprovações pendentes;
• deadline e cancel state;
• hash do checkpoint anterior.

Ao retomar, valide compatibilidade. Uma aprovação concedida para tool:v2 não autoriza silenciosamente tool:v3. A documentação atual do OpenAI Agents SDK descreve RunState serializável para pause/resume e recomenda versionar tarefas pendentes quando definições de agent, tools ou SDK podem mudar (fonte primária).

Human-in-the-loop é uma transição, não uma mensagem no chat

Pare antes da ação sensível. O pedido de aprovação deve conter:

• ação exata e argumentos relevantes;
• motivo e critério que a tornou necessária;
• side effects e blast radius;
• reversibilidade e plano de rollback;
• evidência coletada;
• prazo da aprovação;
• opções approve, reject e modify;
• versão do contrato aprovado.

O OpenAI Agents SDK documenta um fluxo em que tools marcadas para aprovação interrompem o run, o estado é serializado, uma pessoa aprova ou rejeita a chamada específica e o run retoma (documentação). O princípio é mais importante que o SDK: aprovação precisa ser vinculada à intenção, aos argumentos e à versão, não a um “sim” genérico.

Reversibilidade: prefira preparar antes de efetivar

Ordene ações por risco:

1. ler;
2. simular;
3. gerar diff ou plano;
4. escrever em staging/draft;
5. pedir aprovação;
6. efetivar;
7. verificar;
8. compensar se necessário.

Nem todo efeito tem rollback verdadeiro. Um email enviado não pode ser “desenviado”; um segredo exposto não volta a ser secreto. Nesses casos, reduza blast radius antes da ação e trate compensação como mitigação, não viagem no tempo.

Quatro falhas que parecem inteligência, mas são controle ruim

Falha 1 — Parada por narrativa

Sintoma: o agente afirma “concluído”, mas não há eval ou mudança verificável.
Causa: texto final foi aceito como condição de parada.
Diagnóstico: trace termina em output do modelo; não existe verifying → succeeded.
Correção: só o controlador promove succeeded, com assertions sobre evidência.
Artefato preventivo: eval que falha quando sucesso não tem evidenceRef.

Falha 2 — Retry que duplica efeito

Sintoma: dois tickets, cobranças, posts ou patches após timeout.
Causa: retry de escrita sem chave de intenção e sem reconciliação.
Diagnóstico: duas chamadas equivalentes, request IDs diferentes, resultado inicial desconhecido.
Correção: idempotency key estável, lookup por intenção e retry apenas para classe permitida.
Artefato preventivo: teste de contrato que envia a mesma intenção duas vezes e exige um único efeito.

Falha 3 — Dois workers acreditam ser o dono

Sintoma: estado oscila, artifacts se sobrescrevem ou duas ações incompatíveis passam.
Causa: retomada concorrente sem lease/fencing.
Diagnóstico: spans sobrepostos para o mesmo runId, ambos com escrita aceita.
Correção: lease com expiração e fencing token validado em toda mutação.
Artefato preventivo: teste de split-brain em que o worker atrasado perde permissão de commit.

Falha 4 — Run zumbi depois de cancelar

Sintoma: usuário cancela, mas uma tool termina e o agente publica mesmo assim.
Causa: cancelamento não propagado; checkpoint retomado sem revalidar intenção e deadline.
Diagnóstico: cancelledAt anterior ao side effect, sem guardrail na saída.
Correção: cancellation token descendente, verificação antes do commit e estado terminal monotônico.
Artefato preventivo: teste que cancela entre execução e commit e exige zero publicação.

As quatro falhas têm a mesma raiz: o modelo recebeu autoridade que pertencia ao controlador.

Artefato copiável: contrato de execução do loop

Este YAML não depende de framework. Salve como agent-loop-contract.yaml e adapte owners, limites e tools:

apiVersion: agents.example/v1
kind: AgentLoopContract
metadata:
  name: discount-policy-fix
  owner: checkout-platform
spec:
  goal:
    version: 3
    statement: Fix the VIP discount rule without regressions.
    successCriteria:
      - spec_read_before_write
      - targeted_patch_only
      - deterministic_eval_passed
      - release_evidence_emitted
  stateMachine:
    initial: ready
    terminal: [succeeded, failed, cancelled]
    pausable: [waiting_human]
  budgets:
    maxSteps: 12
    maxToolCalls: 8
    maxTokens: 50000
    maxCostUsd: 2.00
    deadlineSeconds: 300
  cancellation:
    propagateToTools: true
    retryAfterCancel: false
    verifyBeforeCommit: true
  concurrency:
    leaseSeconds: 30
    renewEverySeconds: 10
    fencingRequired: true
  checkpoint:
    afterEveryTransition: true
    include: [phase, evidence, budgets, attempts, idempotencyKeys, approvals]
    requireCompatiblePolicyVersion: true
  retry:
    maxAttemptsPerAction: 3
    backoff: exponential_with_full_jitter
    retryOn: [rate_limited, transient_5xx]
    neverRetryOn: [validation_error, permission_denied, policy_block, cancelled]
  tools:
    allow: [read_spec, apply_patch, run_eval]
    sideEffectsRequireIdempotency: true
    productionWritesRequireApproval: true
  safety:
    sandboxByDefault: true
    redactSecretsFromTrace: true
    preferReversibleActions: true
  observability:
    traceFields: [runId, state, action, tool, attempt, latencyMs, costUsd, evidenceRef]
    releaseEvidenceRequired: true
  evals:
    trajectory: [spec_before_patch, no_action_after_cancel, stop_after_success]
    outcome: [discount_policy_passes, regression_suite_passes]

O arquivo só vira governança se runtime e CI rejeitarem violações. Configuração que ninguém aplica é documentação aspiracional.

Evals: avalie resultado, trajetória e controle

Um eval de output pergunta “a resposta está correta?”. Um eval de agente também pergunta “como chegamos aqui?”. A Anthropic descreve tasks, trials, graders e a necessidade de avaliar sistemas multi-turn que usam tools e modificam ambientes (fonte primária).

Construa a suíte em quatro camadas:

Rode múltiplos trials quando a política usa modelo, mas mantenha assertions determinísticas para invariantes. Métricas úteis incluem task success, ações proibidas, retries por classe, tempo até parada, custo por sucesso, handoffs corretos e taxa de reconciliação de resultados desconhecidos.

Não otimize apenas pass rate. Um agente que passa mais vezes porque ignora aprovação está pior.

Tracing: reconstrua decisões sem registrar segredos

Um trace útil permite responder:

• qual objetivo e versão estavam ativos;
• qual estado entrou na decisão;
• qual ação foi proposta, autorizada e executada;
• qual tool/version recebeu quais argumentos redigidos;
• qual observação voltou;
• qual budget foi consumido;
• qual retry, guardrail, aprovação ou cancelamento ocorreu;
• por que o run parou.

OpenTelemetry define traces como caminhos de execução compostos por spans com timestamps, atributos, eventos, links e status (documentação). O guia do OpenAI Agents SDK expõe configuração de tracing e controle sobre a inclusão de dados sensíveis (documentação). Use ambos como referência, mas defina uma taxonomia própria para run, decision, tool, eval, approval e checkpoint.

Observabilidade não significa guardar prompt e output brutos para sempre. Redija segredos, tokenize identificadores quando possível, separe acesso operacional de acesso analítico e defina retenção.

Safety: reduza autoridade e blast radius

Guardrails do modelo ajudam em decisões semânticas; não substituem controles determinísticos.

• allowlist de tools por tipo de tarefa;
• credenciais de menor privilégio e curta duração;
• sandbox para código e arquivos não confiáveis;
• separação entre read, draft e commit;
• limites por tenant, ambiente e recurso;
• aprovação vinculada a argumentos;
• validação de schema antes e depois da tool;
• detecção e redaction de segredos;
• bloqueio de paths e destinos fora do escopo;
• kill switch fora do processo do agente.

O SDK de Agents da OpenAI documenta guardrails de input, output e tool, incluindo tripwires que interrompem a execução (documentação). A regra arquitetural é simples: guardrail precisa alterar o fluxo, não apenas acrescentar um aviso ao prompt.

Custo: meça por resultado aceito

Tokens são só uma parte. O custo de um run inclui inferência, tools pagas, compute de sandbox, armazenamento, tracing, revisão humana, retries e incidentes.

Acompanhe pelo menos:

• custo por tentativa e por sucesso aceito;
• p50/p95 de tempo até estado terminal;
• tool calls úteis versus descartadas;
• retries e reconciliações por classe;
• minutos de revisão humana;
• taxa de runs abandonados, cancelados e expirados;
• custo de coordenação em sistemas multiagente.

Compare com o baseline mais simples. Um agente só vence quando melhora resultado líquido sob as mesmas restrições de risco, não quando gera mais atividade.

Toy vs. produção

O loop mínimo ensina a separação. A versão de produção precisa demonstrar, em testes e operação, que essa separação sobrevive a processo morto, rede ambígua, concorrência, custo, erro humano e mudança de versão.

Checklist de prontidão

Antes do primeiro run

• Objetivo versionado e critérios observáveis definidos.
• Baseline sem agente medido.
• Estados e transições válidas documentados.
• Tools têm owner, schema, permissões, timeout, retry e side effects.
• Ações de escrita têm idempotência ou reconciliação explícita.
• Budgets, deadline e custo são bloqueados fora do modelo.
• Cancelamento chega às tools e é verificado antes do commit.
• Lease/fencing existe quando mais de um worker pode escrever.
• Checkpoint é versionado e compatível com pause/resume.
• Aprovação de alto risco está ligada aos argumentos exatos.
• Evals cobrem outcome, trajetória, controle e falhas injetadas.
• Traces permitem reconstrução sem expor segredos.
• Runbook nomeia owner, alerta, rollback e kill switch.

Antes de declarar sucesso

• Cada critério aponta para evidência verificável.
• O estado externo foi reconciliado após resultados desconhecidos.
• Nenhuma ação ocorreu após cancelamento ou lease expirada.
• Gate determinístico passou.
• Custo e budgets ficaram dentro dos limites.
• Riscos não testados foram declarados.
• Evidência de release registra versões, ações, evals e decisão final.

Exercícios

1. Faça run_eval falhar uma vez com rate_limited. Implemente retry com full jitter, teto de três tentativas e consumo de budget.
2. Persista um checkpoint após cada transição. Mate o processo após apply_patch e retome sem aplicar o patch duas vezes.
3. Execute dois workers para o mesmo runId. Implemente lease com fencing e prove que o worker atrasado não consegue publicar.
4. Cancele o run entre o retorno da tool e o commit. O teste deve provar que o estado externo não muda.
5. Transforme apply_patch em ação de produção que exige aprovação vinculada ao hash do diff. Altere o diff e prove que a aprovação antiga perde validade.

Você aprendeu quando consegue explicar e testar não apenas o que o agente fez, mas quem autorizou, com qual estado, sob quais limites, com qual evidência e por que ele parou.

Critérios de sucesso

Considere o loop pronto para um piloto limitado somente quando:

1. todos os estados terminais são alcançáveis por testes e nenhum deles executa nova tool;
2. todo side effect repetido com a mesma intenção produz no máximo um efeito observável;
3. timeout, rate limit, input inválido, permissão negada e cancelamento seguem políticas diferentes;
4. um checkpoint pode ser retomado após crash sem perder budget, approvals ou idempotency keys;
5. split-brain é bloqueado por lease/fencing;
6. cancelamento vence retry, fallback e conclusão tardia;
7. sucesso exige eval independente e evidência referenciável;
8. traces reconstroem a trajetória sem armazenar segredos proibidos;
9. custo por sucesso e baseline determinístico são comparáveis;
10. owners conseguem executar kill switch, handoff, rollback ou compensação em exercício controlado.

Esses critérios não provam segurança absoluta. Eles provam algo mais útil: que o loop tem contratos falsificáveis e falha de maneira observável.

Síntese

O menor agente é um ciclo: observar, orientar, decidir, agir, verificar e parar. O agente de produção é esse mesmo ciclo cercado por estado durável, tools estreitas, memória com proveniência, budgets, deadlines, cancelamento, leases, checkpoints, retries idempotentes, aprovação, evals, tracing, safety e owners.

Comece pelo while. Depois retire do modelo tudo que não deveria depender de linguagem: autoridade, limites, transições, contabilidade e definição de sucesso.

Autonomia útil não é liberdade para continuar. É capacidade de avançar dentro de um contrato — e parar com evidência.

Fontes primárias

• Anthropic, Building Effective Agents — distinção entre workflows e agents, padrões de composição, feedback ambiental e condições de parada.
• Anthropic, Demystifying Evals for AI Agents — tasks, trials, graders e avaliação de trajetórias multi-turn.
• OpenAI Agents SDK, Running agents — lifecycle do runner, limites de turnos, tracing, erros e integrações de execução durável.
• OpenAI Agents SDK, Human-in-the-loop — interrupções, aprovação/rejeição, serialização, retomada e versionamento de estado pendente.
• OpenAI Agents SDK, Guardrails — guardrails de input, output e tools e tripwires de interrupção.
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models — raciocínio, ação e observação ambiental em trajetórias intercaladas.
• Kubernetes, Leases — coordenação, heartbeats e leader election com objetos Lease.
• AWS Builders’ Library, Timeouts, retries, and backoff with jitter — controle de retries em sistemas distribuídos.
• AWS Builders’ Library, Making retries safe with idempotent APIs — intenção do caller, idempotência e side effects sob retry.
• Stripe, Idempotent requests — contrato de idempotency keys em requests repetidos.
• OpenTelemetry, Traces — traces, spans, eventos, atributos, links e status.

Escopo e validade

• As capacidades específicas de SDKs refletem documentação verificada em 12 de agosto de 2026; revalide versões e defaults antes de implementar.
• O código é didático e local: não prova confiabilidade de modelo, SDK ou infraestrutura externa.
• Os valores de budget do YAML são exemplos, não recomendações universais.
• Leases, idempotência e compensações exigem garantias do armazenamento e do domínio; nomes iguais não produzem semântica correta automaticamente.