Leader election em agentes de IA: como coordenar

Duas instâncias assumiram a rotina da manhã

Uma empresa mantém três réplicas do agente que prepara o relatório comercial diário. A redundância protege a operação quando um servidor falha. Às 7h, porém, duas réplicas concluem que devem iniciar o ciclo. Cada uma busca as mesmas oportunidades, abre o mesmo período e publica sua própria lista de pendências.

O problema apareceu numa tarefa exclusiva. Várias instâncias podiam ficar prontas, mas somente uma deveria coordenar aquela rotina em cada momento.

Leader election permite que um conjunto de instâncias escolha uma líder temporária. As demais permanecem como seguidoras e podem assumir quando a líder perde sua autoridade. O mecanismo reduz o ponto único de falha sem liberar vários coordenadores para o mesmo trabalho.

Este guia trata da eleição aplicada a schedulers, reconciliadores e coordenadores de agentes. O artigo sobre controle de concorrência protege objetos disputados por várias execuções. Aqui, a pergunta é anterior: qual instância possui autoridade para comandar uma função exclusiva agora?

Quando uma liderança exclusiva faz sentido

A eleição acrescenta estado compartilhado, renovação, transição e tratamento de falhas. Use quando uma função precisa continuar disponível e executar em uma única instância ativa.

Casos frequentes incluem:

disparar um ciclo agendado sem duplicar a janela;
reconciliar tarefas presas numa fila;
promover configurações aprovadas;
coordenar partições ou distribuir trabalho;
consolidar um relatório por período;
executar limpeza de registros vencidos;
controlar uma migração gradual;
escolher a instância que representa o grupo perante outro sistema.

Réplicas que apenas consomem unidades independentes costumam funcionar melhor como consumidores concorrentes. Forçar uma líder para todo o processamento pode reduzir capacidade e criar contenção desnecessária.

A pergunta prática é: qual ação ficaria incorreta se duas instâncias a iniciassem como coordenadoras ao mesmo tempo? Se a resposta for nenhuma, talvez a eleição só acrescente arquitetura.

Separe três identidades

O desenho fica mais seguro quando registra identidades diferentes.

Instância

É o processo ou réplica que participa da eleição. Precisa de um identificador único por execução, como:

worker_id: relatorio-7f95c8d9-x2k4
started_at: 2026-10-02T06:54:12Z
build: 2026.10.02-3
region: br-southeast

Reutilizar o mesmo nome entre processos dificulta saber qual deles adquiriu, renovou ou perdeu a liderança.

Mandato de liderança

É a concessão temporária que autoriza uma instância a coordenar. Um lease pode registrar:

role: relatorio-comercial-diario
holder: relatorio-7f95c8d9-x2k4
term: 184
acquired_at: 2026-10-02T06:59:42Z
renewed_at: 2026-10-02T07:00:02Z
expires_at: 2026-10-02T07:00:22Z

O mandato possui prazo. A instância continua viva depois de perder a liderança, mas precisa interromper a função exclusiva.

Unidade de trabalho

É o ciclo empresarial coordenado pela líder. Exemplo:

job_key: relatorio-comercial:2026-10-02
period_start: 2026-10-01T00:00:00-03:00
period_end: 2026-10-01T23:59:59-03:00

A eleição escolhe quem coordena. A identidade da unidade protege o resultado contra repetição durante troca de líder, reinício ou retentativa.

A eleição não substitui idempotência

Uma única líder por instante ainda pode produzir duas tentativas ao longo do tempo.

Considere esta sequência:

a líder A inicia o relatório;
A grava parte do resultado;
A perde conexão com o serviço de coordenação;
o lease expira;
B assume a liderança;
B retoma o mesmo ciclo;
A volta e tenta concluir.

A eleição limita a autoridade corrente. Ela não apaga efeitos já produzidos nem garante que a antiga líder parou no mesmo instante.

Por isso, cada ciclo precisa de:

chave estável da unidade;
checkpoint confirmado;
escrita condicional;
chave de idempotência por efeito;
registro da versão ou termo do líder;
confirmação no sistema de destino;
reconciliação depois da transição.

O guia sobre idempotência em agentes de IA cobre a repetição de efeitos. A página sobre reconciliação ajuda a comparar intenção registrada e estado confirmado depois de falhas.

Use um lease com prazo e renovação

A documentação da Microsoft apresenta leader election por meio de um lock com tempo de vida. A líder renova sua posse enquanto permanece saudável. Se deixa de renovar, outra instância pode adquirir a função.

O Kubernetes usa objetos Lease para coordenação, incluindo eleição de componentes em configurações de alta disponibilidade. Campos como identidade da detentora, tempo de renovação, duração e quantidade de transições deixam a liderança observável.

Um lease operacional precisa definir:

nome da função exclusiva;
identidade da detentora;
instante da aquisição;
última renovação observada;
duração;
número do mandato ou transição;
versão do registro de coordenação;
regra de aquisição;
regra de liberação;
margem para atraso e variação de relógio.

A renovação deve ocorrer antes da expiração, com margem suficiente para atrasos ocasionais. Renovar perto demais do limite aumenta transições evitáveis. Um prazo amplo demais prolonga a indisponibilidade quando a líder cai.

Escolha os tempos a partir de medições do ambiente:

latência do serviço de coordenação;
pausas do runtime;
duração de indisponibilidades transitórias;
precisão dos relógios usados;
tempo tolerável sem coordenador;
tempo necessário para interromper o trabalho antigo;
consequência de duas líderes aparentes.

Não copie números de um exemplo para produção. O prazo pertence ao risco e ao comportamento medido do sistema.

Trate perda de renovação como perda de autoridade

A instância pode continuar com CPU, memória e rede parcial enquanto deixa de renovar o lease. Ela não deveria esperar uma confirmação perfeita de que outra líder assumiu.

Quando a renovação falha além da margem aprovada:

pare de admitir novos ciclos exclusivos;
marque o mandato como incerto localmente;
interrompa chamadas que ainda não chegaram ao compromisso;
preserve checkpoint e contexto mínimo;
evite qualquer novo efeito externo;
consulte novamente o registro de liderança;
encerre ou entre em modo seguidor;
registre o trabalho que exige reconciliação.

A regra conservadora é simples: sem prova atual de autoridade, a instância deixa de comandar.

Uma instrução no prompt não cria essa garantia. O adaptador de ferramentas e o sistema de destino precisam recusar comandos de uma instância cujo mandato venceu.

Use o termo da liderança para bloquear a antiga líder

O lease pode receber um número crescente a cada transição, chamado aqui de term.

Exemplo:

term 184 -> líder A
term 185 -> líder B

A líder inclui o termo nas operações sensíveis. O destino mantém o maior termo aceito para aquela função ou unidade. Depois de aceitar 185, rejeita um comando atrasado com 184.

Esse mecanismo funciona como token de cercamento. Ele resolve uma falha comum: A perde o lease, fica pausada por alguns segundos e depois continua com uma visão antiga. B já assumiu. O destino precisa impedir que A recupere poder apenas porque voltou a executar.

O termo deve acompanhar:

criação do ciclo;
aquisição de partição;
checkpoint;
publicação de comando;
mudança de estado coordenada;
conclusão da unidade;
registro de auditoria.

Nem todo sistema externo aceita esse campo. Nesses casos, coloque a validação numa camada de escrita controlada pela empresa ou use operações condicionais no registro oficial. Se nenhuma fronteira consegue rejeitar a líder antiga, a eleição oferece coordenação parcial e esse limite precisa ficar explícito.

Defina o trabalho da líder com uma fronteira estreita

A líder pode coordenar sem executar todo o processamento.

Um desenho saudável costuma separar:

Responsabilidades da líder

abrir uma janela de trabalho;
identificar unidades elegíveis;
criar um manifesto;
distribuir partições;
acompanhar progresso agregado;
iniciar reconciliação;
encerrar o ciclo;
publicar o estado consolidado.

Responsabilidades dos workers

processar unidades independentes;
validar entrada e permissão;
chamar modelos e ferramentas;
registrar checkpoint;
confirmar efeitos;
devolver resultado ou exceção.

Assim, a eleição governa a coordenação e o processamento continua distribuído. Se a líder executa cada unidade, qualquer transição interrompe uma área maior e limita escala.

Não associe liderança a superioridade do modelo

A escolha da líder precisa ser determinística e operacional. Qualidade de resposta, confiança declarada pelo modelo ou uma votação em linguagem natural criam uma eleição difícil de reproduzir.

Critérios possíveis incluem:

aquisição atômica do lease;
versão compatível;
região elegível;
estado de prontidão;
prioridade definida pela plataforma;
regra explícita para transição durante upgrade.

Depois de eleita, a instância usa o mesmo conjunto aprovado de modelos, políticas e ferramentas. Liderança concede uma função técnica temporária. Ela não amplia alçada empresarial, permissão de dados ou autonomia do agente.

Evite transformar a líder em fonte da verdade

A líder pode cair a qualquer momento. Estado mantido apenas em sua memória desaparece ou reaparece desatualizado.

Persista fora da instância:

manifesto do ciclo;
unidades admitidas;
versão da política;
checkpoints confirmados;
efeitos concluídos;
aprovações pendentes;
erros e exceções;
termo da liderança;
estado de encerramento.

A nova líder deve reconstruir o trabalho a partir desse estado compartilhado e dos sistemas oficiais. Ela não deveria depender de copiar a memória privada da instância anterior.

A página sobre tarefas longas de agentes detalha checkpoints, retomada e estados. Leader election acrescenta a troca de coordenador sobre esse trabalho durável.

Planeje a transição de liderança

Uma troca segura precisa responder cinco perguntas.

O que a líder antiga estava fazendo?

Registre ciclo, etapa, partições distribuídas, comandos emitidos, confirmações recebidas e operações ainda incertas.

O que já produziu efeito?

Consulte os destinos. Ausência de resposta pode significar falha antes ou depois da execução. Não repita até verificar a chave idempotente e o estado final.

O que a nova líder pode retomar?

Retome unidades com checkpoint válido e versão compatível. Reavalie prazos, autorizações, fontes e políticas antes de continuar.

O que precisa ser abandonado?

Ciclos vencidos, comandos com termo antigo, janelas fechadas e aprovações ligadas a versões superadas devem terminar com estado explícito.

Quem recebe a exceção?

Uma transição pode deixar trabalho em dúvida. Defina dono, prazo, evidência e capacidade de interromper ou reconciliar.

Exemplo: relatório diário de oportunidades

Três réplicas podem coordenar o relatório. Todas participam da eleição para a função relatorio-comercial-diario.

Aquisição

A réplica B adquire o lease com term = 184. Ela cria a unidade relatorio-comercial:2026-10-02 somente se essa chave ainda não existe.

Manifesto

B registra o período, as fontes autorizadas, a versão dos critérios e os identificadores das oportunidades elegíveis. Cada item recebe estado próprio.

Distribuição

Workers processam os itens. O relatório separa oportunidade sem próxima ação, registro incompleto, conflito de estágio e dado indisponível. Nenhum contato é enviado.

Falha

B perde acesso ao serviço de coordenação depois de distribuir metade dos itens. A renovação ultrapassa a margem. B suspende novas ações e guarda o último checkpoint.

Nova líder

C adquire term = 185. Ela encontra a unidade existente, consulta os resultados confirmados e redistribui somente itens sem conclusão válida.

Proteção

B retorna e tenta encerrar o ciclo com term = 184. A camada de compromisso rejeita a operação. C reconcilia os itens, fecha o manifesto e publica uma única versão do relatório.

A chave do ciclo evitou um segundo relatório. O termo impediu a antiga líder de concluir. Os checkpoints limitaram o reprocessamento.

Modele estados observáveis

Use estados que permitam operação e investigação:

candidato
lider_adquirida
lider_renovando
lider_incerta
lider_perdida
seguidor
transicao_em_reconciliacao
ciclo_aberto
ciclo_em_processamento
ciclo_com_efeito_incerto
ciclo_concluido
ciclo_abandonado

Cada transição deve registrar:

função coordenada;
instância;
termo;
horário observado;
versão do lease;
motivo;
ciclo afetado;
último checkpoint;
efeitos incertos;
próxima ação;
responsável quando houver exceção.

Um alerta útil diz: “a líder do relatório diário perdeu renovação; nenhuma nova unidade será admitida; 18 de 31 itens estão confirmados; a nova líder precisa reconciliar 13”. A linguagem mostra consequência e ação, não apenas erro técnico.

Teste as falhas que criam duas líderes aparentes

Inclua cenários como:

duas instâncias tentam adquirir o lease ao mesmo tempo;
a líder perde rede com o coordenador, mas alcança o CRM;
a líder pausa por período maior que o lease;
o relógio local apresenta desvio;
a renovação responde depois do prazo;
a líder cai antes de criar o manifesto;
a líder cria o manifesto e cai antes da distribuição;
um comando conclui e a resposta se perde;
a nova líder assume com itens em andamento;
a antiga líder volta com termo vencido;
o serviço de coordenação fica indisponível;
a plataforma reinicia todas as réplicas;
uma versão antiga e outra nova disputam liderança;
a liberação voluntária falha durante deploy;
nenhuma candidata permanece elegível.

Para cada caso, confirme:

quantidade de ciclos criados;
quantidade de efeitos externos;
termo aceito no destino;
tempo sem coordenador;
checkpoint usado na retomada;
registro da transição;
fila de exceções;
capacidade de reconciliação.

Métricas para operar a eleição

Acompanhe:

aquisições e renovações por função;
falhas de renovação;
duração dos mandatos;
transições por período;
tempo até nova liderança;
períodos sem líder;
comandos recusados por termo vencido;
ciclos duplicados bloqueados;
unidades retomadas por transição;
efeitos incertos depois da troca;
tempo de reconciliação;
diferença de versão entre candidatas;
contenção no serviço de coordenação;
disponibilidade do trabalho coordenado.

Transições frequentes podem indicar lease curto, latência instável, pausas do runtime, sobrecarga ou desenho com responsabilidade ampla demais.

Checklist de implementação

[ ] Existe uma função realmente exclusiva?
[ ] Réplicas comuns poderiam processar unidades independentes sem líder?
[ ] Cada instância possui identidade única?
[ ] O lease registra detentora, prazo, renovação e termo?
[ ] A renovação tem margem baseada em medição?
[ ] A instância para de comandar quando perde prova de autoridade?
[ ] O destino rejeita termos antigos?
[ ] Cada ciclo possui chave estável e idempotência?
[ ] Checkpoints ficam fora da memória da líder?
[ ] A nova líder consegue reconstruir e reconciliar o trabalho?
[ ] A líder coordena uma fronteira estreita?
[ ] Liderança não amplia permissões empresariais?
[ ] Deploy e mudança de versão possuem regra de transição?
[ ] Alertas informam consequência, responsável e próxima ação?
[ ] Testes cobrem pausa, partição de rede, retomada e líder antiga?

A liderança precisa expirar de verdade

Alta disponibilidade exige réplicas prontas para assumir. Tarefas exclusivas exigem uma autoridade corrente e verificável. Leader election liga essas duas necessidades por um mandato temporário.

A implementação segura combina lease renovável, identidade de instância, termo crescente, unidade idempotente, checkpoint durável e reconciliação. Quando a renovação acaba, a autoridade também acaba. É esse corte que impede redundância de virar comando duplicado.

Fontes oficiais verificadas em 2 de outubro de 2026:

Microsoft Learn: Leader Election pattern, para coordenação de instâncias, aquisição de lock, lease com prazo e renovação.
Kubernetes: Leases, para uso de objetos Lease em coordenação, heartbeats e eleição de componentes.
Kubernetes API: Lease v1, para campos como holderIdentity, leaseDurationSeconds, renewTime e leaseTransitions.

As fontes sustentam o mecanismo de coordenação. Tempos, garantias do armazenamento, política de failover e proteção dos efeitos precisam ser testados no ambiente adotado.