Deadline em agentes de IA: como propagar o prazo

A resposta venceu, mas as subtarefas continuam trabalhando

Um agente recebe dez minutos para preparar um briefing antes de uma reunião. Ele consulta o CRM, busca documentos, chama um modelo, tenta novamente uma integração lenta e delega uma pesquisa a outra execução.

Aos dez minutos, a interface informa timeout. O problema parece encerrado. Nos bastidores, a pesquisa continua consumindo recursos, a integração ainda tenta gravar uma atualização e uma resposta antiga pode chegar depois que a equipe já tomou outra decisão.

Esse comportamento aparece quando cada componente conhece apenas o próprio timeout. A execução principal possui um prazo, mas as chamadas filhas recebem janelas novas e independentes. O trabalho técnico sobrevive à utilidade empresarial.

Uma deadline registra o instante máximo em que a unidade ainda pode avançar. Propagar essa deadline significa carregar o prazo original, ou um prazo menor, por todas as chamadas, ferramentas, filas, agentes filhos e retentativas. Cada etapa calcula quanto tempo resta antes de iniciar trabalho novo.

O objetivo é impedir três falhas concretas:

subtarefa começando sem tempo para terminar;
retentativa que ultrapassa o prazo da unidade;
efeito externo chegando depois que a intenção perdeu validade.

O que esta página acrescenta ao orçamento de latência

O guia sobre latência em agentes de IA mostra como definir tempo total, distribuir orçamento por etapa, acompanhar percentis e escolher rotas degradadas. A propagação de deadline resolve uma fronteira mais estreita: como fazer o prazo total acompanhar a execução quando o trabalho atravessa várias chamadas.

O artefato final também muda.

Um orçamento de latência diz quanto cada parte deveria consumir. A política de deadline define:

qual instante governa a unidade inteira;
como esse instante chega a cada dependência;
quanto uma chamada filha pode usar;
quando novas tentativas deixam de ser admitidas;
como o cancelamento desce pela árvore de execução;
o que fazer com resultados que chegam tarde;
que evidência prova que o trabalho realmente parou.

A política de retentativas classifica erros, backoff, jitter e destino final. A deadline impõe o teto temporal compartilhado por essas tentativas.

Timeout, deadline, prazo operacional e expiração

Esses controles podem coexistir na mesma unidade.

Timeout limita uma operação

O timeout define quanto uma chamada específica pode esperar. Uma consulta ao CRM pode ter um limite de três segundos. Uma chamada ao modelo pode receber vinte segundos.

Quando a operação atinge o timeout, o cliente deixa de esperar. Isso não garante que o servidor interrompeu o processamento nem que uma escrita falhou.

Deadline fixa um instante final

A deadline é um horário absoluto, como 2026-09-30T18:05:00Z. Componentes diferentes conseguem calcular o tempo restante sem reiniciar o relógio a cada salto.

Se restam oito segundos, uma ferramenta com timeout padrão de trinta segundos não deveria receber os trinta. Ela usa o menor valor entre seu limite local e o tempo ainda disponível.

Prazo operacional vem do processo

Um follow-up pode precisar ser preparado antes do fim do expediente. Uma aprovação comercial pode vencer antes da reunião. Esse prazo pertence ao trabalho, mesmo quando cada chamada técnica dura poucos segundos.

A deadline técnica deve nascer desse requisito com margem para confirmação, comunicação e encerramento seguro.

Expiração invalida o conteúdo ou a autoridade

Uma cotação, autorização, sessão ou dado pode vencer antes do prazo geral. Nesse caso, prevalece a expiração mais próxima.

Um agente não deve continuar porque ainda possui tempo de CPU quando a informação que sustentava a ação perdeu validade.

Use um horário absoluto como autoridade

Durações relativas se renovam sem querer.

Considere uma unidade criada às 14h com deadline às 14h10. A primeira etapa consome quatro minutos. A segunda envia uma subtarefa com "timeout de dez minutos". A nova chamada pode trabalhar até 14h14, quatro minutos depois do limite original.

Com horário absoluto, a subtarefa recebe deadline_at = 14:10. Ao começar às 14h04, ela sabe que possui menos de seis minutos. Se entrar na fila às 14h09min50s, restam dez segundos. A política pode recusar o início.

Um envelope mínimo pode conter:

{
  "work_item_id": "BRF-2048",
  "created_at": "2026-09-30T14:00:00Z",
  "deadline_at": "2026-09-30T14:10:00Z",
  "expires_at": "2026-09-30T14:08:00Z",
  "parent_execution_id": "EXEC-771",
  "remaining_attempts": 2,
  "cancellation_id": "CAN-552",
  "deadline_reason": "briefing antes da reunião",
  "owner": "gerência comercial"
}

O exemplo é sintético. deadline_at limita a execução. expires_at mostra que a base consultada precisa ser revalidada dois minutos antes. A etapa deve respeitar o limite mais próximo.

Calcule o tempo restante antes de admitir trabalho

Cada fronteira de execução deveria calcular:

tempo_restante = menor(deadline_at, expires_at) - agora

Depois, compare o resultado com quatro parcelas:

tempo mínimo esperado da operação;
margem para variabilidade;
tempo reservado para confirmação ou reconciliação;
tempo necessário para comunicar o estado final.

Se a soma não cabe, a chamada não começa na rota normal.

A decisão pode ser:

entregar a parte já confirmada;
usar uma rota mais curta aprovada;
registrar pendência para uma pessoa;
pedir nova autorização com outro prazo;
cancelar a unidade;
manter somente leitura;
encerrar sem executar o efeito externo.

Começar uma etapa sem chance razoável de conclusão apenas converte o pouco tempo restante em custo e incerteza.

A chamada filha nunca recebe mais tempo que a mãe

Uma regra simples evita a renovação acidental:

deadline_filha = menor(deadline_pai, agora + limite_local_da_etapa)

Se a execução principal vence em quarenta segundos e a ferramenta aceita até dois minutos, a chamada filha recebe menos de quarenta segundos. Se a ferramenta precisa de no mínimo um minuto, a política deve escolher outra rota antes de chamá-la.

A documentação de gRPC da Microsoft descreve esse comportamento para chamadas aninhadas: a deadline deve ser propagada e, quando existem limites diferentes, prevalece a menor.

Em agentes de IA, aplique a mesma disciplina a:

chamadas de modelo;
busca e reranking;
APIs de CRM, ERP e agenda;
servidores MCP;
execução de código;
agentes delegados;
filas e jobs;
aprovações com espera;
upload e processamento de arquivos;
consulta de estado e reconciliação.

Reserve tempo para fechar a unidade

Consumir todo o prazo na operação principal deixa o sistema sem espaço para descobrir o resultado real.

Uma escrita no CRM pode terminar no último segundo e perder a resposta. A interface recebe timeout, mas o registro já existe. Repetir cria duplicidade. Encerrar como falha também registra uma realidade incorreta.

Separe uma reserva para:

consultar o destino;
confirmar o identificador criado;
persistir o estado final;
revogar uma credencial efêmera;
liberar uma reserva ou lease;
cancelar trabalho filho;
informar resultado parcial;
enviar o caso para reconciliação.

Se a unidade possui dez minutos, a etapa de negócio talvez precise parar antes. O tamanho da reserva depende do efeito, da dependência e do risco. Não existe porcentagem universal.

Retentativas consomem a mesma deadline

Uma nova tentativa não recebe outro prazo completo.

Antes de repetir, calcule:

tempo_necessario = espera_do_backoff + timeout_da_chamada + reserva_final

A tentativa só entra quando esse valor cabe no tempo restante e a causa ainda admite repetição.

A Amazon Builders' Library alerta que retentativas em várias camadas podem multiplicar chamadas e prolongar uma falha. A política deve escolher um ponto principal de repetição e carregar o consumo já realizado.

Registre:

tentativas feitas pelo SDK;
tentativas feitas pelo adaptador;
reentregas da fila;
chamadas refeitas pelo orquestrador;
espera acumulada;
custo acumulado;
prazo restante no início de cada tentativa.

Reiniciar um worker não zera relógio nem contador.

Propague cancelamento junto com o prazo

Deadline sem cancelamento deixa processos órfãos.

Quando o prazo termina, o componente pai deve emitir ou atualizar um sinal de cancelamento que alcance as execuções filhas. Cada componente precisa responder ao sinal dentro de uma fronteira conhecida.

A resposta depende do tipo de trabalho.

Operação ainda não iniciada

Remova ou invalide a unidade antes da retirada da fila. O consumidor confirma a deadline ao receber, em vez de confiar no horário em que a mensagem foi criada.

Leitura em andamento

Interrompa a chamada quando a biblioteca e o servidor suportarem cancelamento. Descarte resultado tardio ou marque-o como evidência fora do prazo, sem promovê-lo a resposta vigente.

Escrita enviada

Não presuma reversão. O cliente pode ter parado de esperar enquanto o destino confirmou o efeito. Consulte o sistema oficial com a chave de idempotência e encaminhe incerteza para reconciliação.

Modelo gerando resposta

Interrompa o streaming ou a requisição quando possível. Qualquer trecho recebido precisa continuar identificado como parcial. Não o use como aprovação, instrução final ou confirmação de ação.

Agente filho

O filho recebe o identificador de cancelamento, para novas ferramentas, salva o estado mínimo e devolve o que foi confirmado. Ele não deve criar outro agente para terminar silenciosamente o trabalho.

O guia de cancelamento de tarefas cobre o encerramento de uma unidade específica. Aqui, o ponto central é fazer o cancelamento acompanhar a mesma árvore que recebeu a deadline.

Filas precisam preservar validade

Mensagens podem permanecer na fila por tempo superior ao da execução.

Inclua na unidade enfileirada:

deadline_at;
expiração dos dados ou da autorização;
classe de serviço;
tempo mínimo necessário para processar;
destino se o prazo vencer;
identidade da execução pai;
identificador de cancelamento;
contador de tentativas.

O consumidor verifica esses campos depois de receber a mensagem. Uma tarefa válida na entrada pode estar vencida na saída.

Quando a fila já consumiu quase toda a janela, o sistema pode registrar expirado_na_fila, devolver um resultado parcial ou encaminhar a pessoa responsável. Chamar modelos e ferramentas para depois descartar a resposta seria uma forma cara de confirmar o relógio.

A página sobre consumer lag mostra como medir quantidade, idade e posição do atraso. A deadline transforma essa idade em decisão por unidade.

Fan-out exige orçamento por ramo

Uma execução que abre vários ramos pode consumir o prazo de modo desigual.

O pai precisa declarar:

deadline comum;
limite local de cada ramo;
política de conclusão;
número mínimo de resultados válidos;
ramos obrigatórios;
margem para agregação;
tratamento de respostas tardias.

Se um briefing depende de três fontes e apenas duas cabem no prazo, a política decide se entrega saída parcial, pede extensão ou encerra. Ela não espera indefinidamente pelo ramo mais lento.

No fan-in, o agregador aceita apenas resultados vinculados à execução, versão e janela válidas. Um resultado que chega depois do fechamento pode alimentar diagnóstico ou cache, se autorizado. Ele não altera silenciosamente um artefato já aprovado.

O guia de fan-out e fan-in detalha manifesto, identidade dos ramos e política de agregação.

Aprovação humana possui relógio próprio

Uma aprovação pode esperar horas ou dias. A chamada técnica não deveria permanecer aberta durante esse período.

Persista o pedido, registre deadline e expiração, pare a execução e aguarde um evento durável. Quando a resposta chegar:

confirme que a unidade continua aberta;
valide o objeto apresentado à pessoa;
verifique se a aprovação ainda está dentro da validade;
releia dados que podem ter mudado;
calcule o tempo restante para executar o efeito;
recuse o avanço quando a janela não comportar confirmação segura.

Uma aprovação recebida às 17h59 não autoriza uma sequência de vinte minutos cujo compromisso vence às 18h.

A aprovação assíncrona organiza pausa durável, versão do objeto e decisão tardia.

Trate o relógio como dado observável

Logs de timeout isolados não mostram por que o prazo foi perdido.

Registre em cada etapa:

deadline recebida;
prazo local aplicado;
tempo restante na admissão;
tempo em fila;
tempo de execução;
margem reservada;
quantidade de tentativas;
motivo de encerramento;
sinal de cancelamento enviado e confirmado;
subtarefas ainda abertas;
efeitos externos confirmados ou incertos;
resultado que chegou tarde;
rota final da unidade.

Use relógios sincronizados e guarde horários em UTC. A duração interna pode usar relógio monotônico para evitar saltos do relógio do sistema, enquanto o envelope distribuído carrega o instante absoluto.

Diferenças de relógio entre máquinas precisam entrar no teste. Uma tolerância técnica não pode virar extensão informal da autorização empresarial.

Exemplo: briefing antes de uma reunião comercial

Considere um agente fictício com seis minutos para preparar um briefing.

Entrada

oportunidade OP-391;
reunião às 15h;
criação da unidade às 14h53;
deadline técnica às 14h59;
dados comerciais válidos até 14h58min30s;
um minuto reservado para conferência e publicação.

Etapas

consultar oportunidade e contatos;
reunir últimas interações autorizadas;
buscar compromissos abertos;
gerar resumo;
validar afirmações contra as fontes;
publicar rascunho interno.

Decisões

A busca de interações fica lenta às 14h56. Restam dois minutos e meio de validade dos dados, com um minuto reservado para fechamento.

O orquestrador não abre uma tentativa de três minutos. Ele encerra esse ramo, marca as interações como pendentes e produz um briefing parcial somente com CRM e compromissos confirmados. O documento informa a lacuna.

Às 14h58, a validação encontra um valor divergente. A publicação automática é bloqueada. O agente salva o rascunho e encaminha a divergência para o vendedor, sem consumir o último minuto tentando escolher uma fonte por conta própria.

A unidade termina como concluido_com_pendencia. Não há trabalho filho ativo nem escrita incerta.

Testes que a política precisa enfrentar

Inclua pelo menos:

chamada filha recebe prazo maior que o pai;
unidade entra na fila com prazo válido e sai vencida;
relógios de duas máquinas possuem pequena diferença;
timeout ocorre depois do envio de uma escrita;
SDK repete internamente sem reportar consumo;
backoff ocupa o restante do prazo;
agente filho ignora o sinal de cancelamento;
resultado chega depois do fan-in;
aprovação acontece perto da expiração;
dado vence antes da deadline geral;
worker reinicia e tenta renovar o relógio;
fila reentrega uma unidade cancelada;
rota alternativa também não cabe na janela;
cancelamento interrompe leitura, mas não a escrita remota;
reserva final é consumida pela etapa principal;
estado final diz timeout enquanto o efeito externo existe.

Para cada caso, confirme:

nenhuma etapa começa sem tempo suficiente segundo a política;
o menor prazo prevalece;
tentativas não renovam a janela;
cancelamento alcança todos os ramos conhecidos;
efeitos incertos vão para reconciliação;
o usuário recebe um estado legível;
nenhuma resposta tardia altera uma decisão encerrada;
custo e trabalho órfão aparecem nas métricas.

Use o ambiente de teste para agentes de IA para provocar lentidão, atraso de fila e confirmações perdidas sem gerar consequências reais.

Métricas para operar deadlines

Acompanhe:

unidades concluídas dentro do prazo útil;
unidades recusadas antes de começar por falta de tempo;
tempo restante na admissão de cada etapa;
deadlines perdidas por dependência;
tempo gasto depois da deadline;
subtarefas órfãs encontradas;
tentativas bloqueadas por orçamento insuficiente;
resultados tardios descartados;
efeitos externos incertos no encerramento;
cancelamentos enviados e confirmados;
unidades concluídas com pendência;
prazos renovados por decisão humana;
custo de trabalho feito depois da validade;
diferenças entre prazo técnico e necessidade do processo.

Taxa de timeout sozinha é pouco informativa. Um sistema pode registrar poucos timeouts e continuar trabalhando depois do prazo porque nunca propagou o limite.

Fontes oficiais verificadas em 30 de setembro de 2026

Microsoft Learn: Reliable gRPC services with deadlines and cancellation, para deadline absoluta, propagação por chamadas filhas, menor prazo, cancelamento e interação com retentativas.
Microsoft Azure Well-Architected: Recommendations for handling transient faults, para relação entre timeout, prazo total, retentativas, backoff e jitter.
AWS Builders' Library: Timeouts, retries, and backoff with jitter, para contenção de chamadas lentas, amplificação por retentativas em camadas, idempotência e jitter.

As fontes descrevem mecanismos de sistemas distribuídos. A tradução para unidade empresarial, validade de dados, autorização, resultado parcial e dono operacional pertence ao desenho do processo.

Checklist para propagar a deadline

[ ] A unidade possui prazo operacional e deadline técnica?
[ ] A deadline usa horário absoluto?
[ ] Expirações mais curtas prevalecem?
[ ] Cada etapa calcula o tempo restante antes de começar?
[ ] Chamadas filhas recebem prazo igual ou menor que o pai?
[ ] Existe margem para confirmação e encerramento?
[ ] Retentativas usam a mesma janela e o mesmo contador?
[ ] SDK, fila e orquestrador reportam o consumo real?
[ ] Cancelamento acompanha todas as subtarefas?
[ ] A fila descarta ou encaminha trabalho vencido antes de executar?
[ ] Resultados tardios ficam impedidos de alterar estado encerrado?
[ ] Escritas com confirmação perdida seguem para reconciliação?
[ ] Aprovações são revalidadas perto do prazo?
[ ] Logs mostram prazo recebido, restante e motivo final?
[ ] Testes cobrem atraso, reinício, reentrega e relógios divergentes?
[ ] O dono operacional decide quando um novo prazo pode ser concedido?

O prazo precisa atravessar a mesma árvore que o trabalho

Definir dez minutos na interface não limita uma execução distribuída. O limite precisa chegar a cada ferramenta, fila, agente filho e tentativa, sempre com o relógio original e a menor validade aplicável.

Quando o tempo restante deixa de comportar o trabalho, a arquitetura escolhe uma rota conhecida. Ela entrega o que foi confirmado, registra a pendência, pede nova decisão ou encerra. Também prova que subtarefas e efeitos ficaram sob controle.

Esse desenho reduz custo órfão e impede que uma resposta tecnicamente concluída chegue depois da decisão que deveria apoiar.