n8n is great for workflows but not enough for agent memory

That’s a fair take.

n8n is excellent for orchestration, but it’s not really a full memory layer for agents. It can:

• pass data between nodes,
• store state in variables/executions,
• call external APIs,
• write to databases or vector stores,

…but it doesn’t natively give you the kind of persistent, structured, retrieval-friendly agent memory people usually want for long-running AI systems.

What n8n is good at

• Workflow automation
• Trigger/action pipelines
• Glue between services
• Simple short-term state handling
• Calling a DB, Redis, vector DB, or LLM

What it’s missing for “agent memory”

• Long-term memory management
• Semantic retrieval by relevance
• Memory summarization and decay
• Separate memory types, like:
  • conversation memory
  • user profile memory
  • task memory
  • episodic memory
• Memory policies:
  • what to store
  • when to forget
  • how to merge/update memories
• Native retrieval + ranking + grounding logic

Practical pattern

A common setup is:

• n8n = orchestration
• Postgres / Redis / vector DB = memory store
• LLM logic = decide what to remember and what to retrieve

So n8n can be part of the memory system, but usually not the memory system itself.

If you want, I can sketch a simple architecture for “n8n + agent memory” that works well in production.