内容来源：https://blog.n8n.io/ai-agent-memory-how-llm-agents-manage-state-in-production/

内容总结：

大模型每次调用都从零开始，自身不具备记忆能力——每个请求相互独立，模型读完提示词、返回回答后不保留任何信息。这对于一次性问答没有问题，但一旦构建需要跨时间工作的系统——比如处理后续追问的客服坐席、为续约电话做准备的销售助手，或每小时运行一次且需要知道上次做了什么的自动化流程——就会失效。这些系统需要有状态，而模型无法替它们保存状态。

因此，当人们问大模型记忆如何工作时，诚实的答案是：记忆存在于模型之外。智能体把学到的东西存储在别处，在每次调用前检索相关部分并回填到提示词中。这层外部机制就是所谓的AI智能体记忆，其设计好坏决定了智能体是记住该记的，还是被无关信息淹没。

智能体记忆通常按两个时间尺度运作，往往构建为两个独立组件。短期记忆追踪当下正在发生的事：近期消息、中间推理、工具输出、任务状态，通常存放在智能体附近，甚至就在运行框架内部。当上下文窗口填满时，常见做法是把迄今的历史摘要后回填，但摘要会丢失细节，某些输出（如中间草稿或昂贵计算的结果）根本不应被压缩。长期记忆则跨会话存续，保存用户偏好、过往任务结果、经验教训，以及越来越多并非智能体自己生成的公司知识——文档、工单、CRM记录。这几乎从第一天起就需要专门的外部层，因为必须有机制决定保留什么、如何组织、每次请求返回什么。无论哪种方式，交付机制不变：模型仍然只收到一个提示词，记忆只是改变了提示词的组装方式——新的用户消息、加上运行中的会话、加上当前相关的长期记忆。

有几个术语常被混用，但描述的是知识存放的不同位置，真实系统往往四者兼用。严格意义上的大模型记忆是模型训练时吸收的内容，是压缩的模式而非查询表，因此模型可能自信地重复过时信息；微调可增加领域知识，但慢、贵、难以审查，也无法捕捉实时会话中的信息。上下文工程是为本次调用选择放入上下文窗口的内容，更大的窗口有帮助但不解决记忆问题：会话结束上下文即消失，长提示词成本更高，模型对超长输入中各部分的关注并不均衡。RAG从现有知识源（文档、数据库、API）检索并把结果加入提示词，关键局限在于方向——RAG只读不写，不会记住用户上周问了什么或哪个修复已经失败过。智能体记忆则从智能体“写回”开始：它在工作中捕捉新事实、偏好和结果，日后再检索。比如一个销售助手通过RAG拉取本季度数据，同时记得此前对话中该用户希望以欧元计价、按国家拆分的欧盟数据。

任何记忆系统在高层面上都需要三部分：持久化记忆的数据存储、决定存什么及如何存的写入逻辑、让智能体找到相关记忆的检索接口。存储选择对后两者影响很大，按存储类型可分为几类架构。向量数据库把记忆转为嵌入、按语义相似度查找，易于搭建且生态支持好，但相似不等于一切：“Q3销售额”和“Q4销售额”在向量空间几乎重叠，无法判断哪条是当前的，措辞不同的相关内容也可能完全漏检。纯文件方案由智能体维护一个MEMORY.md之类的文件自行读写，因编程智能体而流行，透明且可版本控制，但检索仅限于全量加载或grep，多智能体共享文件很快会乱。知识图谱把事实变为实体和关系——销售报告涵盖欧盟交易、欧盟交易以欧元记账、数据来自账单导出——检索先找到入口再沿边遍历，智能体得到的是与问题逻辑相关的事实，而不仅是听起来相似的，代价是入库时工作量更大。混合系统在实践中没有单一存储能覆盖一切：精确ID需要结构化索引，关系需要图，模糊匹配需要向量，“客户去年三月偏好什么”需要时间戳。生产级记忆层组合多种存储并在其上放置逻辑来决定什么放哪里。这也是记忆层不止于数据库的原因：存储只是数据所在之处，记忆层位于其上，决定以何种形式存什么，并对外暴露智能体用于写入、检索、更新和遗忘的操作。

只增不减的记忆层会随时间变差：事实会变、偏好会移、过时条目开始与正确条目竞争。好的记忆系统在存储之上还要处理几个过程，主要有三：整合，原始条目堆积速度远快于其变得有用，系统应定期将其转化为更少、更高层的记录（摘要、派生事实），同时保留回溯原始内容的线索；更新，事实变化时盲目覆盖会丢失历史——之前是什么、何时变的，在事实上保留时间信息可让智能体同时回答“现在什么是真的”和“我们三月时以为什么是真的”；遗忘，有些数据必须删除——过时数据集、更正、删除请求，这应是明确、有意的操作，区别于让不太有用的记忆在相关性上自然淡出的软性过程。最好的系统还会从使用中学习：答案被确认，其背后的记忆权重上升；被纠正，误导性的记忆权重下降。数周之后，检索应当更精准而非更嘈杂。

公开基准测试提供了有用的第一信号，多数遵循同样的两阶段模式：先把长历史输入记忆系统，再提问，答案取决于是否正确存储和检索了相关事实，包括后来被更新或推翻的。规模比人们预想的重要：如果基准的全部历史能装进现代上下文窗口，就完全可以跳过记忆、把所有内容粘进提示词，这样的测试更多反映模型而非记忆系统。不过这不意味着模型会答得完美——模型对长上下文的利用并不均衡，埋在长提示词中部的细节可能获得较少关注。LoCoMo对话约2.6万token，LongMemEval常见变体约11.5万token。BEAM是三者中要求最高的，在长达1000万token的对话上测试十项记忆能力，这才是外部记忆真正必须发挥作用的地方。BEAM上报告的最优结果为10万token时79%、1000万token时67%，由Cognee取得，此前最好成绩为73.4%和64.1%。但基准主要检查最终答案，不考察记忆实际存了什么、经过数周更新后是否仍然可靠、多智能体共享时表现如何。最重要的测试是你自己的：同一工作流分别开启和关闭记忆运行，衡量你在意的结果，比如解决的工单数、减少的重复提问、正确的后续跟进。

n8n工作流与大模型有一个共同点：默认每次执行都从新开始。因此周一起草了修复方案的客服工作流，周三收到跟进时不会自动知道这件事。许多团队用Postgres表或Airtable base来处理，可行，但每个工作流都需要自己的存储设置和自己的保留规则。最简单的记忆让任何工作流从上一次运行停下的地方继续：一个节点存储工作流学到的东西，另一个节点在下次运行时查出来；由于记忆存在于任何单一工作流之外，多个工作流可以共享它。最大的价值在于集中式的“大脑”：一个所有工作流都读写共享记忆。扩展到整个公司就得到“公司大脑”。大多数有用的上下文本就散落在公司各处：Slack讨论串、工单、文档、CRM备注、通话记录。n8n可以从这些工具中收集，记忆层可以结构化和连接，让每个工作流都基于同一幅公司知识图景。模式很简单：收集型工作流利用n8n的触发器和应用集成，在新材料出现时（关闭的工单、通话摘要、表单提交）拾取并送入记忆层，由其结构化和连接；执行型工作流在做事情之前查询同一记忆——起草回复、路由升级、准备销售简报——可以用自然语言提问，比如“Acme目前状态如何，我们向他们承诺了什么？”，再把答案传给下一个节点。由于两端指向同一记忆，工作流共享上下文而无需共享实现细节。当记忆保留实体间关系时，执行型工作流能得到关联性答案，比如哪些合同下季度到期、哪些账户有共同根因，这是纯相似度搜索会错过的。第二种模式位于单个n8n AI Agent内部，对应此前的短期/长期划分。没有记忆时，智能体收到的每条消息都从零开始。n8n通过AI Agent的Memory端口处理短期侧，默认的“Simple Memory”为当前会话存储可自定义长度的聊天历史，是最容易上手的方式，也可以沿用默认或选择更高级的第三方记忆提供方。但聊天记忆只记住对话，长期知识（用户偏好、过往任务结果、公司上下文）需要的远不止聊天日志。为此，把记忆层连接到Agent的Tool端口，挂载智能体可用于访问额外上下文或资源的附加组件。智能体随后可自行决定何时记住新东西、何时搜索公司已知内容。结果是智能体既把握当前对话的脉络，又能在任务中途触达共享的公司知识。简言之：n8n内置记忆对单个聊天智能体是不错的起点；但如果想要随时间演进、跨工作流和智能体共享的记忆，就应结合记忆层——聊天记忆负责手头对话，共享记忆让每次运行都从公司已知内容出发而非从零开始。

结论：大模型每次调用都从零开始，因此要构建长期可靠工作的AI智能体，就需要模型之外的记忆。但存储信息只是挑战的一半，智能体还需要在任务和工作流之间捕捉、检索并基于正确上下文行动的方式。n8n与Cognee共同解决这些挑战：n8n连接应用、编排AI智能体、自动化系统间的信息流动；Cognee把这些信息转化为结构化、持久的记忆，智能体可以检索、更新和共享。二者结合，让你构建的AI工作流不仅能独立执行任务，还能从过往交互中学习、跨会话保持上下文，并基于对公司知识的共享理解来工作。

中文翻译：

每一次LLM调用都从零开始

LLM本身没有记忆。每个请求都是独立的：模型读取提示词，返回响应，什么都不保留。发送第二个请求时，在模型看来，第一个请求从未发生过。

对于一次性提问来说，这没问题。但当你构建需要跨时间工作的系统时，这种模式就会崩溃：一个处理后续跟进的支持客服、一个为续约电话做准备的销售助理，或者一个每小时运行一次且应该知道上次做了什么的自动化流程。这些系统需要状态，而模型无法替它们保存状态。

所以当人们问LLM记忆是如何工作的，诚实的答案是：记忆存在于模型之外。智能体把学到的东西存储在别处，在每次调用前检索相关部分，再将它们反馈到提示词中。这个外部层就是我们所说的AI智能体记忆，你如何设计它，决定了你的智能体是记住正确的东西，还是淹没在错误的信息中。

本文解释这个层如何工作、构建它的主要方式，以及如何在n8n中使用它——既作为你的工作流可以查询的共享“公司大脑”，也作为单个智能体工作流内部的记忆。

短期记忆与长期记忆

智能体记忆通常在两个时间尺度上运作，且往往被构建为两个独立的组件。

短期记忆跟踪当前正在发生的事情：最近的消息、中间推理过程、工具输出、任务状态。它离智能体很近，通常就在运行框架内部。当上下文窗口填满时，一个常见的技巧是将迄今为止的历史总结压缩，再把摘要反馈回去。这能奏效，直到它不再奏效：摘要会丢失细节，而有些输出根本不应该被压缩，例如中间草稿或昂贵计算的结果。

长期记忆跨会话存续。它保存用户偏好、过往任务的结果、关于什么有效的经验教训，以及越来越多的、并非由智能体自己生成的公司知识：文档、工单、CRM记录。这几乎从第一天起就需要一个专门的外部层，因为必须有东西来决定保留什么、如何组织、以及每次请求时返回什么。

无论哪种方式，交付机制不变。模型仍然只接收一个提示词。记忆只是改变了提示词的组装方式：新的用户消息，加上当前会话，加上当前相关的长期记忆。

LLM记忆、上下文、RAG、智能体记忆：有什么区别？

这四个术语经常被互换使用，但它们描述的是知识可以存在的不同位置。一个真实系统通常会同时使用它们。

严格意义上的LLM记忆是模型在训练过程中吸收的东西。它是压缩的模式，不是查找表，这就是为什么模型会自信地重复过时的信息。微调可以添加领域知识，但它缓慢、昂贵、难以检查，而且无法捕捉实时会话中的任何内容。

上下文工程是为某次特定调用选择什么内容进入上下文窗口。更大的窗口有帮助，但并不能解决记忆问题：会话结束时上下文就消失了，长提示词成本更高，而且模型对超长输入中所有内容的注意力并不均等。

RAG从现有知识源（文档、数据库、API）中检索，并将结果添加到提示词中。关键限制在于方向：RAG只读，不回写。它不会记住用户上周问了什么，或者哪个修复方案已经失败了。

智能体记忆从智能体回写的地方开始。它在工作过程中捕获新事实、偏好和结果，并在之后检索它们。想象一个销售助理，它通过RAG拉取本季度的数据，但同时记得从之前的对话中得知这位用户想要欧元计价的欧盟数据，并按国家细分。

智能体记忆实际上如何工作

从高层来看，任何记忆系统都需要三个部分：一个持久化存储记忆的数据存储、决定存储什么以及如何存储的写入逻辑、以及让智能体找到相关记忆的检索接口。你选择的存储方式对另外两个部分有很大影响：哪种写入逻辑合理，以及检索能做什么。以下是按存储类型划分的主要架构。

向量数据库。记忆被转化为嵌入向量，通过语义相似度来查找。易于搭建且支持良好，但相似度并非一切。“Q3销售额”和“Q4销售额”在向量空间中几乎重叠在一起，没有“哪个事实是当前的”这个概念，而一条相关但措辞不同的条目可能被完全遗漏。

普通文件。智能体维护一个MEMORY.md（或类似文件），它读取和编辑这个文件。编程智能体推广了这种做法。它透明且可版本控制，但检索仅限于加载全部内容或用grep搜索，而且在多个智能体之间共享一个文件很快就会变得混乱。

知识图谱。事实变成实体和关系：销售报告涵盖欧盟交易，欧盟交易以欧元记账，数据来自账单导出。检索找到一个入口点，然后沿着边遍历，因此智能体获得的是与问题逻辑相关的事实，而不仅仅是听起来相似的事实。代价是摄取阶段需要更多工作。

混合系统。在实践中，没有单一存储能覆盖一切。精确ID需要结构化索引，关系需要图，模糊匹配需要向量，而“客户去年三月偏好什么？”需要时间戳。生产级记忆层组合多种存储，并在其上放置逻辑来决定什么去哪里。这也是为什么记忆层不仅仅是一个数据库：存储只是数据所在的地方，记忆层位于它们之上。它决定什么被存储、以什么形式存储，并暴露智能体用来写入、检索、更新和遗忘的操作。

记忆必须被管理，而不仅仅是积累

一个只增不减的记忆层会随着时间推移变得越来越差。事实会变化，偏好会转移，过时的条目开始与正确的条目竞争。好的记忆系统在存储之上处理若干流程。主要的三个是：

• 整合。原始条目堆积的速度远快于它们变得有用的速度。系统应定期将它们转化为更少、更高层级的记录（摘要、派生事实），同时保留回溯到原始内容的线索。
• 更新。当一个事实发生变化时，盲目覆盖会丢失历史：之前什么是真的，以及它何时改变的。在事实上保留时间信息，让智能体既能回答“现在什么是真的？”，也能回答“我们三月时相信什么？”
• 遗忘。有些数据必须删除：过时的数据集、一次更正、一个删除请求。这应该是一个明确的、有意的操作，区别于让不太有用的记忆在相关性中逐渐淡出的柔性过程。

最好的系统还会从使用中学习。如果一个答案被确认，其背后的记忆权重增加；如果被纠正，误导性的记忆权重降低。经过数周，检索应该变得更精准，而不是更嘈杂。

你如何知道你的记忆在工作？

公开基准测试提供了有用的第一信号。大多数遵循相同的两阶段模式：将长历史输入记忆系统，然后提问，这些问题的答案依赖于存储和检索正确的事实，包括后来被更新或矛盾的事实。

规模比人们预期的更重要。如果一个基准测试的完整历史能装进现代上下文窗口，你可以完全跳过记忆，把所有内容粘贴到提示词中，所以这个测试更多说明的是模型而非记忆。不过这并不意味着模型会完美回答：模型不会均匀地使用长上下文，埋在长提示词中间的细节可能获得较少的注意力。LoCoMo对话大约26k token；LongMemEval的常见变体约为115k。BEAM是三者中要求最高的，在长达10M token的对话上测试十种记忆能力，这才是外部记忆真正必须发挥作用的地方。BEAM上报告的最先进结果为100K token时79%、10M token时67%，由Cognee创造，此前最好成绩为73.4%和64.1%。

但基准测试主要检查最终答案。它们不看记忆实际存储了什么、经过数周更新后表现如何、或者当多个智能体共享它时行为如何。关于每个基准测试衡量什么以及在哪里不足的完整地图，请参阅这份AI记忆基准测试指南。

最重要的测试是你自己的：在开启和关闭记忆的情况下运行同一个工作流，衡量你在意的结果，比如解决的工单数、更少的重复问题、或正确的后续跟进。

为n8n工作流添加记忆

n8n工作流与LLM有一个共同特征：默认情况下，每次执行都从零开始。所以一个在周一起草了修复方案的支持工作流，在周三后续跟进到来时不会自动知道这件事。许多团队用Postgres表或Airtable基础表来处理这个问题，这可行，但每个工作流随后都需要自己的存储设置和自己的保留规则。

1. 所有工作流的共享大脑

最简单的层面上，记忆让任何工作流能从上一次运行中断的地方继续。一个节点存储工作流学到的东西；另一个节点在下一次运行时查找它。而且因为记忆存在于任何单个工作流之外，许多工作流可以共享它。

最大的回报是一个集中式的“大脑”：一个所有工作流都写入和读取的共享记忆。将其扩展到整个公司，你就得到了一个“公司大脑”。大多数有用的上下文已经存在于公司各处：Slack讨论串、工单、文档、CRM备注、通话记录。n8n可以从所有这些工具中收集它，记忆层可以对其进行结构化和连接，这样每个工作流都基于公司已知信息的同一幅图景来运作。

模式很简单：

• 收集工作流使用n8n的触发器和应用集成，在新材料出现时拾取它们，例如一个关闭的工单、一份通话摘要或一次表单提交，并将其发送到记忆层，由记忆层进行结构化和连接。
• 执行工作流在做某事之前查询同一个记忆：起草回复、路由升级、准备销售简报。它们可以用自然语言提问，比如“Acme的当前状态是什么，我们向他们承诺了什么？”，然后将答案传递给下一个节点。

因为两边指向同一个记忆，工作流共享上下文而无需共享实现细节。而当记忆保留实体之间的关系时，执行工作流获得的是关联性答案，例如哪些合同下季度到期、或哪些账户有相同的根本原因，这是纯相似度搜索会遗漏的。

2. 智能体工作流内部的记忆

第二种模式存在于单个n8n AI Agent内部，它对应前面提到的短期和长期记忆的划分。没有记忆时，智能体收到的每条消息都从零开始。n8n通过AI Agent的Memory端口处理短期记忆方面。n8n的默认“Simple Memory”存储当前会话可自定义长度的聊天历史，这是最简单的入门方式。你可以沿用这个默认设置，或选择更高级的第三方记忆提供商，如下所示：

然而，聊天记忆只记住对话。长期知识，例如用户偏好、过往任务的结果和公司上下文，需要的不仅仅是聊天日志。为此，将记忆层连接到Agent的Tool端口，在那里你挂载智能体可以用来访问额外上下文或资源的附加组件。然后智能体可以自行决定何时记住新信息、何时搜索公司已知的内容。结果是，智能体既能把住当前对话的线索，又能在任务中途触及共享的公司知识。

简而言之：n8n的内置记忆对于单个聊天智能体来说是一个好的起点。但如果你想要随时间演进且跨工作流和智能体共享的记忆，请将其与记忆层结合：聊天记忆用于手头的对话，共享记忆让每次运行都从公司已知的信息开始，而非从零开始。

结论

LLM每次调用都从零开始，因此构建能长期可靠工作的AI智能体需要模型之外的记忆。但存储信息只是挑战的一半。智能体还需要一种方式来跨任务和工作流捕获、检索和作用于正确的上下文。

n8n和Cognee一起解决这些挑战。n8n连接你的应用、编排AI智能体、自动化信息系统之间的流动。Cognee将这些信息转化为结构化的、持久的记忆，智能体可以检索、更新和共享。

两者结合，让你构建的AI工作流不仅能独立执行任务，还能从之前的交互中学习、跨会话保持上下文、并基于对公司知识的共享理解来工作。

准备好构建具有长期记忆的AI智能体了吗？开始使用n8n并连接Cognee，为你的工作流赋予共享记忆层。

英文来源：

Every LLM call starts from zero
An LLM has no memory of its own. Each request is independent: the model reads the prompt, returns a response, and keeps nothing. Send a second request and, as far as the model knows, the first never happened.
That is fine for a one-shot question. It breaks down the moment you build something that works over time: a support agent handling a follow-up, a sales assistant prepping for a renewal call, or a workflow that runs every hour and should know what it did last time. These systems need state, and the model can't hold it for them.
So when people ask how LLM memory works, the honest answer is that the memory lives outside the model. The agent stores what it learns somewhere else, retrieves the relevant parts before each call, and feeds them back into the prompt. That external layer is what we call AI agent memory, and how you design it decides whether your agent remembers the right things or drowns in the wrong ones.
This post explains how that layer works, the main ways to build it, and how to use it in n8n, both as a shared "company brain" your workflows can query and as memory inside a single agentic workflow.
Short-term and long-term memory
Agent memory usually works on two timescales, and they are often built as two separate components.
Short-term memory keeps track of what's happening right now: recent messages, intermediate reasoning, tool outputs, the state of the task. It lives close to the agent, often inside the harness itself. When the context window fills up, a common trick is to summarize the history so far and feed the summary back in. That works until it doesn't: summaries lose detail, and some outputs shouldn't be compressed at all, for example intermediate drafts or the results of expensive computations.
Long-term memory survives across sessions. It holds user preferences, outcomes of past tasks, lessons about what worked, and increasingly, company knowledge the agent didn't generate itself: docs, tickets, CRM records. This almost always needs a dedicated external layer from day one, because something has to decide what gets kept, how it's organized, and what comes back for each request.
Either way, the delivery mechanism doesn't change. The model still receives one prompt. Memory just changes how that prompt is assembled: the new user message, plus the running session, plus whatever long-term memories are relevant right now.
LLM memory, context, RAG, agent memory: what's the difference?
These four terms get used interchangeably, but they describe different places where knowledge can live. A real system often uses all of them.
LLM memory in the strict sense is what the model absorbed during training. It's compressed patterns, not a lookup table, which is why a model can confidently repeat something outdated. Fine-tuning can add domain knowledge, but it's slow, expensive, hard to inspect, and it can't capture anything from a live session.
Context engineering is choosing what goes into the context window for this particular call. Bigger windows help, but they don't solve memory: the context vanishes when the session ends, long prompts cost more, and models don't attend equally to everything in a very long input.
RAG retrieves from an existing knowledge source (docs, a database, an API) and adds the results to the prompt. The key limitation is direction: RAG reads, but it doesn't write back. It won't remember what the user asked last week or which fix already failed.
Agent memory starts where the agent writes back. It captures new facts, preferences and outcomes as it works, and retrieves them later. Picture a sales assistant that pulls this quarter's numbers via RAG, but also remembers from earlier conversations that this user wants EU figures in euros, broken down by country.
How agent memory actually works
At a high level, any memory system needs three pieces: a data store where memories are persisted, write logic that decides what gets stored and how, and a retrieval interface that lets the agent find the relevant memories. The store you choose has a big influence on the other two: which write logic makes sense, and what retrieval can do. So here are the main architectures, by store type.
Vector databases. Memories are turned into embeddings and found by semantic similarity. Easy to set up and well supported, but similarity isn't everything. "Q3 sales" and "Q4 sales" sit almost on top of each other in vector space, there's no notion of which fact is current, and an entry that's relevant but phrased differently can be missed entirely.
Plain files. The agent keeps a MEMORY.md (or similar) that it reads and edits. Coding agents popularized this. It's transparent and version-controlled, but retrieval is limited to loading everything or grep-ping, and sharing a file between many agents gets messy fast.
Knowledge graphs. Facts become entities and relationships: the sales report covers EU deals, EU deals are booked in euros, the figures come from the billing export. Retrieval finds an entry point, then follows the edges, so the agent gets facts that are logically related to the question, not only ones that sound similar. The trade-off is more work at ingestion time.
Hybrid systems. In practice, no single store covers everything. Exact IDs want a structured index, relationships want a graph, fuzzy matching wants vectors, and "what did the customer prefer last March?" needs timestamps. Production memory layers combine stores and put logic on top that decides what goes where. This is also why a memory layer is more than a database: the stores are just where the data lives, and the memory layer sits on top of them. It decides what gets stored and in what form, and exposes the operations agents use to write, retrieve, update and forget.
Memory has to be managed, not just accumulated
A memory layer that only grows gets worse over time. Facts change, preferences shift, and stale entries start competing with correct ones. Good memory systems handle several processes on top of storage. The main three are:

• Consolidation. Raw entries pile up faster than they become useful. The system should periodically turn them into fewer, higher-level records (summaries, derived facts) while keeping a trail back to the originals.
• Updating. When a fact changes, a blind overwrite loses history: what was true before, and when it changed. Keeping time information on facts lets the agent answer both "what's true now?" and "what did we believe in March?"
• Forgetting. Some data has to go: a stale dataset, a correction, a deletion request. That should be an explicit, deliberate operation, separate from the softer job of letting less useful memories fade in relevance.
  The best systems also learn from use. If an answer gets confirmed, the memories behind it gain weight; if it gets corrected, the misleading ones drop. Over weeks, retrieval should get sharper, not noisier.
  How do you know your memory works?
  Public benchmarks give a useful first signal. Most follow the same two-phase pattern: feed a long history into the memory system, then ask questions whose answers depend on storing and retrieving the right facts, including ones that were later updated or contradicted.
  Size matters more than people expect. If a benchmark's whole history fits in a modern context window, you can skip memory entirely and paste everything into the prompt, so the test says more about the model than about the memory. That doesn't mean the model will answer perfectly, though: models don't use long contexts evenly, and details buried in the middle of a long prompt can get less attention. LoCoMo conversations run around 26k tokens; LongMemEval's common variant is about 115k. BEAM is the most demanding of the three, testing ten memory abilities over conversations of up to 10M tokens, which is where external memory actually has to do the work. The reported state of the art on BEAM is 79% at 100K tokens and 67% at 10M, set by Cognee, up from the previous best of 73.4% and 64.1%.
  But benchmarks mostly check final answers. They don't look at what the memory actually stored, how it holds up after weeks of updates, or how it behaves when many agents share it. For a full map of what each benchmark measures and where it falls short, see this guide to AI memory benchmarks.
  The test that matters most is your own: run the same workflow with memory on and off, and measure the outcome you care about, such as tickets resolved, fewer repeated questions, or correct follow-ups.
  Adding n8n workflows memory
  n8n workflows share a trait with LLMs: by default, each execution starts fresh. So a support workflow that drafted a fix on Monday won't automatically know about it when a follow-up arrives on Wednesday. Many teams handle this with a Postgres table or an Airtable base, which works, but each workflow then needs its own storage setup and its own rules for what to keep.
  1. A shared brain for all your workflows
     At its simplest, memory lets any workflow pick up where the last run left off. One node stores what the workflow learned; another looks it up on the next run. And because the memory lives outside any single workflow, many workflows can share it.
     The biggest payoff is a centralized "brain": one shared memory that all your workflows write to and read from. Extend it to the whole company and you get a "company brain". Most useful context already exists across the company: Slack threads, tickets, docs, CRM notes, call transcripts. n8n can collect it from all those tools, and a memory layer can structure and connect it, so every workflow draws on the same picture of what the company knows.
     The pattern is simple:
• Collector workflows use n8n's triggers and app integrations to pick up new material as it appears, such as a closed ticket, a call summary or a form submission, and send it to the memory layer, which structures and connects it.
• Acting workflows query that same memory right before they do something: draft a reply, route an escalation, prep a sales brief. They can ask in plain English, like "What's the current status with Acme, and what did we promise them?", and pass the answer on to the next node.
  Because both sides point at the same memory, workflows share context without sharing implementation details. And when the memory keeps relationships between entities, acting workflows get connected answers, such as which contracts expire next quarter or which accounts share the same root cause, that a pure similarity search would miss.
  2. Memory inside an agentic workflow
     The second pattern lives inside a single n8n AI Agent, and it maps onto the short-term and long-term split from earlier. Without memory, every message the agent receives starts from zero. n8n handles the short-term side through the AI Agent's Memory port. n8n's default, "Simple Memory", stores a customizable length of chat history for the current session, and it's the easiest way to get started. You can stick with this default or choose a more advanced third-party memory provider, as shown below:
     Chat memory, though, only remembers the conversation. Long-term knowledge, such as user preferences, the outcomes of past tasks and company context, needs more than a chat log. For that, connect a memory layer to the Agent's Tool port, where you attach add-ons the agent can use to access extra context or resources. The agent can then decide for itself when to remember something new and when to search what the company already knows. The result is an agent that holds the thread of the current conversation and can reach into shared company knowledge mid-task.
     In short: n8n's built-in memory is a good starting point for a single chat agent. But if you want memory that evolves over time and is shared across workflows and agents, combine it with a memory layer: chat memory for the conversation at hand, and shared memory so every run starts from what the company already knows rather than from zero.
     Conclusion
     LLMs start every call from zero, so building AI agents that work reliably over time requires memory outside the model. But storing information is only half the challenge. Agents also need a way to capture, retrieve, and act on the right context across tasks and workflows.
     n8n and Cognee solve these challenges together. n8n connects your apps, orchestrates AI agents, and automates how information flows between systems. Cognee turns that information into structured, persistent memory that agents can retrieve, update, and share.
     Together, they let you build AI workflows that don't just execute tasks independently, but learn from previous interactions, maintain context across sessions, and work from a shared understanding of your company's knowledge.
     Ready to build AI agents with long-term memory? Get started with n8n and connect Cognee to give your workflows a shared memory layer.