Aprovação assíncrona para agentes de IA

A pessoa aprovou, mas o caso já havia mudado

Um agente prepara uma condição comercial e envia o pedido de aprovação. A pessoa responde duas horas depois. Nesse intervalo, o cliente recusou a proposta anterior, o preço mudou e outro vendedor atualizou a oportunidade.

O clique em “aprovar” é válido como registro da decisão recebida. Ele não prova que a ação ainda pode ser executada.

Esse intervalo concentra boa parte do risco da aprovação assíncrona. O fluxo precisa sobreviver à espera, identificar exatamente o que foi aprovado, tratar prazo e substituição, revalidar o estado oficial e impedir que respostas tardias ou repetidas criem efeitos duplicados.

O artigo sobre aprovação humana em agentes de IA ajuda a decidir quais casos exigem intervenção e quem possui autoridade. O guia de tarefas longas para agentes cobre estado, checkpoints e retomada do fluxo inteiro. Aqui, o objeto é mais estreito: o ciclo operacional entre emitir um pedido de aprovação e executar a consequência autorizada.

Modele a aprovação como um objeto próprio

Uma mensagem em e-mail ou chat pode comunicar a solicitação. O estado oficial da aprovação precisa existir fora do canal.

O registro mínimo inclui:

Campo	Função
approval_id	identifica o pedido sem depender da mensagem
work_item_id	liga a decisão à unidade de trabalho
action_type	informa qual consequência está em avaliação
target_ref	identifica cliente, documento, conta ou registro
proposal_version	fixa o conteúdo submetido
proposal_hash	detecta alteração no payload material
requested_by	registra agente, aplicação ou pessoa solicitante
required_role	define a autoridade necessária
assigned_to	aponta o aprovador atual
created_at	inicia o relógio da espera
expires_at	encerra a validade do pedido
status	mostra o estado operacional
decision	preserva aprovação, recusa ou pedido de alteração
decided_by	identifica quem respondeu
decided_at	registra quando a resposta chegou
decision_note	guarda justificativa quando exigida
execution_ref	liga a decisão ao efeito confirmado

A aprovação pertence à versão submetida. Se valor, destinatário, escopo, arquivo ou condição muda, o pedido anterior não deve autorizar o novo conteúdo.

Separe pedido, decisão e execução

Misturar as três etapas num único status chamado aprovado cria ambiguidade.

Pedido

O agente prepara uma ação, registra a versão e solicita decisão. Nenhuma consequência externa ocorre.

Decisão

Uma pessoa autorizada aprova, recusa ou pede alteração. O sistema registra identidade, horário e conteúdo decidido.

Execução

O runtime revalida as condições e tenta a ação. O sistema de destino confirma o efeito com um identificador próprio.

Uma aprovação pode existir sem execução. Isso acontece quando ela vence, o objeto muda, a política é revogada ou a ferramenta fica indisponível. Uma execução também pode ficar com confirmação incerta depois de timeout. O desenho precisa mostrar esses estados sem chamar tudo de sucesso.

Use uma pausa durável

A espera humana pode durar minutos, horas ou dias. Manter uma requisição aberta ou um processo preso em memória deixa a continuidade dependente da infraestrutura.

Uma pausa durável preserva o estado necessário e libera o worker. Quando chega uma decisão ou o prazo vence, o fluxo é retomado a partir do ponto registrado.

O checkpoint da espera deve conter referências pequenas e verificáveis:

• unidade de trabalho;
• pedido de aprovação;
• versão submetida;
• estado anterior;
• ação proposta;
• prazo;
• política aplicável;
• próxima transição permitida.

Documentos completos, segredos e histórico bruto permanecem em armazenamento próprio, com acesso e retenção adequados. O checkpoint aponta para esses objetos em vez de copiá-los sem necessidade.

Defina estados que resistem a respostas tardias

Um fluxo inicial pode usar:

• preparando_proposta;
• aguardando_aprovacao;
• aprovado_pendente_revalidacao;
• recusado;
• alteracao_solicitada;
• expirado;
• substituido;
• cancelado;
• executando;
• executado_confirmado;
• efeito_incerto;
• falhou_sem_execucao.

A resposta só produz transição quando corresponde ao pedido ativo e ao estado esperado. Uma aprovação recebida depois de expirado, substituido ou cancelado entra no histórico, mas não reabre o caso sozinha.

Essa regra também protege contra cliques repetidos, entrega duplicada do evento e respostas de um cartão antigo ainda aberto no celular do aprovador.

Fixe o conteúdo que está sendo aprovado

O aprovador precisa enxergar o objeto material da decisão. “Aprovar proposta” é insuficiente quando existem versões diferentes.

Mostre:

• ação e consequência;
• destinatário ou objeto;
• valores, prazos e condições;
• fonte dos dados principais;
• regra ou alçada aplicada;
• lacunas e conflitos;
• versão do artefato;
• prazo para responder;
• caminho de recusa ou alteração.

No momento da resposta, o sistema confere o identificador e a versão. Se o conteúdo mudou, a decisão deve ser recusada como incompatível e um novo pedido precisa ser criado.

Editar a proposta depois de enviada sem invalidar a aprovação transforma o controle numa assinatura em branco.

Trate prazo como uma decisão empresarial

O timeout técnico da aplicação e a validade da aprovação resolvem problemas diferentes.

O timeout técnico limita quanto uma chamada pode aguardar resposta. A validade informa até quando a decisão continua aplicável ao negócio.

O prazo pode depender de:

• validade de preço;
• disponibilidade de estoque ou agenda;
• janela de contato;
• data do documento;
• fechamento financeiro;
• vigência da política;
• criticidade do caso;
• capacidade do aprovador substituto.

Ao vencer, escolha um caminho explícito:

1. recusar por segurança;
2. escalar para outra autoridade;
3. pedir nova submissão com dados atuais;
4. encerrar sem ação;
5. manter o trabalho preparatório e bloquear somente a consequência.

Aprovação automática depois do silêncio só cabe em situações de baixo impacto e política explícita. Em ações financeiras, contratuais, de acesso ou comunicação sensível, a ausência de resposta costuma exigir bloqueio ou escalonamento.

Aprovar a versão anterior não autoriza enviar a atual

1. 1. Proposta v4 fixada e espera durável

   Registrar pedido, ação, alvo, hash, papel e expiração. Salvar checkpoint e liberar worker; nenhuma consequência externa durante a espera.

2. 2. Receber decisão para o pedido ativo

   Conferir identidade, autoridade, versão e estado. Resposta duplicada não cria nova transição; aprovação válida fica pendente de revalidação.

3. 3. Revalidar CRM e condições atuais

   Reler preço, estoque, entrega, política, destino e ausência de execução anterior. Aprovação autêntica não prova que o objeto continua igual.

4. 4. Substituir por v5 e pedir nova decisão

   Mudança material no exemplo invalida o envio da v4. Preservar a aprovação como histórico e submeter novo conteúdo com outro hash.

5. 5. Executar uma consequência e confirmar

   Se tudo permanece válido, usar chave por pedido, ação e versão. Guardar ID do destino; timeout exige consulta antes de repetir.

6. 6. Histórico sem reabertura automática

   Resposta após expiração, substituição ou cancelamento fica registrada sem liberar ação. Silêncio em consequência sensível exige bloqueio ou escalonamento.

• 1 → 2 Decisão recebida
• 2 → 3 Pedido ativo e resposta válida
• 2 → 6 Pedido vencido, substituído ou cancelado
• 3 → 4 Estoque, condição ou versão mudou
• 4 → 1 Nova submissão reinicia o ciclo com v5
• 3 → 5 Objeto e autorização continuam válidos

Revalide antes de executar

Depois da aprovação, releia as condições que podem ter mudado.

Confirme:

• o pedido continua ativo;
• a versão aprovada é a versão candidata;
• o aprovador tinha autoridade no momento da decisão;
• a política ainda permite a ação;
• o objeto permanece no estado esperado;
• preço, prazo, saldo ou disponibilidade continuam válidos;
• não existe cancelamento ou substituição;
• a identidade do destino continua confirmada;
• a credencial de execução está válida e no escopo;
• a ação ainda não foi realizada por outra pessoa ou rotina.

Se alguma condição material mudou, marque revalidacao_falhou ou estado equivalente. Preserve a aprovação recebida, explique o conflito e prepare nova decisão quando necessário.

A pessoa autorizou uma versão sob determinadas condições. O sistema não deve estender essa autoridade por semelhança.

Controle concorrência entre pessoa e agente

Enquanto o agente espera, alguém pode resolver o caso manualmente. Dois aprovadores substitutos também podem responder quase ao mesmo tempo.

Use operação atômica ou controle de versão para aceitar apenas a primeira transição válida. Antes de executar, compare a versão esperada do objeto com a versão atual.

Exemplos de conflito:

• o vendedor enviou a mensagem manualmente;
• o financeiro alterou a condição;
• outro gestor recusou o mesmo pedido;
• a tarefa foi cancelada;
• o documento recebeu nova versão;
• o cliente encerrou a negociação;
• a aprovação foi escalada e respondida em dois níveis.

O guia de controle de concorrência em agentes de IA detalha versões, reservas e conflitos. Nesta fronteira, o objetivo é impedir que uma decisão válida seja aplicada sobre um estado que deixou de existir.

Torne a execução idempotente

A aprovação libera no máximo uma consequência para aquela unidade e versão.

Crie uma chave estável, por exemplo:

approval_id + action_type + proposal_version

Envie a mesma chave em todas as tentativas quando o destino oferecer idempotência. Registre o identificador retornado. Se houver timeout, consulte o destino antes de repetir.

A resposta perdida depois de uma escrita não deve gerar outra cobrança, tarefa, mensagem ou alteração. O artigo sobre idempotência em agentes de IA aprofunda essa proteção.

Exemplo: desconto comercial

Um agente identifica uma oportunidade com pedido de desconto fora da faixa do vendedor.

Preparação

O sistema reúne produto, quantidade, preço atual, desconto solicitado, margem calculada por regra, validade e histórico autorizado. A saída gera proposal_version = 4.

Solicitação

O pedido é enviado ao gestor comercial com prazo de duas horas. O estado passa para aguardando_aprovacao.

Mudança durante a espera

O estoque disponível cai e a condição de entrega muda. A oportunidade recebe nova versão no CRM.

Resposta

O gestor aprova a versão 4. O sistema registra a decisão e entra em aprovado_pendente_revalidacao.

Revalidação

A versão atual do objeto já não coincide com a versão submetida. O fluxo não envia a proposta. Ele marca o pedido como substituido, explica a mudança e prepara uma versão 5 para nova avaliação.

A aprovação foi autêntica. A execução foi corretamente bloqueada porque o objeto aprovado ficou para trás.

Teste os casos que o fluxo feliz esconde

Inclua no ambiente de teste:

1. aprovação dentro do prazo e execução confirmada;
2. recusa com justificativa obrigatória;
3. pedido de alteração;
4. aprovação depois da expiração;
5. resposta duplicada;
6. dois aprovadores respondendo em concorrência;
7. decisão de pessoa sem papel autorizado;
8. conteúdo alterado depois da submissão;
9. objeto encerrado manualmente durante a espera;
10. reinício do worker antes da decisão;
11. decisão recebida durante indisponibilidade do executor;
12. timeout depois de efeito concluído;
13. cancelamento simultâneo à aprovação;
14. escalonamento respondido pelo aprovador original e pelo substituto;
15. evento com approval_id de outro cliente;
16. tentativa de reutilizar aprovação em nova versão.

O teste passa quando cada caso termina em estado legível, sem consequência duplicada e com evidência suficiente para explicar a decisão.

Métricas para operar aprovações assíncronas

Acompanhe:

• pedidos emitidos por classe de ação;
• tempo até decisão por alçada;
• aprovações, recusas e alterações;
• pedidos expirados;
• decisões tardias recebidas;
• revalidações reprovadas;
• versões substituídas durante a espera;
• respostas duplicadas;
• conflitos entre ação manual e automática;
• aprovações sem execução;
• execuções sem confirmação;
• tempo entre decisão e efeito confirmado;
• casos escalados;
• falhas por aprovador sem autoridade.

Uma fila rápida ainda pode ser ruim se aprova versões antigas sem análise. Uma fila lenta pode ser aceitável quando a ação possui prazo amplo e consequência relevante. Leia tempo junto com validade, correção e efeito final.

Fontes oficiais verificadas em 23 de setembro de 2026

• Approval Pattern, Temporal. A documentação descreve espera por sinal externo, decisão estruturada, timeout, escalonamento e registro do aprovador.
• Human-in-the-loop AI agent, Temporal. O exemplo mostra pausa sem consumo de worker, sinal de aprovação e timer durável.
• Add a human-in-the-loop approval step, Microsoft Learn. A página, marcada como preview, descreve pausa e retomada sob o mesmo identificador de tarefa e recomenda guardar referências pequenas no estado.
• Durable Task Extension for Microsoft Agent Framework, Microsoft Learn. A documentação cobre sessões persistentes, espera longa, aprovação humana e expiração de estado.

Recursos em preview podem mudar. Confirme SDK, versão, limites, armazenamento, comportamento de timeout e suporte da plataforma escolhida antes da implementação.

Checklist antes de liberar

• [ ] A aprovação possui identificador próprio?
• [ ] A unidade, ação, alvo e versão estão fixados?
• [ ] O canal de comunicação está separado do estado oficial?
• [ ] A espera sobrevive a reinício sem manter worker ocupado?
• [ ] Existe prazo empresarial e caminho de timeout?
• [ ] Respostas tardias ficam registradas sem reabrir o caso?
• [ ] O papel do aprovador é validado?
• [ ] Mudanças materiais invalidam o pedido anterior?
• [ ] O estado oficial é relido antes da execução?
• [ ] Concorrência aceita uma única transição válida?
• [ ] A execução usa idempotência e confirmação?
• [ ] Cancelamento, escalonamento e substituição foram testados?
• [ ] O histórico liga pedido, decisão e efeito final?

A retomada precisa confirmar que a decisão ainda cabe

Aprovação assíncrona permite que agentes parem nos pontos de compromisso sem prender infraestrutura nem perder o caso. O ganho depende do que acontece depois da resposta.

Fixe a versão, preserve o estado, trate prazo, rejeite decisões incompatíveis, releia a fonte oficial e execute uma única vez. Assim, o humano decide sobre um objeto conhecido e o agente retoma somente quando a realidade ainda corresponde ao que foi aprovado.