Memória de agente no n8n: buffer, resumo e memória em Postgres

Sem memória, cada mensagem para o agente começa do zero — ele não lembra do que foi dito dois minutos atrás. A memória guarda o histórico da conversa e é o que permite um diálogo contínuo. O n8n oferece a Simple Memory, que é a mais fácil de começar, e serviços externos como Postgres, Redis e outros para quando a conversa precisa sobreviver ao reinício do servidor.

Um detalhe que decide a arquitetura

Direto da documentação: agentes podem usar memória, cadeias não. Se o seu caso exige lembrar de mensagens anteriores, você precisa de um agente — não há como contornar isso com cadeia.

As opções

Simple Memory

Guarda uma quantidade configurável de mensagens da sessão atual. É a mais simples de usar e resolve bem enquanto você está construindo e testando.

A limitação a conhecer antes de levar para produção: ela vive na instância. Reiniciou o n8n, o histórico se foi. E em instalação com vários trabalhadores, a mensagem seguinte pode cair em outro processo, que não tem aquele histórico.

Postgres Chat Memory

Guarda o histórico num banco. É a escolha natural para produção: sobrevive a reinício, funciona com vários trabalhadores e permite consultar as conversas depois — para auditoria, para medir qualidade, para descobrir o que os clientes mais perguntam.

Redis Chat Memory

Também externo, otimizado para acesso rápido. Bom quando o volume é alto e a latência importa.

Há ainda outros serviços com nodes prontos, como Motorhead, Xata e Zep, cada um com características próprias.

A chave de sessão: o erro mais grave

A memória é organizada por sessão. Cada conversa tem um identificador, e é ele que separa o histórico de um cliente do de outro.

Se a chave de sessão estiver errada, um cliente lê a conversa do outro. É o pior defeito possível num atendimento — vazamento de dado entre clientes. A chave precisa ser algo único e estável por conversa: o número do telefone, o identificador do contato, o número do ticket. Nunca um valor fixo, e nunca algo que possa se repetir entre pessoas diferentes.

Vale testar isso explicitamente: abra duas conversas simultâneas com dados diferentes e confirme que uma não enxerga a outra.

Quanto histórico guardar

Mais memória não é melhor. Todo o histórico guardado é enviado ao modelo a cada mensagem — então conversa longa significa chamada cara e mais lenta.

Alguns pontos de referência:

• Atendimento objetivo (status de pedido, agendamento): poucas mensagens bastam. O contexto útil é curto.

• Consultoria ou triagem: mais mensagens ajudam, porque o raciocínio depende do que foi dito antes.

• Conversa que dura dias: guardar tudo fica caro. Aqui entra a alternativa de manter um resumo em vez do histórico completo.

Gestão avançada

Existe um node dedicado a manipular a memória diretamente, útil em três situações que a documentação cita:

• Quando não dá para conectar um node de memória diretamente.

• Quando é preciso ir além do que os nodes de memória oferecem — por exemplo, verificar o tamanho da memória e reduzi-la quando crescer demais.

• Quando você quer injetar mensagens que pareçam ter vindo do usuário, para dar mais contexto ao modelo.

A terceira é a mais interessante na prática: permite "contar" ao agente algo que ele precisa saber — dados do cliente já identificado, por exemplo — sem que isso apareça como instrução de sistema.

Simple Memory para construir, Postgres para produção. A chave de sessão precisa ser única e estável por conversa, e vale limitar o histórico: tudo que fica guardado é enviado ao modelo a cada mensagem.

Perguntas frequentes