Clock skew em agentes de IA: como tratar o tempo

Dois servidores registraram versões diferentes da mesma manhã

Um agente recebe pedidos por webhook, confere regras e encaminha exceções para aprovação. O servidor A registra a entrada às 09:02:11. O servidor B grava a aprovação às 09:02:08. Pela ordenação dos timestamps, a aprovação parece ter acontecido antes do pedido.

A diferença pode vir de relógios locais fora de sincronia, correções do sistema operacional, máquinas virtuais pausadas ou conversões de fuso. Três segundos bastam para inverter uma sequência curta, liberar um lease cedo demais ou classificar uma tarefa válida como vencida.

Clock skew é a diferença entre os horários observados por máquinas ou componentes distintos. Em agentes de IA, o efeito aparece quando o sistema usa horário de parede para decidir ordem, autoridade, validade ou exclusividade.

Este artigo trata da semântica do tempo na arquitetura. O guia sobre propagação de deadlines mostra como um orçamento temporal atravessa etapas. A página sobre leader election cobre a troca de coordenador. Aqui, a pergunta é outra: quais decisões continuam corretas quando os relógios discordam?

Onde o horário entra no trabalho de um agente

O tempo participa de várias decisões operacionais:

aceitar ou recusar uma tarefa pelo prazo;
expirar autorização humana;
renovar um lease;
ordenar eventos recebidos de canais diferentes;
calcular duração de uma chamada;
definir validade de cache e contexto;
aplicar janela de silêncio em comunicação;
encerrar uma sessão;
medir SLA;
escolher a versão mais recente de um registro;
excluir dados depois do período de retenção;
correlacionar logs durante um incidente.

Esses usos pedem tipos diferentes de evidência. Um timestamp pode ajudar uma pessoa a localizar um evento no calendário. Ele pode ser fraco demais para decidir qual escrita venceu uma corrida.

Separe instante, duração e ordem

Misturar essas três ideias cria boa parte dos erros.

Instante civil

Responde quando algo aconteceu segundo um calendário compartilhado. Use UTC no armazenamento e converta para o fuso da pessoa apenas na apresentação.

Exemplos:

recebido_em: 2026-10-06T12:02:11.482Z
fuso_exibicao: America/Sao_Paulo

O instante civil é útil para auditoria, prazo contratual, agenda, retenção e comunicação. Ele continua sujeito a sincronização, ajustes e incerteza entre máquinas.

Duração decorrida

Responde quanto tempo passou dentro de um processo. Um relógio monotônico é a referência adequada porque ele avança de forma contínua para medir intervalos e não acompanha saltos do calendário.

Use duração decorrida para:

timeout de uma chamada;
orçamento interno de uma etapa;
latência;
intervalo entre retentativas;
margem de renovação local;
tempo de processamento.

Se o relógio civil recuar durante uma correção, a duração monotônica continua utilizável.

Ordem causal

Responde qual evento depende de outro. Essa relação deve vir do próprio fluxo: versão, sequência, offset, revisão, identificador de execução ou vínculo entre comando e resultado.

Exemplo:

pedido_id: PED-842
versao_anterior: 17
versao_nova: 18
evento: aprovacao_registrada
causado_por: comando-5f29

O evento de versão 18 sucede a versão 17 por contrato do sistema. Dois horários parecidos não precisam arbitrar essa ordem.

Sincronização reduz erro, mas não cria uma ordem confiável

Serviços de sincronização mantêm relógios próximos. Eles ajudam logs, certificados, retenção e observação operacional. Ainda assim, proximidade não equivale a igualdade.

Uma arquitetura precisa admitir:

atraso entre a leitura e a correção do relógio;
precisão diferente entre hosts;
ajuste gradual ou salto do horário;
máquina suspensa e retomada depois;
container migrado;
host sob carga intensa;
perda temporária da fonte de tempo;
evento enviado antes e recebido depois;
relógio correto no produtor e incorreto no consumidor.

A AWS descreve por que seus sistemas evitam depender de relógios sincronizados para ordenar operações distribuídas. Em leases, a recomendação é usar duração local decorrida e tratar com cuidado pausas, redes lentas e trabalho que continua depois da expiração.

Mantenha sincronização e monitore seu estado. Desenhe a correção sem pressupor simultaneidade perfeita.

Não escolha a última versão pelo maior timestamp

O padrão last write wins baseado no horário do cliente parece simples:

aceitar se incoming.updated_at > current.updated_at

Ele falha quando dois produtores discordam sobre o horário. Uma atualização antiga pode carregar timestamp maior e substituir um estado recente.

Prefira uma autoridade que consiga impor ordem:

versão crescente por objeto;
compare-and-set sobre a versão esperada;
número de sequência por partição;
offset do log;
revisão retornada pelo armazenamento;
evento anexado numa transação;
ETag validada na escrita.

Guarde o timestamp para auditoria. Use a versão para decidir qual mudança pode avançar.

O artigo sobre controle de concorrência mostra como impedir que uma decisão preparada sobre estado antigo seja gravada depois de outra alteração.

Deadlines precisam viajar como orçamento restante

Um serviço recebe uma tarefa às 12:00:00Z com prazo final às 12:00:30Z. Ele pode repassar somente o instante absoluto. O serviço seguinte olha seu relógio adiantado e conclui que restam cinco segundos, embora o chamador ainda calcule oito.

Um envelope mais seguro mantém duas informações:

expires_at_utc: 2026-10-06T12:00:30Z
remaining_budget_ms_at_send: 8200
sent_at_utc: 2026-10-06T12:00:21.800Z

O destinatário aplica a política aprovada para reconciliar orçamento recebido, tempo de trânsito e seu próprio limite. Ele nunca amplia o prazo porque o relógio local parece atrasado.

Regras úteis:

o prazo empresarial absoluto continua visível;
cada processo mede seu consumo com relógio monotônico;
o orçamento restante diminui ao atravessar etapas;
a etapa reserva tempo para confirmar, cancelar ou reconciliar;
tarefa vencida recebe estado explícito;
nenhuma retentativa reinicia o prazo original;
aprovação humana possui validade própria, ligada à versão analisada.

O instante civil preserva o compromisso. A duração monotônica controla o consumo local.

Leases exigem autoridade verificável no destino

Um lease concede posse por período limitado. O worker pode pausar, perder a renovação e continuar vivo. Outro worker assume. Quando o primeiro volta, seu relógio local pode ainda sugerir que existe margem.

A autoridade precisa vir do coordenador e chegar ao recurso protegido.

Registre pelo menos:

resource: fechamento:empresa-aurora:2026-10
holder: worker-a31
lease_revision: 2481
acquired_at_utc: 2026-10-06T12:14:00Z
expires_at_utc: 2026-10-06T12:14:30Z

Antes de produzir um efeito sensível:

confira se a posse continua vigente no coordenador;
pare o trabalho quando a renovação perde a margem aprovada;
inclua revisão ou token crescente na escrita;
faça o destino rejeitar revisões antigas;
use idempotência para efeitos repetíveis;
reconcilie ações cujo resultado ficou incerto.

O horário local não consegue revogar um processo antigo. A fronteira de escrita precisa recusar sua autoridade vencida.

Eventos precisam carregar identidade e versão

Considere três fatos sobre uma oportunidade:

E17: proposta enviada
E18: cliente recusou
E19: tarefa de follow-up cancelada

A fila pode entregar E19 antes de E18. Os timestamps podem inverter a sequência. O consumidor deve conhecer a versão esperada e o que fazer diante de lacuna.

Políticas possíveis:

esperar brevemente pela versão ausente;
buscar o estado atual na fonte oficial;
aplicar apenas eventos com versão consecutiva;
manter evento fora de ordem numa área de espera;
reconstruir o objeto a partir do log autorizado;
encerrar evento superado;
abrir exceção quando a lacuna afeta uma decisão irreversível.

A escolha depende do processo. Um painel pode tolerar atraso. Uma cobrança, uma concessão de acesso ou uma mensagem ao cliente pedem um contrato mais conservador.

Use janelas de tolerância somente onde elas fazem sentido

Algumas decisões aceitam margem. Um token que expira às 12:00 pode tolerar poucos segundos de variação durante validação técnica. Um prazo regulatório ou uma janela de consentimento talvez não aceite extensão.

Defina a tolerância por finalidade:

uso: validar token interno
margem: definida pela equipe de segurança
quem aplica: gateway autorizado
pode ampliar ação externa: não
registro: horário observado + motivo

Evite uma tolerância global escondida na biblioteca. Ela pode prolongar autorização, retenção ou envio em processos que exigem corte exato.

Quando houver dúvida, o agente deve bloquear a consequência e encaminhar o caso com os horários observados, a fonte de cada horário e a decisão pendente.

Modele estados temporais legíveis

Um erro genérico de tempo oferece pouca ação. Use estados que expliquem o conflito:

prazo_valido;
prazo_proximo_do_limite;
prazo_expirado;
relogio_local_degradado;
sincronizacao_indisponivel;
evento_fora_de_ordem;
versao_ausente;
lease_incerto;
lease_perdido;
autorizacao_temporal_vencida;
aguardando_reconciliacao.

Registre junto:

instante informado pela origem;
instante observado na entrada;
versão do objeto;
duração medida localmente;
qualidade da sincronização;
margem aplicada;
política usada;
efeito que foi bloqueado;
responsável e próxima ação.

Esse pacote permite investigar o caso sem tentar reconstruir uma linha do tempo a partir de logs com relógios divergentes.

Exemplo: aprovação de pagamento com dois relógios

Uma solicitação exige aprovação válida por 15 minutos e continua vinculada à versão 7 do pagamento.

Criação

O sistema financeiro cria APR-771, registra o prazo absoluto e emite uma versão da autorização. A interface mostra o horário no fuso da pessoa.

Aprovação

A aprovadora confirma dentro da janela apresentada. O serviço de aprovação registra o evento com seu horário, identidade e a versão 7.

Divergência

O worker que executaria o pagamento está com o relógio adiantado. Pela leitura local, a autorização já venceu.

Decisão segura

O worker não altera o timestamp nem amplia a janela. Ele consulta a autoridade da autorização, recebe o estado corrente e confirma que a versão 7 continua válida segundo o serviço responsável. Em seguida, executa com chave idempotente.

Se o serviço de autoridade estiver indisponível, o pagamento fica como aguardando_confirmacao_de_validade. O agente preserva o compromisso financeiro em vez de escolher um relógio por conveniência.

Observe a saúde do tempo

Acompanhe:

desvio estimado por host;
idade da última sincronização;
falhas da fonte de tempo;
saltos do relógio civil;
tarefas rejeitadas por prazo;
deadlines que chegaram com orçamento negativo;
eventos fora de ordem;
lacunas de versão;
leases perdidos durante execução;
escritas recusadas por revisão antiga;
diferenças entre horário de origem e recebimento;
incidentes cuja linha do tempo ficou ambígua.

Alertas precisam mostrar consequência. "Worker de cobrança com desvio acima do limite; novos envios suspensos; 42 unidades aguardam confirmação" orienta melhor que uma mensagem isolada sobre NTP.

Teste falhas temporais antes da produção

Inclua cenários como:

relógio de um worker adiantado;
relógio de outro worker atrasado;
ajuste do relógio para trás durante a execução;
máquina pausada além do lease;
evento novo entregue antes do antigo;
retentativa depois do prazo empresarial;
aprovação que vence antes do compromisso;
cache considerado novo por timestamp incorreto;
token usado perto da expiração;
perda da fonte de sincronização;
reinício com temporizadores locais perdidos;
logs de regiões diferentes com latência variável.

Verifique estado final, quantidade de efeitos, versão aceita, duração medida, decisão tomada e evidência disponível para reconciliação.

Checklist de arquitetura temporal

[ ] Instantes são armazenados em UTC?
[ ] Fuso aparece como dado de apresentação ou regra empresarial explícita?
[ ] Durações internas usam relógio monotônico?
[ ] Ordem de eventos usa versão, sequência ou causalidade?
[ ] Escritas recusam versões antigas?
[ ] Deadlines diminuem ao atravessar etapas?
[ ] Retentativas preservam o prazo original?
[ ] Leases dependem de autoridade do coordenador?
[ ] O destino consegue recusar um holder antigo?
[ ] Tolerâncias são específicas por finalidade?
[ ] Sincronização e desvio são monitorados?
[ ] Estados temporais indicam próxima ação?
[ ] Testes cobrem saltos, pausas e entrega fora de ordem?
[ ] Alertas informam impacto e responsável?

O relógio informa; o contrato decide

Horários continuam necessários para auditoria, calendário, retenção e operação. O erro aparece quando um timestamp local recebe poder para ordenar eventos ou liberar consequências sem outra garantia.

Uma arquitetura temporal segura usa UTC para instantes compartilhados, relógio monotônico para durações, versões para ordem e autoridade verificável para leases e aprovações. Assim, três segundos de diferença continuam sendo um dado observável. Eles deixam de ser capazes de reescrever a sequência do negócio.

Fontes oficiais verificadas em 6 de outubro de 2026:

AWS Builder Center: Leader Election in Distributed Systems, para uso de duração local em leases, riscos de rede lenta, pausas e dependência indevida de relógios sincronizados.
Amazon DynamoDB: Distributed locking with the DynamoDB Lock Client, para lease, heartbeat, escrita condicional, clock skew e ordem consistente na aquisição de locks.
Microsoft Learn: Leader Election pattern, para coordenação temporária, locks com prazo e troca de líder.

As fontes sustentam os mecanismos descritos. Limites de desvio, margens e prazos precisam ser definidos e testados no ambiente adotado.