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:

1. tempo mínimo esperado da operação;
2. margem para variabilidade;
3. tempo reservado para confirmação ou reconciliação;
4. 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.

Prazo menor acompanha filhos, filas e retentativas

1. 1. Pai distribui o envelope

   Carregar deadline absoluta, expiração, ID do pai, cancelamento e tentativas para CRM, modelo e fila; nenhum filho recebe janela nova.

2. 2. Admissão de cada filho

   Aplicar menor prazo entre pai, expiração e limite local. Antes de iniciar ou repetir, incluir backoff, operação e reserva final.

3. 3. Trabalho admitido

   CRM, modelo ou consumidor só inicia se cabe na janela; fila revalida prazo e cancelamento ao entregar a unidade.

4. 4. Encerrar e cancelar a árvore

   Sem tempo, impedir etapas novas, cancelar filhos e comunicar parcial ou pendência. Resultado tardio não altera unidade fechada.

5. 5. Fechamento com confirmação

   Usar reserva para consultar destino, persistir estado e comprovar parada de filhos. Timeout do cliente não comprova falha da escrita.

6. 6. Reconciliar escrita incerta

   Consultar destino com chave de idempotência; não repetir cegamente nem declarar reversão enquanto efeito não estiver confirmado.

• 1 → 2 Prazo original propagado
• 2 → 3 Operação e reserva cabem
• 2 → 4 Janela insuficiente ou expirada
• 3 → 2 Retentativa usa mesmo teto e contador
• 3 → 5 Concluiu ou parou de esperar: fechar estado
• 5 → 6 Escrita enviada sem confirmação

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:

1. confirme que a unidade continua aberta;
2. valide o objeto apresentado à pessoa;
3. verifique se a aprovação ainda está dentro da validade;
4. releia dados que podem ter mudado;
5. calcule o tempo restante para executar o efeito;
6. 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

1. consultar oportunidade e contatos;
2. reunir últimas interações autorizadas;
3. buscar compromissos abertos;
4. gerar resumo;
5. validar afirmações contra as fontes;
6. 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:

1. nenhuma etapa começa sem tempo suficiente segundo a política;
2. o menor prazo prevalece;
3. tentativas não renovam a janela;
4. cancelamento alcança todos os ramos conhecidos;
5. efeitos incertos vão para reconciliação;
6. o usuário recebe um estado legível;
7. nenhuma resposta tardia altera uma decisão encerrada;
8. 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.