# Design — Memória da Sessão via Postgres Chat Memory

**Data:** 2026-08-11
**Status:** Aprovado pelo usuário, aguardando plano de implementação.

## Objetivo

O node atual de memória do AI Agent (`Memória da Sessão`, tipo
`memoryBufferWindow`/"Simple Memory") guarda o histórico da conversa só
em RAM do processo do n8n. Isso tem duas limitações reais de produção:
não sobrevive a um reinício do n8n (deploy, crash, atualização) — a
conversa em andamento "esquece" tudo — e não funciona em setups com
múltiplos workers (queue mode), já que cada worker teria sua própria
memória isolada. Este design troca esse node pelo node oficial `Postgres
Chat Memory`, que persiste o histórico num banco Postgres.

## Infraestrutura

O usuário vai provisionar **um container Postgres**, com **um banco de
dados por cliente/clínica** dentro desse container — mesma filosofia de
isolamento por cliente já usada nos outros parâmetros de configuração
(`docId` do Google Doc, `baseUrl`/`apiId` dos MCP Servers). Isso significa
que cada workflow de agente terá sua própria Credential Postgres no n8n,
apontando pro mesmo host/porta do container mas pro banco específico
daquele cliente.

## Escopo desta etapa

Aplicado só ao Z-PRO (`Agendamento - GChat - Z-PRO (clínica exemplo)`,
`yG2mi6ECBpPv4Hmn`), único workflow de agente em produção real até
agora. Klingo/SysLife/ClinicAll ainda não têm workflow de agente — o
padrão fica pronto pra replicar quando esses forem criados.

## Componentes

### Troca de node (porta `ai_memory` do AI Agent)

Sai: `Memória da Sessão` (`@n8n/n8n-nodes-langchain.memoryBufferWindow`).

Entra: `Memória da Sessão (Postgres)`
(`@n8n/n8n-nodes-langchain.memoryPostgresChat`, v1.4), com:

- `sessionIdType: customKey`, `sessionKey: ={{ $json.sessionId }}` —
  idêntico ao node atual, mesma expressão, mesmo comportamento de
  sessão por `protocol`/atendimento.
- `contextWindowLength: 20` — idêntico ao valor atual.
- `tableName: n8n_chat_histories` — nome padrão do node, **criado
  automaticamente na primeira execução**, sem setup manual de schema.
  Se outros clientes futuros usarem o mesmo Postgres (bancos separados
  por cliente, ver "Infraestrutura"), cada banco terá sua própria
  instância dessa tabela — sem risco de misturar histórico entre
  clientes, já que são bancos fisicamente separados.
- Credential `postgres` — criada manualmente pelo usuário na UI do n8n
  (mesmo padrão de todas as outras credenciais deste projeto), apontando
  pro banco específico do Z-PRO dentro do container.

### Migração de histórico

**Não há nada a migrar.** O histórico atual vive só em RAM — ao trocar
o node, conversas em andamento simplesmente recomeçam do zero na
próxima mensagem. Não é uma perda de dado nova introduzida por esta
mudança: é exatamente o que já acontece hoje a cada reinício do n8n,
só que agora deixa de acontecer daqui pra frente.

## Fora de escopo

- Aplicar o mesmo padrão em Klingo/SysLife/ClinicAll — fica para quando
  esses tiverem workflow de agente.
- Provisionar o container Postgres em si — infraestrutura de
  responsabilidade do usuário, fora do escopo deste design (que cobre
  só a integração no n8n).
- Qualquer política de retenção/limpeza de histórico antigo na tabela
  `n8n_chat_histories` — não solicitado, YAGNI por enquanto.

## Testes

Sem framework automatizado (workflow n8n). Validação manual: enviar uma
conversa de teste com múltiplas mensagens (protocolo novo), confirmar
que o agente mantém contexto entre mensagens (ex.: lembra o nome já
informado). Confirmar na tabela `n8n_chat_histories` do Postgres que o
histórico foi persistido de fato (consulta direta ao banco). Se
possível, reiniciar o processo do n8n (ou simular) e confirmar que uma
conversa em andamento mantém o histórico depois do reinício — validação
do ganho real desta mudança.