Cancelamento de tarefas em agentes de IA

O pedido de cancelamento chegou depois da próxima ação

Uma pessoa percebe que o arquivo enviado para análise está errado e clica em cancelar. A interface muda para “cancelando”. O worker continua executando, chama outra ferramenta e grava um resultado baseado no documento incorreto.

O botão registrou uma intenção. A execução nunca recebeu essa intenção em tempo útil, ou recebeu e não sabia onde parar.

Cancelamento de tarefas em agentes de IA é o protocolo que leva uma solicitação de parada até cada parte ativa, impede novo trabalho, trata operações em andamento, libera recursos e confirma o estado final. Ele precisa funcionar entre orquestrador, workers, subtarefas, filas, ferramentas e sistemas externos.

Este recorte é diferente de um kill switch para agentes de IA. O kill switch contém uma função, ferramenta ou serviço diante de risco. O cancelamento organiza o encerramento normal de uma unidade específica que perdeu validade, foi corrigida, superada ou interrompida pelo responsável.

Cancelar, pausar, expirar e terminar cumprem funções próprias

Essas ações não deveriam compartilhar um único status.

Cancelar

Encerra uma execução porque a intenção deixou de valer. O fluxo recebe o sinal, para em pontos seguros, registra o trabalho já feito e trata consequências abertas.

Pausar

Mantém a possibilidade de continuar depois. Estado, prazo e recursos necessários para retomada precisam permanecer disponíveis. Uma pausa não deveria liberar automaticamente outra cópia para executar o mesmo trabalho.

Expirar

Interrompe porque o prazo ou a condição de validade terminou. A expiração pode ser automática, mas deve produzir o mesmo cuidado com efeitos e evidência.

Terminar à força

Corta a execução sem permitir que o código faça limpeza. A documentação da Temporal separa cancellation, que entrega um pedido ao workflow, de termination, que fecha a execução imediatamente e não executa cleanup.

Terminação forçada serve como saída quando o processo não responde. Ela deixa mais trabalho para investigação e reconciliação. Por isso, precisa de autoridade, motivo registrado e procedimento posterior.

O cancelamento precisa atravessar a árvore da execução

Uma tarefa pode criar subtarefas, chamadas, arquivos temporários, reservas e trabalhos em outros serviços. Marcar apenas o registro principal como cancelado deixa partes ativas.

Mapeie a árvore:

workflow principal;
atividades ou jobs;
tarefas filhas;
mensagens em filas;
chamadas ao modelo;
chamadas de ferramentas;
processos externos;
aprovações pendentes;
arquivos e recursos temporários;
retentativas agendadas;
callbacks e webhooks de conclusão.

Para cada ramo, declare:

como recebe o sinal;
quanto tempo pode levar para percebê-lo;
que etapa pode terminar antes de parar;
quais ações ficam proibidas imediatamente;
como confirma o encerramento;
o que exige reconciliação;
quem assume quando o sinal não chega.

Uma tarefa principal cancelada enquanto a filha continua enviando mensagens produz um estado bonito no painel e uma operação ainda ativa.

Use um estado de cancelamento observável

Cancelar raramente acontece num instante. Modele a transição.

Estados úteis incluem:

ativa
cancelamento_solicitado
cancelando
aguardando_operacao_atomica
aguardando_confirmacao_externa
reconciliacao_necessaria
cancelada_sem_efeito
cancelada_com_efeito_parcial
cancelamento_falhou
terminada_a_forca

O pedido deve registrar:

unidade de trabalho;
versão da execução;
solicitante;
motivo;
horário;
autoridade usada;
alcance esperado;
etapa observada no momento;
prazo máximo para parar;
política para tarefas filhas;
decisão sobre efeitos já iniciados.

Esse histórico evita que “cancelado” esconda uma cobrança emitida, um arquivo publicado ou uma atualização ainda sem confirmação.

Coloque pontos seguros entre as etapas

Uma execução precisa consultar o sinal antes de iniciar novo trabalho e em intervalos compatíveis com o risco.

Pontos seguros costumam aparecer:

antes de buscar outro lote;
depois de persistir um checkpoint;
antes de chamar um modelo;
antes de usar uma ferramenta;
antes de gravar em sistema externo;
depois de receber uma confirmação;
entre páginas, arquivos ou registros;
antes de criar tarefa filha;
antes de agendar retentativa;
depois de uma espera ou heartbeat.

Interromper dentro de uma operação atômica pode deixar o objeto inconsistente. Em alguns casos, o worker termina a etapa curta, registra o resultado e para antes da próxima. Essa exceção deve ser delimitada. “Vou terminar o que comecei” não pode autorizar uma sequência inteira depois do cancelamento.

A frequência dos pontos seguros determina o tempo real de resposta. Uma atividade que verifica o sinal a cada cinco minutos pode continuar produzindo trabalho por quase cinco minutos depois do clique.

Heartbeat pode carregar progresso e entregar o cancelamento

Em tarefas longas, heartbeat informa que o worker continua vivo e pode registrar um checkpoint pequeno. Na Temporal, atividades longas recebem o cancelamento por meio do heartbeat. Uma atividade que não envia heartbeat pode continuar até concluir, mesmo depois do pedido.

O heartbeat útil registra apenas o necessário para retomar e decidir:

etapa atual;
último item confirmado;
contadores relevantes;
identificador do checkpoint;
efeitos iniciados;
pendências;
horário;
versão.

A documentação da Temporal recomenda equilibrar frequência e sobrecarga. Heartbeats muito raros atrasam detecção de travamento e propagação de cancelamento. Frequência excessiva cria tráfego sem melhorar a fronteira do trabalho.

O artigo sobre agentes de IA para tarefas longas mostra como dividir a execução em etapas retomáveis. Aqui, o heartbeat também funciona como ponto de observação para encerrar a tarefa.

Cancele antes de iniciar outra consequência

Quando o sinal chega, novas ações externas devem parar. Isso inclui:

envio de mensagens;
atualização de CRM ou ERP;
criação de cobrança;
reserva de agenda;
publicação de arquivo;
alteração de permissão;
criação de tarefa;
disparo de outro workflow.

A verificação precisa ficar perto do dispatcher ou da ferramenta. Um worker pode ter lido o estado como ativo no início e passar vários minutos preparando uma ação. Antes da consequência, consulte novamente a versão e o cancelamento.

Para ações de maior impacto, use uma condição de escrita. A ferramenta recebe a versão esperada da execução e recusa chamadas originadas de uma versão cancelada ou substituída.

Trate operações que já estavam em andamento

Nem toda chamada aceita cancelamento. Uma API pode já ter recebido o pedido. Um modelo pode continuar processando. Um pagamento pode estar em autorização. Uma mensagem pode ter saído para o provedor.

Classifique o estado:

Ainda não enviada

Bloqueie a chamada e marque a etapa como não iniciada.

Enviada e cancelável

Solicite cancelamento ao provedor, guarde o identificador e espere confirmação dentro de um limite.

Enviada e não cancelável

Aguarde ou consulte o resultado. Não repita. Depois, decida se o efeito fica, precisa de compensação ou exige pessoa com alçada.

Resultado incerto

Registre reconciliacao_necessaria e consulte a fonte oficial. Um timeout não prova que a ação falhou.

Concluída

Preserve o efeito confirmado no histórico. Cancelar a execução não apaga a realidade externa.

A reconciliação em agentes de IA ajuda a comparar intenção, registro local, logs e sistema de destino antes de corrigir ou repetir.

Limpeza não significa desfazer tudo

Ao cancelar, o sistema pode precisar:

fechar arquivo temporário;
liberar lock ou lease;
remover credencial efêmera;
cancelar timer;
impedir retentativa;
encerrar sessão;
soltar capacidade reservada;
retirar callback pendente;
preservar logs e checkpoints;
notificar o responsável.

Desfazer um efeito empresarial exige outra análise. Excluir um rascunho local pode ser seguro. Estornar uma cobrança, remover acesso, cancelar reserva ou apagar um registro pede regra própria, autorização e evidência.

A documentação da Temporal destaca que a aplicação escreve o cleanup e decide como desfazer um processo parcialmente concluído. O orquestrador entrega o sinal; a semântica de negócio continua sob responsabilidade do sistema.

Propague a decisão para tarefas filhas

Defina uma política por relação.

Filha faz parte da mesma intenção

O cancelamento costuma propagar. Exemplo: uma análise cria subtarefas para cada documento. Se o caso inteiro foi cancelado, nenhuma filha deveria continuar.

Filha produz um ativo reutilizável

Pode ser permitido concluir um trabalho sem efeito externo, como uma indexação já quase pronta, desde que a política autorize e o resultado não seja publicado automaticamente.

Filha possui responsabilidade independente

Talvez continue. Um registro de auditoria ou uma rotina de limpeza não deve ser cancelado junto com a tarefa que originou o evento.

Filha já criou consequência

Ela entra em confirmação ou reconciliação. Propagar “cancelado” não substitui verificar o destino.

Registre a política no momento da criação. Decidir durante o incidente convida interpretações diferentes entre serviços.

Exemplo: agente que prepara e envia uma proposta

A unidade possui cinco etapas:

reunir dados aprovados;
preparar o escopo;
calcular valores por regra;
gerar o documento;
enviar depois da aprovação.

O cliente altera o pedido durante a geração do documento. O responsável cancela a execução anterior.

Solicitação

O orquestrador grava cancelamento_solicitado, motivo e nova versão do pedido. Novas ferramentas da execução antiga passam a ser recusadas.

Propagação

A atividade de geração percebe o sinal no próximo heartbeat. Ela encerra o arquivo temporário, salva a referência do último checkpoint e devolve cancelamento.

Efeito externo

Nenhum envio foi iniciado. A aprovação anterior fica invalidada porque apontava para outra versão.

Estado final

A execução termina como cancelada_sem_efeito. A nova solicitação nasce com outro identificador e reutiliza somente dados cuja validade foi confirmada.

Se o envio já tivesse sido solicitado e a confirmação estivesse ausente, o estado correto seria aguardando_confirmacao_externa ou reconciliacao_necessaria. Criar outra proposta antes dessa verificação poderia duplicar comunicação.

Cancelamento e filas precisam combinar

Uma mensagem pode voltar à fila depois que a execução foi cancelada. Outra cópia pode já estar em processamento. Uma retentativa pode ter sido agendada antes do pedido.

Para impedir reanimação:

vincule a mensagem à unidade e à versão;
consulte o estado antes de processar;
rejeite versões canceladas;
invalide timers e retentativas;
encerre tarefas filhas ainda não iniciadas;
use idempotência nos efeitos;
confirme mensagens somente quando o tratamento de cancelamento estiver persistido;
mantenha cancelamentos disponíveis por tempo suficiente para cobrir reentregas tardias.

O guia sobre visibility timeout em filas de agentes de IA explica como a posse temporária da mensagem pode vencer durante o processamento. Cancelamento e perda de posse são sinais diferentes, mas ambos retiram autoridade para iniciar consequências.

Erros comuns

Atualizar a interface e deixar o worker ativo

O status visual não interrompe chamadas. O cancelamento precisa chegar ao executor e às ferramentas.

Encerrar o processo sem salvar estado

A equipe perde evidência do que foi feito e não sabe quais efeitos confirmar. Terminação forçada pode ser necessária, mas exige reconciliação posterior.

Executar cleanup destrutivo por padrão

Apagar registros ou reverter transações sem regra pode ampliar o dano. Limpeza técnica e compensação empresarial precisam de políticas separadas.

Esquecer tarefas filhas e retentativas

O workflow principal para, mas jobs derivados continuam. A árvore deve aparecer no registro da execução.

Marcar como cancelado antes de confirmar a parada

Use estados intermediários. cancelamento_solicitado informa intenção; cancelada exige confirmação dentro do alcance definido.

Esperar que toda operação externa seja reversível

Muitas consequências só podem ser compensadas, corrigidas ou comunicadas. O histórico precisa preservar o efeito original.

Teste o caminho de interrupção

Inclua cenários como:

cancelamento antes da primeira etapa;
cancelamento durante chamada ao modelo;
cancelamento entre preparação e escrita;
atividade sem heartbeat;
heartbeat atrasado;
tarefa filha em execução;
retentativa já agendada;
mensagem reentregue depois do cancelamento;
efeito concluído com confirmação perdida;
cleanup que falha;
worker que ignora o sinal;
terminação forçada;
cancelamento repetido;
pedido cancelado e substituído por nova versão;
pausa confundida com cancelamento.

Para cada caso, confira estado final, efeitos, recursos liberados, tarefas filhas, evidência, alertas e autoridade restante.

Métricas para governar cancelamentos

Acompanhe:

cancelamentos solicitados;
tempo até o worker perceber o sinal;
tempo até a confirmação final;
execuções que iniciaram outra ação depois do pedido;
tarefas filhas que permaneceram ativas;
cancelamentos sem efeito;
cancelamentos com efeito parcial;
casos enviados para reconciliação;
cleanup concluído e falho;
terminações forçadas;
mensagens reentregues depois do encerramento;
efeitos duplicados bloqueados;
prazo excedido antes da parada;
motivo operacional do cancelamento;
etapas em que o pedido mais ocorre.

O motivo também informa produto e processo. Muitos cancelamentos por entrada errada podem apontar validação fraca. Cancelamentos tardios podem indicar aprovação colocada depois do ponto de compromisso.

Checklist de cancelamento de tarefas

[ ] A unidade de trabalho possui identificador e versão?
[ ] Cancelar, pausar, expirar e terminar têm estados distintos?
[ ] O sinal alcança workflow, atividades, filas e tarefas filhas?
[ ] Existem pontos seguros antes de novas ações?
[ ] Atividades longas verificam o sinal com frequência adequada?
[ ] Novas ferramentas são bloqueadas depois do pedido?
[ ] Operações em andamento são confirmadas antes de outra decisão?
[ ] Cleanup técnico e compensação empresarial estão separados?
[ ] Retentativas e timers antigos são invalidados?
[ ] Reentregas consultam o estado da unidade?
[ ] O estado final distingue ausência de efeito e efeito parcial?
[ ] Terminação forçada exige autoridade e reconciliação?
[ ] Logs preservam solicitante, motivo, alcance e resultado?
[ ] O caminho foi testado com falhas e tarefas filhas?

Uma tarefa só parou quando a operação consegue provar

Cancelar exige propagação, pontos seguros, bloqueio de novas consequências e tratamento explícito do que já começou. O estado final precisa mostrar quais efeitos ocorreram, quais recursos foram liberados e se ainda existe algo para reconciliar.

Quando esse protocolo está presente, a empresa consegue corrigir uma entrada, substituir uma decisão ou encerrar trabalho vencido sem depender de matar processos e reconstruir a história depois.

Fontes oficiais verificadas em 24 de setembro de 2026: