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:

recusar por segurança;
escalar para outra autoridade;
pedir nova submissão com dados atuais;
encerrar sem ação;
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.

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:

aprovação dentro do prazo e execução confirmada;
recusa com justificativa obrigatória;
pedido de alteração;
aprovação depois da expiração;
resposta duplicada;
dois aprovadores respondendo em concorrência;
decisão de pessoa sem papel autorizado;
conteúdo alterado depois da submissão;
objeto encerrado manualmente durante a espera;
reinício do worker antes da decisão;
decisão recebida durante indisponibilidade do executor;
timeout depois de efeito concluído;
cancelamento simultâneo à aprovação;
escalonamento respondido pelo aprovador original e pelo substituto;
evento com approval_id de outro cliente;
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.