Memory
The agent-memory config node connects an agent to managed data stores for
facts and events.
Configure both stores: A usable agent currently needs both a Facts store and an Events store. The Node-RED fields may appear optional and deployment may succeed without them, but the agent can fail when it first tries to read or write memory.
Properties
Section titled “Properties”| Property | Current behavior |
|---|---|
| Name | Reusable configuration label. |
| Storage | Storage backend. Data Store is currently the available option. |
| Facts | Mutable memory records such as facts, profiles, preferences, summaries, and usage. |
| Events | Append-only runtime activity used for conversation history and Studio tracing. |
| Scope | Session or User fact scope. |
The plus buttons next to Facts and Events can provision stores with the expected columns.
Create or select these stores in Node-RED. Agent Studio currently displays their IDs as read-only values.
Facts Store
Section titled “Facts Store”Fact records include identifiers plus:
kindkeyvalue
Facts may be read or written by runtime memory actions. Rolling conversation summaries and usage counters also use fact storage.
Normal fact keys that do not start with __ are automatically included in
model context on every reasoning call. Context None disables stored event
history, not scoped facts.
Do not store API keys, passwords, tokens, or other secrets as facts. They can be sent to the configured model provider.
Fact Writes
Section titled “Fact Writes”Facts are identified by their key within the current logical agent and selected session/user scope. Writing an existing key replaces its value and kind.
Writing a null value leaves the fact record present with an empty value. It
does not delete the fact, and the current model-facing memory actions do not
provide a delete operation.
Memory reads and writes continue the agent loop with another reasoning step. They count toward Max Iterations and can add model calls and usage.
Events Store
Section titled “Events Store”Event records identify the agent, session, and method and store the action-specific content. Events are used to reconstruct history and populate Agent Studio.
Events can contain user messages, model output, tool data, warnings, and errors. Apply appropriate retention and access controls.
Session keeps normal facts with the current sessionId.
User keeps normal facts with the userId, allowing them to be reused across
sessions for that user.
Event history remains session-based in both modes. Treat a stable user ID as required for User scope. Use Session scope for anonymous traffic or when a reliable identity is unavailable.
Changing Scope does not migrate existing facts. A record written under Session scope is not automatically moved into User scope, or vice versa.
Context Is Separate
Section titled “Context Is Separate”The Memory node selects storage and fact scope. The Agent node’s Context setting decides how much event history is sent to the model.
For example, a user-scoped memory can still use Context None, and a session-scoped memory can still use Full Conversation.
With Context None, normal scoped facts are still supplied automatically. Use a separate Memory configuration or avoid storing facts when a workload must not inherit any saved information.
Agent Studio Editing
Section titled “Agent Studio Editing”Studio currently allows Name, Storage, and Scope changes, but the Facts and Events store fields are read-only. Use the Node-RED Memory config node to create or replace stores and confirm the deployed IDs.