Para evitar que dois agentes de IA sobrescrevam alterações no mesmo registro do CRM, a gravação precisa conferir se os dados usados na decisão ainda são válidos. Quando a API oferece atualização condicional, envie o identificador de versão recebido na leitura. Se houver conflito, recarregue o registro e reavalie a proposta antes de tentar novamente.
Filas e bloqueios também podem ajudar, mas sua proteção depende do desenho completo. Um bloqueio usado apenas pelos agentes não impede uma edição humana fora desse caminho. Comece pelo contrato da API do CRM e pelas regras dos campos envolvidos; depois escolha a coordenação necessária. Não presuma que todo CRM aceita ETag ou que um campo personalizado cria comparação atômica.
Resumo rápido
- O risco aparece entre ler um registro e gravar uma decisão baseada nessa leitura.
- A comparação de versão precisa acontecer junto da escrita, no sistema responsável pelo dado.
- Um conflito pede nova leitura e revisão das premissas, não troca cega do token.
- Locks com expiração podem perder validade enquanto um processo ainda trabalha.
- Filas exigem tratamento de duplicatas, falhas e outros caminhos de edição.
O que acontece quando dois agentes leem o mesmo contato
Imagine que um agente prepara uma atualização de qualificação enquanto outro registra uma conversa. Ambos leem a etapa “novo contato”. Antes da primeira gravação, uma vendedora já pode ter marcado uma reunião. Uma proposta baseada na fotografia antiga pode regredir o negócio para uma etapa anterior, mesmo que o texto gerado esteja correto para o contexto que o agente recebeu.
Esse problema não exige inteligência artificial: integrações comuns também podem sofrer atualização perdida, quando uma escrita substitui trabalho de outra. Agentes ampliam a janela de exposição quando consultam documentos ou aguardam respostas antes de gravar. Ainda assim, a solução pertence principalmente à aplicação e ao contrato de persistência, não a uma instrução para “tomar cuidado”.
Defina quem pode alterar cada campo e quais transições são permitidas. Um agente de enriquecimento cadastral não precisa editar a etapa comercial. Um registro de conversa pode ser acrescentado como evento, em vez de substituir um campo de histórico completo. Essas escolhas reduzem disputas e complementam a organização de sistemas com múltiplos agentes de IA.
Atualização condicional e controle otimista
O controle otimista permite trabalhar sem reservar o registro durante toda a análise. Na escrita, o destino verifica uma condição: a versão atual ainda é aquela que a aplicação leu? Se não for, a atualização deve ser recusada. Fazer uma consulta separada antes de gravar não resolve, pois outra alteração pode ocorrer entre essas duas chamadas.
Um exemplo documentado é o Microsoft Dataverse. A API retorna um ETag que pode ser enviado em If-Match para uma atualização condicional. Uma versão divergente pode produzir HTTP 412. O suporte depende das capacidades da tabela; os detalhes estão na documentação de operações condicionais do Dataverse. Trate o ETag como token opaco: não calcule sua própria versão a partir dele.
Se a API não oferece mecanismo equivalente, um contador personalizado só funciona quando o destino compara e atualiza esse contador atomicamente. Ler o contador, compará-lo no middleware e enviar um PATCH comum deixa uma janela de corrida. Um serviço central pode coordenar os escritores que passam por ele; edições e integrações externas continuam precisando de tratamento.
Após um conflito, leia novamente o estado e confira as condições do negócio. Um endereço complementar talvez possa ser mesclado; uma troca de responsável exige regra própria. Limite as tentativas e encaminhe disputas persistentes para revisão. Recuo entre tentativas reduz pressão, mas não torna semanticamente correta uma alteração desatualizada.
Transações no banco e bloqueios distribuídos
Quando sua equipe controla o banco, pode colocar validações e gravações relacionadas numa transação curta. O PostgreSQL documenta mecanismos de bloqueio de linhas, incluindo SELECT FOR UPDATE, que coordenam operações conflitantes no banco. Isso não transforma uma chamada externa ao CRM em parte da mesma transação e não deve manter uma conexão presa durante uma longa conversa com o modelo.
O nível de isolamento também muda o comportamento. A documentação do PostgreSQL descreve diferenças entre Read Committed, Repeatable Read e Serializable. Transações podem precisar de repetição após falhas de serialização. Portanto, “está numa transação” não explica sozinho quais conflitos foram cobertos. Teste o comportamento da operação completa, incluindo as condições que envolvem vários registros.
Um lock distribuído é uma reserva coordenada entre processos. A documentação do Redis apresenta requisitos e hipóteses de implementação, incluindo valor exclusivo para reconhecer o dono e liberação condicionada a esse valor. Se um processo apagar uma chave sem conferir a propriedade, pode liberar a reserva de outro processo que entrou depois.
A expiração evita reservas eternas, mas traz outro problema: o processo antigo pode continuar trabalhando depois do prazo. Uma pausa ou falha de rede pode deixá-lo sem exclusividade. Para proteger uma escrita sensível, o destino precisa rejeitar operações antigas por versão ou por um token de ordenação apropriado. Renovar o prazo e usar um lock, isoladamente, não garante esse comportamento.
Escolha o tempo de vida a partir de medições e do modelo de falhas; não existe intervalo universal em segundos. Para uma equipe pequena, adicionar Redis sem necessidade pode aumentar a complexidade. Sempre pergunte se a atualização condicional nativa já resolve o caso e como o sistema se comportará quando a coordenação ficar indisponível.
Filas, duplicatas e escolha do mecanismo
Uma fila por contato pode concentrar propostas num consumidor que decide a ordem de aplicação. Para isso funcionar, configure a entrega, a concorrência de consumidores e a identificação da entidade conforme o produto utilizado. Não se deve presumir que qualquer fila oferece ordem global ou preserva a cronologia original de eventos recebidos de sistemas diferentes.
Prepare também a repetição de mensagens. Se o CRM confirmou a alteração e o consumidor caiu antes de registrar a conclusão, a mensagem pode voltar. A aplicação precisa reconhecer a operação ou consultar seu resultado antes de repetir o efeito. Concorrência e duplicação são problemas relacionados, mas uma fila organizada não elimina automaticamente nenhum deles.
| Mecanismo | Quando considerar | O que conferir |
|---|---|---|
| Versão na escrita | API com atualização condicional | Comparação atômica e política de conflito |
| Transação local | Dados sob controle do mesmo banco | Isolamento, duração e repetição de falhas |
| Lock distribuído | Coordenação necessária entre processos | Expiração, propriedade e proteção no destino |
| Fila por entidade | Concentração de propostas para um contato | Ordenação configurada, duplicatas e edições externas |
Exemplo: empresa de manutenção em Belo Horizonte
Considere uma empresa fictícia de manutenção comercial em Belo Horizonte. Um agente propõe a classificação das solicitações e outro prepara o próximo contato com o cliente. O caso é ilustrativo, sem métricas de resultado. A empresa quer preservar edições da equipe de atendimento enquanto experimenta automação no cadastro.
Um contato informa que prefere atendimento à tarde. Enquanto o agente prepara o resumo, uma atendente confirma uma visita e muda a etapa da oportunidade. O executor recebe a proposta do agente com a versão antiga do registro. Se o CRM tiver atualização condicional configurada, a tentativa é rejeitada por divergência de versão, sem forçar a etapa anterior.
O serviço lê o registro novamente. A preferência de horário ainda pode ser acrescentada, mas o agendamento não deve ser refeito. A regra do exemplo limita o agente a registrar a observação e preserva a visita confirmada. Para transições contraditórias, a proposta vai para revisão humana. O mesmo cuidado vale ao automatizar o follow-up de leads com IA e CRM.
A equipe valida o fluxo com dois processos de teste: ambos leem a mesma versão; um grava; o outro tenta gravar depois. O resultado esperado é a rejeição da segunda proposta, seguida de reavaliação. Em outro cenário, a resposta do servidor se perde e o serviço precisa descobrir se a operação ocorreu. Só depois desses ensaios faz sentido medir retrabalho e tempo de atendimento.
Erros comuns
Dar ao agente o objeto inteiro para regravar. Atualize somente campos autorizados e necessários. Mesmo uma atualização parcial pode contrariar uma mudança em outro campo, por isso combine escopo reduzido com validação das premissas. As permissões de agentes de IA precisam aparecer no executor, além do prompt.
Substituir a versão depois de um conflito. Copiar o token novo para a proposta antiga contorna a proteção. Recarregue os dados, compare mudanças e decida se a intenção ainda vale. Uma nova leitura não autoriza automaticamente uma gravação.
Tratar qualquer timestamp como versão. Um horário pode não ter precisão suficiente ou não cobrir todas as alterações relevantes. Use o mecanismo documentado pelo destino e teste sua semântica. Também não assuma que todo hash ou contador personalizado funciona como ETag.
Confiar só no lock do middleware. Se uma integração externa não usa o mesmo protocolo, ela pode alterar o contato durante a reserva. Mapeie todos os escritores e mantenha a proteção no ponto da gravação sempre que possível.
Ocultar rejeições. Registre operação, campo, versão esperada, resultado e motivo de encaminhamento. Evite copiar conversas e documentos completos para logs. Um identificador técnico associado a uma pessoa também pode ser sensível; controle acesso e retenção conforme a política da empresa.
Perguntas frequentes
ETag funciona em qualquer CRM?
Não. Consulte a documentação do endpoint e da entidade. O exemplo do Dataverse não demonstra suporte em outros fornecedores. Um cabeçalho ignorado pelo servidor não oferece controle de concorrência, mesmo que a aplicação consiga enviá-lo.
Um campo de versão personalizado resolve?
Somente quando há comparação e gravação atômicas no caminho que controla o dado. Fazer essa comparação na aplicação e depois enviar uma atualização comum mantém uma janela de conflito entre as chamadas.
Redis impede dois agentes de gravar ao mesmo tempo?
Ele pode participar da coordenação entre processos que seguem o protocolo. A segurança depende de expiração, falhas e validação no destino. Um processo com reserva vencida pode continuar executando; esse caso precisa de proteção específica.
Qual tentativa deve vencer quando há conflito?
A regra é do negócio. Não escolha automaticamente a resposta que terminou por último. Pode ser necessário preservar a decisão humana, mesclar campos independentes ou pedir revisão. Documente a regra e guarde evidência da escolha aplicada.
Uma fila dispensa controle de versão?
Não necessariamente. Ela organiza apenas os caminhos que participam do fluxo. Edições humanas, integrações externas e repetição de mensagens continuam exigindo tratamento. Use testes para demonstrar quais escritores e falhas a arquitetura realmente cobre.
