Estado da conversa em agentes de IA: Postgres, Redis ou outro

Estado da conversa em agentes de IA: Postgres, Redis ou outro

Para a maioria dos agentes de atendimento, o histórico de conversa deve ficar em um banco relacional como o Postgres, que oferece durabilidade, consulta flexível e retenção controlável. O Redis entra como apoio para o que é curto e rápido, como sessão ativa, trava de concorrência e deduplicação de mensagens, e não como o único lugar onde a conversa existe. Outras opções fazem sentido em casos específicos, e a escolha deve partir do que o negócio precisa consultar, por quanto tempo e com que risco de perda.

Principais pontos

• Separe histórico (o registro do que foi dito) de estado (em que etapa o fluxo está e o que já foi coletado). Eles têm requisitos de armazenamento diferentes.
• O Postgres é o padrão seguro como fonte de verdade: transações, consulta por cliente e período, backup e controle de acesso maduros.
• O Redis é excelente para expiração automática, travas e cache, mas usá-lo como único registro cria risco de perda e dificulta auditoria.
• Expiração é decisão de negócio e de LGPD, não detalhe técnico. Defina o prazo de retenção por finalidade antes de escolher a ferramenta.
• O custo operacional real está em quem cuida de backup, limpeza, migração e monitoramento, e não apenas na hospedagem.

O que é estado da conversa e por que não é só histórico?

Quando alguém pergunta como armazenar o histórico de conversa de um chatbot, em geral está misturando quatro coisas que merecem tratamento separado.

• Histórico de mensagens: o log cronológico do que cliente, agente e atendente humano disseram, com canal, horário e identificador da mensagem.
• Estado do fluxo: etapa atual, dados já coletados (por exemplo, número do pedido ou endereço), ações pendentes e se a conversa está com o agente ou com uma pessoa.
• Memória resumida: um resumo ou fatos extraídos de conversas anteriores, usados para dar continuidade sem reenviar tudo ao modelo.
• Metadados de controle: consentimento, idioma, preferências, motivo da transferência para humano e registro das decisões do agente.

O histórico quase sempre precisa durar e ser consultável. O estado do fluxo muda a cada mensagem e frequentemente pode expirar. A memória resumida precisa ser corrigível e apagável. Misturar tudo em uma única estrutura é a origem da maior parte das dores que aparecem depois, como conversas travadas, respostas fora de contexto e dados guardados por mais tempo do que deveriam.

Há ainda uma distinção importante: o que você guarda não é o que você envia ao modelo. O banco pode manter a conversa inteira, enquanto cada chamada recebe apenas um recorte útil. Isso conecta o armazenamento ao tema de janela de contexto em IA, e a prática descrita pela Anthropic em engenharia de contexto vai no mesmo sentido: selecionar o que entra no contexto, em vez de despejar tudo.

Quando o Postgres é a escolha certa?

O Postgres costuma ser o ponto de partida mais defensável para agentes de atendimento por motivos práticos.

• Durabilidade: gravações confirmadas sobrevivem a reinicializações, e backups e recuperação em ponto no tempo são recursos conhecidos e documentados.
• Consulta: você responde perguntas de negócio com SQL, como quais conversas ficaram abertas, quais foram transferidas para humano ou o que um cliente específico disse na semana passada.
• Estrutura mista: colunas tradicionais para o que é estável (cliente, canal, horário) e campos JSON para o que varia (dados coletados por fluxo).
• Transações: gravar a mensagem e atualizar o estado do fluxo de forma atômica evita o caso clássico de a mensagem ser salva e o estado não.
• Controle de acesso: permissões por papel e isolamento por linha ajudam quando mais de uma equipe ou cliente usa o mesmo banco.

Os custos também são reais. Alguém precisa operar o banco, ou pagar por um serviço gerenciado. A expiração não é automática: é preciso rotina de limpeza, e em volumes maiores vale particionar a tabela de mensagens por período para que apagar dados antigos seja simples. E consultas sobre texto livre dentro das mensagens pedem índices ou busca dedicada, caso contrário ficam lentas.

Para a operação típica de uma empresa pequena ou média que atende pelo WhatsApp, esses custos são administráveis e o ganho em auditoria compensa. Se você ainda está desenhando a integração com o canal, o guia de como integrar IA no WhatsApp da empresa ajuda a ver onde o armazenamento entra no fluxo.

Onde o Redis ajuda e onde ele atrapalha?

O Redis guarda dados em memória, com latência muito baixa e expiração nativa por chave. Isso o torna ideal para tudo que é efêmero.

• Sessão ativa: o estado da conversa em andamento, que pode expirar após um período de inatividade.
• Deduplicação: plataformas de mensagens podem reenviar a mesma notificação, e uma chave com prazo curto evita responder duas vezes.
• Trava por conversa: impede que duas execuções processem mensagens do mesmo cliente ao mesmo tempo e embaralhem a resposta.
• Agrupamento de mensagens: quando o cliente manda várias frases seguidas, o agente espera um instante e responde uma vez só.
• Cache de dados consultados, como status de pedido, para não bater no sistema de origem a cada turno.

O problema aparece quando o Redis vira a única cópia. A durabilidade depende da configuração de persistência e do plano contratado, e o modelo de dados não foi feito para perguntas do tipo mostre todas as conversas transferidas para humano no mês. Memória também é um recurso mais caro por volume do que disco, então guardar meses de histórico ali raramente é boa economia. E sem registro durável, fica difícil responder a um pedido de titular, investigar uma reclamação ou avaliar a qualidade do agente.

A regra simples: se perder esse dado for aceitável (uma sessão que recomeça), Redis serve. Se perder significar não conseguir provar o que foi dito ao cliente, grave também em banco durável.

E as outras opções: MongoDB, DynamoDB, SQLite, arquivos?

Não existe proibição de usar outras ferramentas. Cada uma tem um encaixe.

• Bancos de documentos, como MongoDB: combinam bem quando cada conversa é naturalmente um documento flexível e a equipe já domina a ferramenta. Em contrapartida, relatórios que cruzam conversas com clientes e pedidos ficam mais trabalhosos do que em SQL.
• DynamoDB e similares de nuvem: oferecem expiração por tempo de vida e escala sem administrar servidor. Servem bem a acesso por chave (buscar a conversa de um número), mas consultas exploratórias exigem planejamento prévio dos padrões de acesso.
• SQLite: funciona para protótipos, ferramentas internas e agentes rodando localmente. Para múltiplas instâncias escrevendo ao mesmo tempo, passa a ser limitação.
• Armazenamento de objetos: bom para guardar transcrições, áudios e anexos por longo prazo e a baixo custo, sempre com um índice em banco apontando para eles.
• Persistência de frameworks de agentes: muitas bibliotecas oferecem checkpoints de estado com adaptadores para Postgres, Redis e outros. Use o adaptador, mas confirme onde e por quanto tempo os dados ficam, porque o padrão pode ser memória volátil.

Se a empresa roda modelos localmente por questão de privacidade, o raciocínio se estende ao banco: manter tudo em infraestrutura própria só faz sentido se alguém assumir a operação. Vale ler sobre rodar um modelo local sem improvisar antes de decidir.

Como comparar por durabilidade, consulta, expiração e custo?

Use este guia de decisão como ponto de partida. Ele descreve tendências, não garantias, e depende de configuração e fornecedor.

• Durabilidade: Postgres e bancos de documentos ou de nuvem gerenciados são adequados como registro. Redis exige cuidado com persistência e réplica. SQLite depende de um único arquivo e de quem faz cópia dele.
• Consulta: Postgres lidera para perguntas variadas e cruzamento com outros dados. DynamoDB e Redis são fortes em acesso por chave, fracos em exploração. Bancos de documentos ficam no meio.
• Expiração: Redis, DynamoDB e MongoDB têm mecanismos nativos de tempo de vida. No Postgres, você cria a rotina, de preferência com partições por período.
• Custo operacional: serviço gerenciado reduz trabalho, mas não elimina decisões de backup, acesso, retenção e monitoramento. Um Redis a mais é mais uma peça para vigiar, e isso conta.
• Auditoria: quem precisa reconstruir a conversa, as ferramentas chamadas e a transferência para humano se beneficia de um registro único e consultável.

Uma arquitetura comum e econômica em complexidade é Postgres como fonte de verdade e Redis opcional para o que é efêmero. Para pequenas operações, só o Postgres já basta, e adicionar Redis pode esperar até que exista um problema medido de latência ou concorrência.

Como tratar expiração, LGPD e dados sensíveis?

Expiração não deve ser definida pelo que o banco facilita, e sim pelo que a finalidade exige. Uma conversa de suporte pode precisar ficar disponível para garantia ou contestação, enquanto o estado temporário de um fluxo de agendamento pode sumir quando termina. Cada categoria de dado merece um prazo e uma justificativa registrados.

Alguns cuidados práticos:

• Guarde o mínimo: se o agente não precisa do documento do cliente depois da verificação, não o mantenha no histórico em texto aberto.
• Mascare ou separe dados sensíveis que clientes digitam espontaneamente, como documentos e informações de saúde.
• Garanta que dá para localizar e apagar os dados de uma pessoa, incluindo resumos e memórias derivadas, não só as mensagens originais.
• Trate transcrições de áudio como parte do histórico, com as mesmas regras de retenção.
• Registre onde o banco está hospedado. Se o provedor ou o modelo estiver fora do Brasil, veja o que a LGPD exige em transferência internacional de dados com IA.
• Restrinja quem lê o histórico. Acesso amplo a conversas de clientes é risco interno, e também um assunto de medir produtividade sem virar vigilância quando a equipe é monitorada.

Para orientação oficial sobre proteção de dados no país, a página da ANPD é a referência primária. Questões jurídicas específicas, como base legal e prazo de guarda, pedem validação com quem responde pela área jurídica da empresa.

Como escolher na prática: mapear, limitar, pilotar, transferir

O método de trabalho que usamos para agentes segue quatro movimentos, e eles se aplicam bem à decisão de armazenamento.

• Mapear: liste o que o fluxo precisa lembrar durante a conversa, o que precisa consultar depois e quem precisa ler. Anote o que acontece hoje, com planilha, CRM ou histórico do WhatsApp.
• Limitar: defina prazos de retenção, campos que não serão guardados e o tamanho do histórico enviado ao modelo a cada turno.
• Pilotar: rode um fluxo real com registros de cada mensagem, decisão e transferência para humano, e uma métrica de sucesso combinada de antemão. Meça se o agente perdeu contexto, repetiu pergunta ou respondeu duas vezes.
• Transferir: documente o esquema, a rotina de limpeza, o backup e quem responde por cada parte. Só então decida se expande, ajusta ou encerra.

Cenário ilustrativo: uma loja de serviços atende pedidos de orçamento pelo WhatsApp. O agente coleta nome, tipo de serviço e endereço, e transfere para um vendedor quando o cliente pede valores fora do padrão. No mapeamento, a equipe percebe que o vendedor precisa ver a conversa inteira e o que o agente já coletou, e que o fluxo de coleta pode ser descartado dias depois de concluído. A decisão é guardar mensagens e decisões em Postgres, com prazo de retenção definido, manter o estado do fluxo em uma tabela com data de expiração, e deixar o Redis fora do piloto. Se surgirem respostas duplicadas por reenvio de notificações, aí sim se acrescenta uma chave de deduplicação com prazo curto. Os números, nomes e prazos são fictícios e servem apenas para mostrar a ordem das decisões.

Um detalhe que costuma passar despercebido é a idempotência: gravar a mesma mensagem duas vezes depois de uma nova tentativa gera histórico confuso. Usar o identificador da mensagem do canal como chave única resolve boa parte, e o tema de retentativas é tratado em erros e retentativas no n8n.

Checklist antes de colocar em produção

• O histórico tem uma fonte de verdade durável, com backup testado de restauração?
• Cada mensagem tem identificador único do canal para evitar duplicidade?
• O estado do fluxo tem prazo de expiração e um caminho claro para retomar ou encerrar conversas paradas?
• Há prazo de retenção por tipo de dado, e uma rotina que realmente apaga?
• É possível localizar e excluir todos os dados de uma pessoa, incluindo resumos?
• O acesso ao histórico é restrito por papel e fica registrado?
• A transferência para humano leva o contexto junto, sem o atendente precisar perguntar tudo de novo?
• Há observabilidade mínima: erros de gravação, latência de leitura e conversas sem estado recuperado.

Sobre esse último ponto, o conceito de observabilidade e as convenções para telemetria de IA generativa do OpenTelemetry são uma base útil para padronizar o que se registra.

Perguntas frequentes

Posso guardar o histórico do chatbot só no Redis? Pode para protótipos ou para conversas em que perder a sessão é aceitável. Para atendimento real, em que você pode precisar provar o que foi dito ao cliente, recomendamos um registro durável em banco, usando o Redis apenas para o que é temporário.

Preciso enviar todo o histórico ao modelo a cada mensagem? Não. O banco pode guardar tudo, mas o modelo deve receber apenas o recorte necessário, como as últimas mensagens, o estado do fluxo e um resumo. Isso reduz custo por chamada e evita que informação irrelevante confunda a resposta.

Quanto tempo devo guardar as conversas? Não há prazo único. Ele depende da finalidade (suporte, garantia, contestação), de obrigações legais do seu setor e do que você consegue justificar. Defina por categoria de dado, registre a justificativa e valide com o responsável jurídico ou de proteção de dados.

Um banco gerenciado resolve a operação? Reduz o trabalho de manutenção do servidor, mas não decide por você retenção, acesso, backup testado e monitoramento. Esses pontos continuam sendo responsabilidade da empresa, e é por isso que vale documentá-los e definir um responsável na entrega do piloto.

Fontes

• Anthropic: Effective context engineering for AI agents
• OpenTelemetry: observability concepts
• OpenTelemetry: semantic conventions for generative AI
• ANPD: Autoridade Nacional de Proteção de Dados