Event sourcing para agentes de IA: quando usar

O estado atual pode esconder a decisão que criou o problema

Um agente acompanha uma oportunidade comercial. Pela manhã, o CRM mostra proposta_enviada. Depois, um vendedor altera o estágio, o cliente responde por outro canal e uma automação cancela a próxima ação. No fim do dia, o registro mostra aguardando_cliente.

Esse estado informa onde o processo terminou. Ele não explica, sozinho, quais fatos aconteceram, em que ordem, sob qual versão da política e por que uma tarefa foi criada e depois cancelada.

Event sourcing é um padrão em que mudanças relevantes são registradas como eventos duráveis. O estado atual passa a ser uma projeção desses fatos, em vez de ser o único registro preservado. A empresa consegue reconstruir a trajetória de um objeto, criar novas visões e investigar uma decisão sem depender de campos sobrescritos.

Para agentes de IA, o padrão pode ser útil quando contexto, aprovação, execução e correção precisam permanecer ligados ao processo. Também pode adicionar complexidade demais em rotinas simples. A decisão correta começa pelo trabalho operacional, não pela vontade de adotar uma arquitetura sofisticada.

O que event sourcing significa na prática

Em um sistema convencional, uma atualização substitui parte do estado:

oportunidade.status = "aguardando_cliente"

Com event sourcing, o sistema preserva fatos que produziram a mudança:

proposta_enviada
resposta_cliente_recebida
objecao_classificada
followup_cancelado
oportunidade_movida_para_aguardando_cliente

Cada evento representa algo que aconteceu e foi aceito pela autoridade daquele processo. Uma projeção consome a sequência e produz a visão atual para CRM, painel, fila ou agente.

O evento costuma incluir:

identificador único;
tipo e versão;
objeto empresarial;
versão esperada do objeto;
horário de ocorrência e de registro;
identidade do produtor;
cliente, conta e ambiente;
dados mínimos do fato ou referência protegida;
política e aprovação relevantes;
identificador de correlação;
relação com evento causador;
classificação e retenção.

O registro de eventos precisa ser append-only para o fluxo comum. Correções entram como novos eventos. Alterar silenciosamente um fato antigo destruiria justamente a capacidade de reconstrução que motivou o padrão.

Evento de domínio, log e trace cumprem trabalhos diferentes

Esses registros podem parecer semelhantes, mas possuem compromissos distintos.

Evento de domínio altera a história do objeto

pagamento_confirmado, proposta_aprovada e acesso_revogado representam fatos reconhecidos pelo negócio. Eles podem mudar projeções e autorizar novas etapas.

Log explica o comportamento de um componente

Uma integração registra timeout, payload rejeitado ou credencial vencida. O log ajuda a diagnosticar o componente, mas não deve mudar automaticamente o estado do processo.

Trace conecta a trajetória de uma execução

O tracing de agentes de IA mostra chamadas, ferramentas, tentativas e tempos dentro de uma unidade. Ele ajuda a investigar como a execução ocorreu.

Um trace pode ser descartado conforme a política de observabilidade. Um evento que sustenta o estado de um contrato, pedido ou aprovação pode precisar de outra retenção e outra autoridade.

A pergunta decisiva é simples: este registro descreve um fato empresarial aceito ou apenas algo que a tecnologia tentou fazer?

Event sourcing, outbox e fonte da verdade também são distintos

Event sourcing preserva fatos e deriva estado

Seu objeto central é a trajetória do agregado. O estado atual pode ser reconstruído a partir dos eventos válidos.

Outbox entrega eventos para outros componentes

O padrão outbox para agentes de IA reduz a lacuna entre gravar uma mudança local e publicar a mensagem correspondente. Uma solução pode usar outbox sem event sourcing. Também pode registrar eventos como fonte principal e usar outbox para distribuí-los.

Fonte da verdade define autoridade

A fonte da verdade para agentes de IA determina qual sistema governa cada objeto, campo e evento. Event sourcing não concede autoridade a qualquer mensagem armazenada. O evento só entra na história quando o produtor, a política e a confirmação são válidos para aquele fato.

Guardar todas as mensagens recebidas não transforma uma fila em sistema de registro.

Quando o padrão merece consideração

Event sourcing tende a fazer sentido quando o processo reúne várias destas condições:

decisões relevantes dependem da ordem dos fatos;
o estado atual não explica a trajetória necessária para auditoria;
correções precisam preservar o histórico anterior;
regras mudam e a empresa precisa saber qual versão atuou;
várias projeções consomem a mesma sequência;
agentes e pessoas podem agir sobre o mesmo objeto;
o processo exige reconstrução depois de falha ou migração;
novas leituras históricas podem ser criadas sem alterar a origem;
disputas, aprovações ou obrigações exigem evidência durável;
o custo de um estado inexplicável supera a complexidade do padrão.

Exemplos possíveis:

jornada de pedido com alterações, reserva, faturamento e cancelamento;
onboarding de cliente com dependências, aprovações e acessos;
gestão de contrato com versões, aceite e obrigações;
processo financeiro com preparação, aprovação, execução e conciliação;
operação comercial em que compromissos mudam por CRM, agenda e canais;
concessão e revogação de permissões para agentes.

O padrão não deve ser escolhido apenas porque o sistema usa filas ou webhooks. Muitas integrações precisam de eventos sem precisar reconstruir todo o estado a partir deles.

Quando um histórico simples resolve melhor

Uma tabela com estado atual e trilha de auditoria costuma ser suficiente quando:

o objeto possui poucas transições;
a trajetória raramente participa de decisões futuras;
uma única aplicação governa o processo;
relatórios usam principalmente o estado atual;
correções podem ser registradas em histórico convencional;
a equipe não possui capacidade para operar projeções e migrações;
o impacto de reconstruir uma unidade manualmente é baixo.

Um agente que classifica perguntas internas e encaminha cada uma para uma fila pode precisar de logs, métricas e registro da classificação. Transformar toda essa rotina em event sourcing pode criar mais infraestrutura do que capacidade operacional.

Complexidade também produz risco. Um padrão útil no processo errado vira uma dívida que exige especialistas para responder perguntas que antes cabiam em uma consulta simples.

Comece pelo agregado e pelos invariantes

O agregado é a fronteira que recebe comandos e protege regras antes de aceitar novos eventos. Ele deve representar uma unidade que o negócio reconhece.

Exemplos:

oportunidade;
pedido;
contrato;
onboarding;
solicitação de acesso;
caso de atendimento;
unidade de cobrança.

Para cada agregado, defina:

identificador estável;
estado inicial;
comandos aceitos;
eventos possíveis;
regras que precisam permanecer verdadeiras;
autoridade para cada transição;
versão usada para concorrência;
condição de encerramento;
retenção e acesso;
responsável operacional.

Uma regra pode dizer que um contrato cancelado não aceita nova ativação sem reabertura autorizada. Outra pode impedir duas aprovações para a mesma versão de uma proposta.

O agente prepara interpretação e opção. O componente que recebe o comando valida estado, versão, permissão e regra antes de anexar o evento.

Separe comando, evento e projeção

Misturar essas três camadas cria registros ambíguos.

Comando expressa uma intenção

criar_followup, aprovar_proposta ou revogar_acesso pedem uma mudança. O comando pode ser recusado.

Evento registra um fato aceito

followup_criado, proposta_aprovada ou acesso_revogado entram depois da validação e da confirmação exigida.

Projeção entrega uma visão útil

Painel comercial, fila de pendências, timeline do cliente e contexto do agente podem ser projeções diferentes da mesma história.

Um agente sugerir aprovar_proposta não produz proposta_aprovada. Entre os dois existem autoridade, política, estado e confirmação.

Essa separação reduz um erro recorrente: registrar texto plausível como fato operacional.

Modele eventos como fatos estáveis

Bons nomes descrevem algo concluído:

documento_validado;
revisao_solicitada;
pagamento_confirmado;
agenda_reservada;
consentimento_revogado;
caso_encerrado_com_pendencia.

Evite nomes como:

agente_processou;
fluxo_ok;
resultado_gerado;
etapa_finalizada.

Esses nomes falam da tecnologia e escondem o objeto empresarial.

Um evento deve carregar o necessário para preservar o fato, sem copiar indiscriminadamente documentos, conversas ou dados pessoais. Conteúdo sensível pode permanecer na fonte autorizada, com referência, versão e política de acesso.

Preserve ordem sem inventar certeza global

Dentro de um agregado, use uma sequência crescente ou controle de versão. Um novo evento só entra quando a versão esperada corresponde ao estado atual.

Exemplo:

contrato_id: C-208
versao_esperada: 12
evento: renovacao_aprovada

Se outra ação já criou a versão 13, o comando precisa reler o estado e ser avaliado novamente.

Não dependa apenas do horário. Relógios podem divergir, eventos podem chegar atrasados e registros podem ser importados depois. Ordem total entre todos os objetos da empresa raramente é necessária ou viável.

Preserve:

ordem por agregado;
vínculo causal quando um evento inicia outro processo;
horário do fato;
horário de registro;
versão do contrato;
estado para eventos atrasados ou fora de ordem.

A idempotência em agentes de IA impede que reentregas anexem o mesmo fato ou repitam a consequência.

Crie projeções com finalidade e dono

Uma projeção transforma eventos em uma visão de leitura.

Possibilidades:

estado atual do pedido;
timeline para atendimento;
pendências por responsável;
contexto resumido para o agente;
indicadores de prazo;
histórico de aprovações;
fila de reconciliação.

Cada projeção precisa declarar:

eventos consumidos;
versão do projetor;
campos gerados;
atraso esperado;
mecanismo de reconstrução;
regra para evento desconhecido;
fonte para conferência;
dono e consumidores.

Uma projeção é derivada. Ela pode ser apagada e reconstruída quando o desenho permite. O event store permanece como registro dos fatos aceitos.

O agente não deveria usar uma projeção atrasada para executar uma consequência sensível sem revalidar a versão atual do agregado.

Planeje replay antes de precisar dele

Replay processa novamente eventos para reconstruir uma projeção ou aplicar uma nova leitura histórica. Ele pode corrigir uma visão quebrada e também pode multiplicar efeitos se consumidores não forem desenhados para repetição.

Antes de executar replay:

delimite agregados e período;
congele ou versiona a projeção afetada;
valide contratos de eventos antigos;
separe consumidores de leitura de consumidores com efeito externo;
execute em ambiente controlado;
compare contagens e estados;
registre lacunas e eventos inválidos;
faça a troca da projeção com critério de aceite;
monitore consumidores;
preserve caminho de retorno.

Um replay para recalcular um painel não deve reenviar e-mails, recriar tarefas ou refazer cobranças. Projetores precisam ser puros quando possível. Efeitos externos exigem outra política e outra autorização.

Use snapshots sem transformar cópia em autoridade

Reconstruir um agregado com muitos eventos pode ficar lento. Um snapshot guarda o estado derivado até determinada versão. A leitura carrega o snapshot e aplica os eventos posteriores.

O snapshot precisa incluir:

agregado e versão;
schema do estado;
versão do projetor;
último evento incluído;
data de criação;
integridade verificável;
regra de invalidação;
retenção.

Ele acelera a reconstrução. Não substitui os eventos. Se snapshot e sequência divergem, a arquitetura precisa detectar e reconstruir a cópia.

Evolua contratos sem perder a história

Eventos antigos continuam existindo depois que o processo muda. Renomear campo ou alterar significado sem estratégia pode tornar a reconstrução impossível.

Opções comuns incluem:

consumidor aceitar várias versões;
adaptador converter versões antigas durante leitura;
novo tipo de evento para uma mudança semântica;
migração controlada com trilha preservada;
projeções versionadas durante a transição;
período de convivência entre consumidores.

O contrato de dados para agentes de IA ajuda a definir estrutura, semântica, compatibilidade e responsabilidade. O controle de mudanças deve promover eventos, validadores, projeções e consumidores como um conjunto testado.

Nunca mude silenciosamente o significado de um campo antigo. Uma reconstrução precisa interpretar cada evento conforme o contrato vigente quando ele foi produzido.

Defina correção, exclusão e retenção

O padrão append-only não elimina obrigações de privacidade, segurança ou correção.

Evite colocar dados pessoais e conteúdo sensível no evento quando uma referência protegida atende ao caso. Quando a remoção for obrigatória, a arquitetura pode precisar de:

criptografia com descarte controlado de chave;
tokenização;
referência para conteúdo armazenado fora do event store;
eventos de correção;
projeções que deixam de exibir dado inválido;
procedimento formal de expurgo;
registro de que uma operação de privacidade ocorreu, sem preservar o conteúdo removido.

A retenção de dados para agentes de IA deve considerar evento, projeção, snapshot, backup e cópia usada em teste.

Append-only é uma regra arquitetural. Ela continua subordinada às políticas e obrigações aplicáveis ao dado.

Monitore a saúde do registro e das projeções

Acompanhe:

eventos aceitos e recusados por tipo;
conflitos de versão;
eventos desconhecidos;
atraso por projeção;
falhas de projeção;
agregados que não reconstruíram;
diferença entre projeção e fonte autorizada;
replays executados;
duração e custo de reconstrução;
snapshots inválidos;
comandos repetidos;
correções por classe;
acessos ao histórico sensível;
impacto no prazo do processo.

Um painel técnico pode mostrar atraso de cinco mil eventos. O alerta operacional precisa informar quais pedidos, contratos ou atendimentos estão com visão desatualizada e quem decide a contenção.

Teste as falhas que comprometem a história

Inclua cenários como:

dois comandos usam a mesma versão esperada;
o mesmo evento chega novamente;
um evento antigo aparece depois de uma versão nova;
projetor falha no meio do lote;
replay começa com consumidor externo habilitado;
snapshot possui versão incompatível;
evento desconhecido entra na sequência;
contrato antigo deixa de ser interpretado;
projeção fica atrasada durante uma ação sensível;
correção humana ocorre entre leitura e comando;
parte do histórico está indisponível;
restauração de backup duplica publicação;
expurgo de dado afeta projeções e snapshots.

Verifique a sequência, o estado reconstruído, as projeções, os efeitos externos e a evidência entregue ao responsável.

Checklist de decisão

[ ] O estado atual perdeu informação necessária para decisões ou auditoria?
[ ] Existe uma unidade empresarial clara para o agregado?
[ ] Comandos, eventos e projeções estão separados?
[ ] Cada evento representa um fato aceito por uma autoridade conhecida?
[ ] Ordem e concorrência são controladas por agregado?
[ ] Reentregas preservam idempotência?
[ ] Projeções possuem versão, atraso, dono e reconstrução?
[ ] Replay não dispara efeitos externos por acidente?
[ ] Snapshots podem ser validados e descartados?
[ ] Contratos antigos continuam interpretáveis?
[ ] Dados sensíveis possuem minimização, retenção e expurgo?
[ ] A equipe consegue operar falhas de projeção e reconstrução?
[ ] O benefício do histórico reconstruível paga a complexidade?

Preserve eventos quando a trajetória realmente importa

Event sourcing oferece uma base forte para processos em que a ordem dos fatos, a versão da decisão e a possibilidade de reconstrução possuem valor operacional. Ele ajuda agentes, sistemas e pessoas a trabalhar sobre uma história verificável, sem tratar o último campo salvo como explicação completa.

O padrão exige disciplina. Eventos precisam representar fatos estáveis. Projeções precisam ser reconstruíveis. Replay, snapshots, contratos, retenção e correções precisam existir antes da falha.

Use event sourcing quando a trajetória do processo é parte do produto operacional. Para rotinas simples, estado atual com histórico de auditoria pode entregar controle suficiente com menos peso. Arquitetura boa também sabe quando recusar sofisticação.