Window Memory

Window buffer memory for AI agents — stores the last N messages with optional cross-run persistence.

When to Use

Use Window Memory when:

Prototyping chatbots that need basic conversation continuity
Conversations are short and recent context is sufficient (customer support, Q&A)
You want lightweight memory with no external vector database dependencies

For long-term recall with semantic search, use Qdrant Memory instead.

Inputs

None. Window Memory is a sub-node — it does not accept data from the main workflow. Connect its Memory output handle to an AI Agent's Memory input handle (dashed purple edge).

Output

None — memory is consumed internally by the connected AI Agent and does not emit data to the main workflow.

Connection Handle

Handle	Type	Description
`memory`	memory	Connect to an AI Agent's `Memory` input. Only one memory provider can be connected per agent.

Settings

Setting	Type	Default	Description
`windowSize`	number	`20`	Number of recent messages to keep in the conversation window. Older messages are dropped.
`sessionKey`	string	`""`	Per-user or per-thread scope key. Supports `{{ }}` bindings, e.g. `user:{{ input.body.user_id }}`.
`persistent`	boolean	`true`	When enabled, memory is saved to workflow state (SQLite) and survives workflow restarts. Disable for volatile in-memory only.

Example

Canvas

Build a per-user chatbot with conversation memory:

Add an API Endpoint trigger with openai-chat protocol
Add an AI Agent node and connect the trigger to the agent's message input
Add a Window Memory node and connect its Memory handle to the agent's Memory handle
Configure Window Memory:
- Window Size: 10
- Persistent: true
- Session Key: user:{{ "{{ api_request.headers["x-tensorify-session-id"] }}" }}
Connect the agent's response output to a Return node

The agent remembers the last 10 messages per session across workflow runs.

Session key patterns:

Pattern	Session Key	Use Case
Per-user	`user:{{ input.body.user_id }}`	Each user has their own conversation history
Per-thread	`thread:{{ input.body.thread_id }}`	Each conversation thread is isolated
Shared	`global`	All requests share one buffer (development only)

TSL

import api from @tensorify/api-trigger:1.0.0
import agent from @tensorify/ai-agent:1.0.0
import memory from @tensorify/memory-window:1.0.0
import respond from @tensorify/return:3.0.0

node api @tensorify/api-trigger:1.0.0 {
    path = "/v1"
    method = "POST"
    responseMode = "use-workflow-response"
    protocol = "openai-chat"
}

node agent @tensorify/ai-agent:1.0.0 {
    provider = "openai"
    model = "gpt-4o"
    systemPrompt = "You are a helpful assistant."
}

node memory @tensorify/memory-window:1.0.0 {
    windowSize = 10
    persistent = true
    sessionKey = "user:{{ api_request.headers[\"x-tensorify-session-id\"] }}"
}

node respond @tensorify/return:3.0.0 {
    returnMode = "simple"
}

api.payload -> agent.message
memory.memory -> agent.memory
agent.response -> respond.input

Common Gotchas

Window size vs token limits: A large window (50+ messages) can exceed the LLM's context window. Start with 10–20 and increase as needed.
Persistent mode: When enabled, memory survives workflow restarts but uses workflow state storage. For high-traffic deployments, consider Qdrant Memory instead.
No semantic search: Window Memory only returns recent messages in chronological order. It cannot recall relevant information from older conversations.
Session key in production: Without a sessionKey, the agent falls back to agent_memory:{workflow_id} and all users share one buffer. Always set a session key in production.
Only one memory provider: An agent accepts a single memory connection. You cannot combine Window Memory and Qdrant Memory on the same agent.