Assíncrono ou Nada: o playbook do CTO para orquestração durável de agentes em 2026

Seu stack web foi construído para CRUD de 200 ms. Seus agentes precisam de 2–20 minutos de retries, callbacks e aprovações humanas. É por isso que sistemas de agentes em produção travam, cobram clientes em duplicidade ou vazam tokens. O HN está certo: todos os seus agentes vão para o assíncrono. A questão é se você fará isso de forma deliberada.

Este é um playbook prático para CTOs: como projetar orquestração assíncrona durável para agentes de IA — idempotente por padrão, observável e com custo previsível. Baseia-se nas lições por trás de dois temas que dominaram os feeds da semana: “Todos os seus agentes estão indo para o assíncrono” e os post-mortems sobre o que o async prometeu vs. o que entregou. Se você lidera um time de produto hoje, não tem trimestres para experimentar. Você precisa de um blueprint que consiga implementar em 30–90 dias.

Comece com uma taxonomia de workloads (não com uma ferramenta)

Antes de comprar um motor de workflow, rotule seu trabalho. Agentes de IA ampliam quatro classes distintas de execução. Cada classe empurra você para uma escolha arquitetural diferente.

• Classe A — I/O curto (≤5s): Chamadas únicas de API, consultas a vetores, invocações leves de ferramentas. Mantenha síncrono via HTTP. Proteja com timeouts e retries no cliente.
• Classe B — Tarefas médias (5–60s): I/O em múltiplas etapas, computação leve, fan-out para algumas ferramentas. Use fila + workers com semântica at-least-once e chaves de idempotência.
• Classe C — Tarefas longas (1–30 min): Loops de agente, backoffs em múltiplas APIs, aprovações humanas. Use um mecanismo de workflow durável (Temporal/Step Functions/Durable Functions) ou um coordenador de sagas caseiro com checkpoints de estado e heartbeats.
• Classe D — Muito longas / com estado (30 min–dias): Crawls de pesquisa, negociações multiagente, enriquecimento em lote. Use um motor de workflow + armazenamento durável para checkpoints, etapas human-in-the-loop e retomada após deploys.

Sua primeira decisão é mapear features para classes. Se >30% do seu roadmap é Classe C/D, você vai ultrapassar cron + filas ad hoc rapidamente. Se seu trabalho é 90% Classe B, um stack enxuto com SQS/Redis + workers e padrão outbox/inbox vence orquestradores pesados em simplicidade e custo.

Semântica de entrega: escolha seu veneno desde o começo

Agentes são estocásticos. Redes falham. Exactly-once em escala é conto de fadas. Escolha effectively-once e implemente sem piedade.

• Filas at-least-once: SQS, Pub/Sub, Kafka vão reentregar. Projete cada etapa para ser idempotente.
• Chaves de idempotência: Gere uma chave estável por intenção do usuário (ex.: hash de input + ferramenta + versão). Persista um registro tombstone com status e checksum da resposta. Rejeite duplicatas dentro de uma janela de dedupe limitada (ex.: 24–72 horas).
• Padrão outbox/inbox: Para mutações no banco, escreva a intenção em uma tabela de outbox na mesma transação da mudança de estado. Envie com um relay para a fila. No consumidor, escreva em uma tabela de inbox antes de processar para deduplicar reentregas.
• Compensações em vez de rollbacks: Use o padrão saga. Quando uma etapa posterior falhar, agende uma ação compensatória (reembolso, revogar token, excluir arquivo), não um rollback de banco que você não consegue aplicar a sistemas externos.

Times que adotam idempotência na borda cortam efeitos colaterais duplicados em >95% na prática. Sem isso, sua fila de suporte vira seu serviço de dedupe.

As opções de orquestração que realmente chegam à produção

Existem mil frameworks. Poucos sobrevivem às restrições reais de produção (tarefas de vários minutos, backpressure, observabilidade, passos mistos humano/automatizado).

Opção 1: Fila + workers DIY (SQS/Redis/Kafka)

• Quando usar: ≤20 tipos de tarefa, fluxos ≤5 etapas, majoritariamente Classe B. Você precisa de velocidade e eficiência de custo.
• Como: SQS ou Pub/Sub para enfileiramento, um outbox/inbox em Postgres para dedupe, workers em ECS/Kubernetes, dead-letter queues (DLQs) com alarmes.
• Prós: Barato e simples. SQS custa ~$0,40 por milhão de requisições; 10M jobs/mês ≈ $4 em operações de fila.
• Contras: Sem etapas humanas nativas, sem visibilidade gráfica dos fluxos, você constrói seus próprios retries, políticas de backoff e IDs de correlação.

Opção 2: Serviços gerenciados de workflow (AWS Step Functions, Azure Durable, GCP Workflows)

• Quando usar: Fluxos de 10–100 etapas, mix de tarefas curtas e longas, necessidade de estado visual, integrações de serviço e SLAs.
• Como: Modele os fluxos como estados. Use task tokens para callbacks e heartbeats para trabalhos longos. Abrace sub-workflows para chamadas paralelas de ferramentas.
• Prós: Durável, depuração visual, backoff embutido. Step Functions Standard custa $0,025 por 1.000 transições de estado; 10M transições ≈ $250/mês. Integra-se nativamente com serviços AWS.
• Contras: Dependência do fornecedor, ergonomia de DSL em JSON, variantes express cobram por GB-second e podem disparar com payloads pesados, história limitada para dev local.

Opção 3: Temporal (ou Cadence) para execução durável

• Quando usar: >100 tipos distintos de tarefa, human-in-the-loop, workflows versionados que você pode reexecutar de forma determinística, deploys frequentes sem perder progresso.
• Como: Escreva workflows em código (Go/Java/TypeScript/Python). O Temporal cuida de retries, timers, heartbeats, replays e persistência de estado.
• Prós: “Escreva código bloqueante, obtenha assíncrono durável.” Reexecuções determinísticas permitem depuração com “viagem no tempo”. Cancelamentos e padrões de compensação robustos.
• Contras: Superfície operacional se self-hosted (Cassandra/Postgres + serviços de matching/history). Você precisa de disciplina de engenharia na versionagem de workflows.

Regra prática: se você tem dois ou mais de 1) aprovações humanas, 2) etapas que ultrapassam 15 minutos, 3) precisa retomar em voo após deploys, 4) 50+ atividades distintas, escolha um motor de workflow. Caso contrário, mantenha enxuto com filas.

Egress seguro: trate o HTTP do agente como pagamentos em produção

Agentes chamam a internet. Isso amplia o raio de impacto. As manchetes do mês sobre vazamentos de OAuth e variáveis de ambiente devem servir de alerta. Trate o HTTP de saída como perigoso até prova em contrário.

• Egress zero-trust: Direcione todo HTTP de agentes por um proxy que imponha uma allowlist por domínio e esquema. Negue por padrão. Para ferramentas dinâmicas, use tokens de egress assinados e de curta duração, com escopo e limites de taxa.
• Raias de proteção com LLM-as-judge: Um proxy “juiz” pode pontuar ou redigir prompts/respostas para remover segredos e PII antes de as requisições saírem da sua VPC. Não é sua única linha de defesa, mas reduz vazamentos por prompt injection.
• Higiene de segredos: Nada de tokens de longa duração em variáveis de ambiente. Use credenciais por workflow, com escopo temporal, vindas de um cofre (AWS STS + Secrets Manager, HashiCorp Vault) com rotação automática. Passe credenciais por referência, não por valor.
• RBAC para ferramentas: Toda ferramenta tem uma role de serviço. Mapeie as capacidades do agente para roles, não para chaves brutas. O princípio do menor privilégio é obrigatório quando agentes compõem ferramentas.

Backpressure, timeouts e retries conscientes de custo

Retries são onde as contas morrem. Seu cálculo de retry deve ser guiado por orçamento, não por esperança.

• Backoff exponencial com jitter: Comece em 250–500 ms, multiplique por 2, limite em 30–60 segundos, adicione ±20% de jitter para evitar thundering herds.
• Orçamentos de retry: Defina um orçamento máximo de compute por intenção do usuário (ex.: 30 segundos de CPU, 3 minutos de wall time, $0,02 de gasto em LLM). Abandone ou escale para humano quando esgotar.
• Profundidade da fila sinaliza capacidade: Workers escalam para cima quando a profundidade > N mensagens ou a idade > T segundos. Reduza lentamente para evitar oscilação.
• Rate limits por endpoint: Mantenha token buckets no cliente por API externa para honrar SLAs do fornecedor e evitar banimentos de conta.

Observabilidade para humanos, não só para máquinas

Se seu time não consegue responder “onde está este job e por que está preso?” em 60 segundos, você não tem observabilidade — você tem logs. Construa ferramentas de primeira classe.

• IDs de correlação fim a fim: Um ID por intenção, propagado por HTTP, mensagens de fila e etapas de workflow. Indexe por ID em logs e traces.
• Heartbeats e liveness: Tarefas longas devem enviar heartbeats a cada 10–60 segundos. Mate e reorquestre em heartbeats perdidos após uma janela de tolerância.
• Higiene de DLQ: Dead-letter queues não são cemitério. São fila paginada e triada. Agregue automaticamente por causa raiz e exponha botões de remediação (retry, compensar, escalar) no seu console interno.
• SLAs e SLOs por classe: Publique percentis 50/95/99 por classe de workload. Metas típicas que funcionam: Classe B 95º ≤ 10s, Classe C 95º ≤ 5m, Classe D limitada por etapa humana, com timers para nada apodrecer.

Modelos de custo concretos que você consegue defender para Financeiro

Custo é onde async ganha ou perde credibilidade. Aqui vão referências usando preços públicos em 2026. Ajuste para sua região e free tiers.

Fila + workers (exemplo AWS)

• SQS: ~$0,40 por 1M de requisições. 10M mensagens/mês ≈ $4.
• Compute (exemplo Lambda): 10M jobs a 256MB por 5 segundos cada = 10.000.000 × 5s × 0,256 GB = 12.800.000 GB-segundos. A ~$0,00001667/GB-s, ≈ $213. Some taxas de requisição e alguma folga; arredonde para $230.
• Total estimado: ~$234/mês mais banda de egress e storage. Se seus jobs rodam mais ou precisam de containers, orce de acordo (nós de ECS/K8s, autoscaling).

Motor de workflow (Step Functions Standard)

• Transições de estado: $0,025 por 1.000. Para um workflow de 10 etapas executado 1M de vezes/mês: 10M transições ≈ $250.
• Compute das tasks: Mesma conta acima para Lambda ou tasks em containers.
• Total estimado: $250 para orquestração + compute. Para human-in-loop, você acrescenta storage de estado e um DB modesto (~$50–$200/mês).

Temporal

• Self-hosted: Infra é mais pesada (banco de dados + serviços). Espere baixo cinco dígitos/ano em infra e tempo de operações quando estiver em escala (>100M execuções de atividades/ano).
• Cloud: Preços de vendor variam por volume de execuções e storage; pode sair mais barato que trabalho humano se você precisa de replay determinístico e fluxos complexos. O ROI está na redução de defeitos e na velocidade de desenvolvedor, não no custo bruto de compute.

Teste de sanidade: se você gasta mais reprocessando falhas e fazendo limpezas manuais do que com orquestração, você está subinvestido em async.

Human-in-the-loop que não trava o mundo

Agentes falham de maneiras sutis — campos de API alucinados, updates parciais, violações de política. Aprovações humanas devem ser assíncronas, de alto sinal e com tempo máximo.

• Aprovações cronometradas: Toda etapa manual tem um timer (ex.: 15 minutos). No timeout, auto-aprove usando um threshold de risco ou auto-rejeite com ação compensatória.
• UIs de revisão enxutas: Construa um painel único mostrando o prompt, chamadas de ferramentas, diffs das mudanças propostas e um clique para aprovar/negar com captura de motivo.
• Amostragem: Comece com 100% de revisão para ações arriscadas. Reduza para 5–10% de amostragem conforme suas métricas estabilizam e a taxa de falso negativo cai.

Testes e deploys: determinismo ou nada

A maioria dos bugs de agentes “funciona na minha máquina”, mas falha após um deploy ou um retry. Você precisa de determinismo onde importa.

• Workflows reexecutáveis: Prefira engines que possam reexecutar decisões. Se for DIY, faça snapshot do estado nas fronteiras de etapa e suporte reexecução a partir da etapa N com os mesmos inputs.
• Testes baseados em propriedades para ferramentas: Para cada ferramenta externa, gere inputs perturbados e faça asserts de efeitos colaterais. Capture IDORs, lacunas de rate limit e auth faltante cedo — um tema recorrente à medida que APIs geradas por IA chegam mais rápido do que o AppSec consegue revisar.
• Canary em mudanças no orquestrador: Versione seus workflows. Rode canários (1–5%) antes do corte total. Execuções antigas devem terminar nas versões antigas; novas começam nas novas.

Um plano pragmático de 30-60-90

Dias 0–30: Classifique, contenha e estanque o sangramento

• Faça inventário de todos os fluxos de agentes. Rotule como Classe A–D. Desenhe um diagrama de swimlanes com ferramentas e egress por etapa.
• Implemente chaves de idempotência nas bordas de API. Adicione uma tabela de outbox. Ative DLQs com paginação.
• Introduza um proxy de egress simples com allowlist. Movimente segredos para um cofre e rotacione quaisquer chaves de longa duração.

Dias 31–60: Suba execução durável para Classe C/D

• Escolha seu orquestrador: Step Functions/Durable se você está all-in na nuvem; Temporal se precisa de fluxos nativos na linguagem e replay.
• Migre os dois fluxos mais ruidosos. Adicione heartbeats, IDs de correlação e aprovações humanas com timers. Instrumente percentis 50/95/99.
• Defina orçamentos de retry e rate limits por endpoint. Ajuste backoff e autoscaling de workers com base na idade da fila, não em CPU.

Dias 61–90: Torne isso entediante

• Construa um console interno de “Jobs”: pesquisável por ID de correlação, com controles de retry/compensar/escalar.
• Escreva um playbook para triagem de DLQ e revisões semanais. Rastreie as 3 principais causas raiz e elimine-as.
• Endureça a segurança: expanda a allowlist de egress, imponha roles por ferramenta, habilite redação de prompt/resposta no proxy.

E as equipes nearshore?

Times distribuídos na verdade se beneficiam do assíncrono durável: um time em São Paulo repassa para um time em New York com os mesmos IDs de correlação, dashboards e semântica de retry. Você ganha 6–8 horas de sobreposição, mais 16–18 horas/dia de progresso, já que trabalhos longos continuam com segurança enquanto os times dormem. A troca: você precisa investir em observabilidade e remediação com um clique para que ninguém fique espeleologando logs às 3 da manhã.

Antipadrões comuns para matar agora

• Long polling sobre HTTP por minutos: Isso ocupa infraestrutura e convida timeouts. Use callbacks ou webhooks com task tokens.
• Salvar estado do modelo em memória entre etapas: Um deploy vai matar isso. Persista checkpoints em um store (S3, Postgres) e passe referências.
• Retries globais em SDKs de cliente: Retries pertencem ao lado servidor com orçamentos e visibilidade, não escondidos nos defaults do SDK.
• Variáveis de ambiente como “secret store”: Vazamentos via logs e inspetores de ambiente da plataforma. Use um cofre e credenciais de curta duração.

Considerações finais

Async não é estilo. É a única forma de entregar recursos agentic que sobrevivem à realidade — instabilidade de rede, APIs flakey, aprovações humanas, deploys e o ocasional colapso do modelo — sem tacar fogo no dinheiro. A resposta certa raramente é uma plataforma novinha em folha. É uma taxonomia afiada, idempotência, uma fila entediante onde der e um motor de workflow de verdade onde for preciso. Bem feito, seus agentes viram colegas confiáveis, não máquinas caras do caos.

Principais aprendizados

• Classifique workloads A–D antes de escolher ferramentas; filas para Classe B, motores de workflow para C/D.
• Adote effectively-once com chaves de idempotência e padrões outbox/inbox.
• Proteja o egress com proxy de allowlist, credenciais com escopo e curta duração e, opcionalmente, um LLM juiz.
• Use orçamentos de retry, heartbeats, DLQs e IDs de correlação para tornar falhas baratas e visíveis.
• Modele custos: filas custam centavos por milhão de operações; motores de workflow adicionam ~ $25 por 1M de transições.
• Versione workflows e habilite replay/canários; aprovações devem ser temporizadas e mínimas.
• Equipes nearshore ganham continuidade se houver observabilidade e remediação com um clique.