Controle de concorrência em agentes de IA

Duas decisões corretas podem produzir um resultado errado

Um agente consulta uma oportunidade no CRM, encontra a proposta enviada e prepara uma tarefa de follow-up. Enquanto ele analisa o histórico, o vendedor recebe a resposta do cliente e marca a oportunidade como perdida. Segundos depois, o agente grava a tarefa que fazia sentido para o estado anterior.

Nenhuma execução duplicou a mesma ação. Nenhuma API apresentou erro. O problema nasceu porque duas partes trabalharam sobre versões diferentes do mesmo objeto.

Controle de concorrência em agentes de IA é o conjunto de regras que impede pessoas, agentes, integrações e workers de aplicar mudanças incompatíveis ao mesmo estado. A arquitetura precisa reconhecer quando o contexto usado na decisão envelheceu, escolher quem pode avançar e preservar o conflito para tratamento.

Essa disciplina ganha importância quando o agente combina análise demorada com ferramentas rápidas. O texto pode levar minutos para ser preparado. A gravação no sistema acontece em milissegundos. Entre uma etapa e outra, a realidade operacional continua mudando.

O que é uma condição de corrida

Uma condição de corrida ocorre quando o resultado depende da ordem ou do momento em que operações concorrentes são executadas.

Considere um cadastro com saldo disponível para uma reserva:

execução A lê saldo igual a uma unidade;
execução B lê o mesmo saldo;
A conclui que pode reservar;
B chega à mesma conclusão;
as duas gravam a reserva;
o sistema termina com duas promessas para uma unidade.

O mesmo padrão aparece em agentes que:

alteram estágio de oportunidade;
reservam horário de agenda;
aprovam ou rejeitam documento;
atribuem chamado para uma fila;
atualizam estoque;
encerram pendência financeira;
concedem acesso;
enviam comunicação baseada em consentimento;
executam tarefas que uma pessoa também pode concluir.

A resposta do modelo pode estar coerente com o contexto recebido. O erro ocorre porque esse contexto deixou de representar o estado vigente antes da consequência.

Concorrência, duplicidade e volume resolvem problemas diferentes

Esses controles costumam aparecer juntos, mas possuem funções próprias.

Idempotência protege contra repetição do mesmo efeito

A idempotência em agentes de IA impede que uma reentrega, retentativa ou reinício crie outra cobrança, mensagem ou tarefa para a mesma unidade.

Uma chave inédita, porém, não detecta que o objeto mudou. A tarefa pode ser criada uma única vez e continuar inadequada.

Rate limit protege capacidade

O rate limit para agentes de IA controla quantas operações pressionam modelos, APIs, bancos e filas humanas. Ele reduz saturação e distribui capacidade.

Executar uma chamada por vez pode reduzir colisões, mas não substitui a validação de estado. Uma pessoa ainda pode alterar o registro entre a leitura e a escrita.

Controle de concorrência protege a validade da mudança

Ele responde perguntas como:

a versão examinada ainda é a atual?
outra execução já assumiu esta unidade?
as mudanças podem ser combinadas?
o objeto precisa ser processado em sequência?
o conflito exige releitura, cancelamento ou decisão humana?

Os três mecanismos se complementam. Uma operação crítica pode precisar de limite de volume, chave idempotente e verificação de versão na mesma unidade.

Encontre a fronteira que precisa de consistência

Bloquear o sistema inteiro costuma custar caro e resolver o problema errado. A arquitetura deve identificar a menor unidade cuja mudança precisa permanecer coerente.

Essa unidade pode ser:

uma oportunidade;
um pedido;
uma parcela;
uma agenda e um intervalo;
um contrato e sua versão;
um chamado;
um item de estoque;
uma solicitação de acesso;
um cliente dentro de uma etapa específica.

Pergunte quais regras nunca podem ser violadas. Exemplos:

uma oportunidade encerrada não recebe nova próxima ação automática;
o mesmo horário não pode ser confirmado para duas pessoas;
uma parcela paga não volta para cobrança sem revisão;
um opt-out vigente bloqueia comunicação;
uma versão cancelada do contrato não pode ser aprovada;
uma tarefa assumida por uma pessoa não pode ser encerrada silenciosamente pelo agente.

A fronteira nasce dessas regras. O banco, a API ou o orquestrador deve aplicar a proteção perto do sistema que possui autoridade sobre o objeto.

Use controle otimista quando conflitos são ocasionais

Controle otimista permite que várias partes leiam o objeto. Na escrita, cada uma informa qual versão examinou. O sistema aceita a mudança somente quando essa versão continua vigente.

Um registro pode carregar:

oportunidade_id: OP-2481
versao_lida: 17
acao_proposta: criar_followup

Se a oportunidade permanece na versão 17, a operação pode avançar e gerar a versão 18. Se outra ação já criou a versão 18, a escrita é recusada por conflito.

Mecanismos comuns incluem:

número de versão;
ETag com cabeçalho If-Match;
comparação e troca;
coluna de última alteração, quando possui precisão e semântica adequadas;
condição no UPDATE que exige o estado esperado;
evento anexado somente sobre a versão esperada.

O controle otimista funciona bem quando colisões são pouco frequentes e reler o estado tem custo aceitável. Ele evita manter locks durante análise, consulta ao modelo ou aprovação humana.

A recusa não deve virar retentativa cega. O agente precisa reler o objeto, reconstruir a decisão e verificar se a finalidade continua válida.

Use serialização quando a ordem faz parte da regra

Alguns objetos recebem eventos cuja sequência altera o significado. Nesses casos, encaminhar todo o trabalho daquela unidade para a mesma partição ou fila pode simplificar o controle.

Exemplos:

eventos de um pedido processados pela chave do pedido;
mudanças de uma oportunidade consumidas pela chave da oportunidade;
comandos de uma conta financeira ordenados pela conta e competência;
atualizações de agenda serializadas por recurso e intervalo.

A serialização local reduz operações simultâneas sobre a mesma fronteira. Ela não cria ordem global para a empresa inteira, nem elimina eventos atrasados. O consumidor ainda precisa validar versão e reconhecer mensagens vencidas.

O event sourcing para agentes de IA mostra como preservar ordem por agregado e anexar fatos somente quando a versão esperada corresponde ao estado atual.

Use locks quando uma unidade precisa de posse temporária

Um lock concede a uma execução o direito temporário de trabalhar sobre uma unidade. Ele pode ser útil quando duas operações simultâneas seriam caras, quando o sistema não oferece versão condicional ou quando existe uma etapa curta que precisa de exclusão mútua.

Um lock operacional deve registrar:

objeto protegido;
proprietário da reserva;
unidade de trabalho;
horário de concessão;
prazo de validade;
heartbeat, quando a execução é longa;
motivo;
política de renovação;
condição para liberação;
evidência de recuperação.

Locks distribuídos falham de formas pouco intuitivas. Um worker pode pausar, perder conectividade, deixar o prazo vencer e continuar executando. Outro worker recebe o lock e os dois passam a acreditar que possuem autoridade.

Para reduzir esse risco, operações sensíveis podem usar um token de cercamento. Cada concessão recebe um número crescente. O sistema de destino aceita somente comandos com token mais novo que o último observado. Assim, uma execução antiga perde poder mesmo que continue viva.

Evite manter lock durante chamada longa ao modelo, pesquisa externa ou espera humana. Reserve próximo ao compromisso, valide o estado e conclua a etapa protegida rapidamente.

Revalide antes da consequência

A decisão costuma atravessar quatro momentos:

leitura do estado;
preparação da proposta;
autorização;
execução no sistema oficial.

Quanto maior o intervalo, maior a chance de o contexto vencer. Antes da consequência, releia os invariantes que sustentam a ação.

Para um follow-up comercial, verifique:

a oportunidade continua aberta;
o estágio ainda permite contato;
a próxima ação permanece ausente ou vencida;
o responsável não mudou;
o cliente não respondeu por outro canal;
consentimento e restrições continuam válidos;
a versão aprovada ainda é a atual.

O guia sobre freshness de dados para agentes de IA detalha validade temporal e revalidação. A concorrência acrescenta outra pergunta: alguém alterou o objeto desde a leitura usada pela decisão?

Aprovação humana também vence. Se a pessoa aprovou a versão 12 e o registro está na versão 14, a autorização precisa ser revista conforme a política. Guardar apenas “aprovado = sim” separa a decisão do objeto realmente examinado.

Separe mudanças combináveis de mudanças conflitantes

Nem toda concorrência exige bloqueio. Duas alterações podem atuar sobre campos independentes e ser combinadas com segurança.

Considere um cadastro de cliente:

uma rotina corrige o telefone;
outra adiciona uma tag interna;
uma terceira altera o status do contrato.

As duas primeiras podem ser compatíveis. A terceira pode mudar a elegibilidade de toda a operação.

Defina por objeto:

campos que aceitam merge;
campos derivados que devem ser recalculados;
transições exclusivas;
estados terminais;
ações que invalidam aprovações anteriores;
mudanças que pedem nova leitura completa;
conflitos que exigem pessoa com alçada.

O modelo pode ajudar a explicar diferenças ou preparar opções. A regra que aceita merge precisa ser determinística e aprovada pelo dono do processo.

Modele o conflito como um estado operacional

Tratar conflito como erro genérico convida retentativas sem contexto. Use estados que orientem a próxima decisão.

Exemplos:

conflito_de_versao;
objeto_alterado_durante_aprovacao;
posse_expirada;
acao_manual_detectada;
estado_terminal_encontrado;
merge_nao_permitido;
exige_reavaliacao;
exige_decisao_humana.

O registro deve incluir:

versão lida;
versão encontrada;
campos ou eventos que mudaram;
ação pretendida;
identidade concorrente, quando disponível;
consequência evitada;
regra aplicada;
responsável;
prazo e próxima ação.

Esse pacote transforma um 409 Conflict em informação operacional. A equipe entende o que mudou e decide sem reconstruir a história a partir de logs dispersos.

Evite estes atalhos

Confiar no timestamp do prompt

A data em que o contexto foi montado informa idade, mas não prova que nenhuma mudança ocorreu depois. Use versão do objeto ou consulta à fonte autorizada.

Fazer lock com um campo booleano

em_processamento = true sem proprietário, prazo e recuperação pode deixar unidades presas depois de reinício. Também não impede que um processo antigo grave após perder a posse.

Repetir automaticamente qualquer conflito

Um conflito indica mudança de realidade. Repetir a mesma decisão sobre o novo estado sem reavaliar pode produzir o efeito que o controle tentou impedir.

Bloquear durante aprovação humana

Pessoas podem levar minutos ou horas. Um lock longo paralisa trabalho legítimo e aumenta recuperação. Vincule a aprovação à versão e revalide no compromisso.

Serializar tudo

Uma fila única reduz throughput, aumenta atraso e cria ponto central de falha. Preserve ordem apenas onde a regra do objeto exige.

Delegar a garantia ao modelo

Instruir “verifique se algo mudou” ajuda o comportamento, mas a garantia depende de versão, condição de escrita, transação e autoridade do sistema de destino.

Exemplo: agente que atualiza o CRM

Um agente identifica oportunidades sem próxima ação e prepara uma recomendação.

Leitura

Ele recupera oportunidade, estágio, responsável, último contato, restrições e versão 31.

Preparação

O agente sugere criar uma tarefa para a próxima terça-feira. A saída carrega oportunidade_id, ação, motivo, fonte e versao_esperada = 31.

Mudança concorrente

Antes da gravação, o vendedor registra uma ligação, agenda retorno para segunda-feira e o CRM avança para a versão 32.

Compromisso

A integração tenta atualizar somente quando a versão permanece 31. O CRM recusa. O fluxo busca a versão 32, identifica próxima ação existente e encerra a recomendação como superada.

Evidência

O sistema registra que uma escrita vencida foi evitada, liga a recomendação à mudança do vendedor e não cria pendência desnecessária.

Esse desenho preserva o trabalho humano e impede que o agente transforme contexto antigo em obrigação nova.

Exemplo: agente de agendamento

Dois clientes escolhem o mesmo horário quase ao mesmo tempo.

A disponibilidade exibida na tela é uma consulta. A confirmação precisa usar uma operação atômica no sistema de agenda:

identificar recurso, início e fim;
tentar reservar sob condição de disponibilidade vigente;
aceitar somente uma operação;
devolver conflito para a outra;
buscar novas opções;
confirmar o compromisso no sistema oficial;
usar idempotência para impedir reserva repetida na retentativa.

Pedir ao agente que “confira antes” ainda deixa uma janela entre consulta e reserva. A garantia deve ficar na operação que cria o compromisso.

Monitore conflitos e contenção

Acompanhe:

conflitos de versão por objeto e processo;
escritas vencidas bloqueadas;
locks concedidos, renovados e expirados;
execuções que continuaram depois da perda de posse;
tempo de espera por unidade;
objetos com contenção frequente;
retentativas após conflito;
ações manuais detectadas durante execução;
aprovações invalidadas por mudança;
merges automáticos e recusados;
casos enviados para decisão humana;
consequências incorretas que escaparam do controle;
impacto no prazo e na capacidade do processo.

Conflito alto pode apontar arquitetura inadequada, fronteira ampla demais ou processo com muitos donos simultâneos. Também pode revelar que o agente demora tanto para decidir que o contexto vence com frequência.

O alerta precisa falar em linguagem de negócio. “A oportunidade mudou depois da análise; criação automática de tarefa foi cancelada; nenhum contato foi enviado” orienta melhor que uma sequência isolada de erros técnicos.

Teste as corridas que a produção vai criar

Inclua cenários como:

dois workers leem a mesma versão;
pessoa e agente atualizam o objeto em paralelo;
lock vence durante uma chamada lenta;
worker antigo continua depois da nova concessão;
aprovação ocorre e o objeto muda antes da escrita;
evento antigo chega depois do novo;
duas alterações compatíveis tentam merge;
duas transições incompatíveis disputam o estado;
fila reinicia com itens reservados;
operação confirma e a resposta se perde;
sistema de destino não oferece escrita condicional;
relógios divergem entre componentes.

Para cada teste, confirme estado final, quantidade de efeitos, versão, identidade, evidência, recuperação e impacto na unidade de trabalho.

Checklist de controle de concorrência

[ ] A fronteira de consistência representa um objeto empresarial claro?
[ ] As regras que nunca podem ser violadas estão registradas?
[ ] Leituras carregam versão ou condição verificável?
[ ] Escritas aceitam somente a versão esperada?
[ ] Conflitos provocam releitura e reavaliação?
[ ] Aprovações ficam vinculadas ao objeto e à versão examinada?
[ ] Locks possuem proprietário, prazo e recuperação?
[ ] Execuções antigas perdem poder depois da expiração?
[ ] Ordem é preservada somente onde a regra exige?
[ ] Mudanças combináveis e conflitantes estão separadas?
[ ] Ações manuais aparecem antes da retomada automática?
[ ] Idempotência protege repetições do mesmo efeito?
[ ] Métricas mostram conflitos evitados e impactos reais?
[ ] Testes cobrem concorrência humana, técnica e recuperação?

Autonomia segura depende de estado vigente

Um agente pode interpretar corretamente uma situação que já deixou de existir. Por isso, qualidade da resposta não basta para autorizar uma mudança.

Controle otimista, serialização, locks curtos e revalidação aproximam a decisão do estado oficial. Conflitos viram estados tratáveis, aprovações permanecem ligadas à versão examinada e execuções antigas perdem autoridade.

A empresa ganha velocidade quando agentes e pessoas conseguem trabalhar sobre o mesmo processo sem sobrescrever silenciosamente o que o outro acabou de decidir. O controle de concorrência preserva essa coordenação no ponto em que análise vira consequência.