Dify AI Memory:
Adding Persistent State to Dify Workflows

Dify is one of the most popular no-code/low-code AI workflow builders. But its built-in memory resets every session. Here's how to wire Kronvex into your Dify workflows to add true cross-session, per-user persistent memory.

Dify's memory limitations

Dify comes with a "Conversation Memory" feature. It stores the message history of a given conversation thread. When you start a new conversation, that history is gone.

This is sufficient for simple chatbots where each session is independent. But most B2B use cases require more:

• A support bot that remembers a customer's previous tickets, plan, and past frustrations
• A sales assistant that recalls what a prospect discussed in the last demo call
• An onboarding agent that tracks what steps a user has completed across sessions

Dify also doesn't support semantic search across memory. Even if you store data, you can only retrieve it with exact variable lookups — not "find memories most relevant to this query."

Using Kronvex with the Dify HTTP node

Dify's HTTP Request node lets you call any REST API from within a workflow. This is the integration point. You'll use two Kronvex endpoints:

• POST /api/v1/agents/{agent_id}/remember — store a memory after each user interaction
• POST /api/v1/agents/{agent_id}/recall — retrieve relevant memories before generating a response

Your Kronvex API key goes in the X-API-Key header. You can store it as a Dify environment variable (Settings → Environment Variables) and reference it as {{env.KRONVEX_API_KEY}}.

Step-by-step: remember endpoint integration

Add a HTTP Request node at the end of your workflow (after the LLM response is generated). This stores the conversation turn as memory.

https://api.kronvex.io/api/v1/agents/YOUR_AGENT_ID/remember

{
  "X-API-Key": "{{env.KRONVEX_API_KEY}}",
  "Content-Type": "application/json"
}

{
  "content": "{{user_message}}",
  "memory_type": "episodic",
  "session_id": "{{conversation.id}}"
}

Use {{conversation.id}} as the session_id to scope memories per conversation thread. For cross-conversation user memory, use a stable user identifier like {{sys.user_id}}.

Step-by-step: recall endpoint integration

Add a HTTP Request node at the beginning of your workflow, before the LLM node. This fetches the most relevant memories to inject as context.

https://api.kronvex.io/api/v1/agents/YOUR_AGENT_ID/recall

{
  "query": "{{sys.query}}",
  "top_k": 5,
  "session_id": "{{sys.user_id}}"
}

The response will contain a memories array. Extract the content with a Code node (JavaScript or Python) to build a context string:

// Input: recall_response (from HTTP node output)
const memories = recall_response.memories || [];
const context = memories
  .map(m => m.content)
  .join('\n');

return {
  memory_context: context || 'No previous context available.'
};

Then pass {{memory_context}} into your LLM node's system prompt:

You are a helpful support assistant. Use the following context about
this user to personalize your response:

---
{{memory_context}}
---

Answer the user's question based on this context and your knowledge.

Example workflow: customer support bot with memory

Here is the complete node sequence for a production-grade customer support workflow:

Production tips: session IDs, TTL, memory types

• Use stable user IDs as session_id. Don't use Dify's conversation ID if you want memory to persist across multiple conversations with the same user. Use your CRM user ID or a hashed email.
• Set TTL for episodic memories. Add "ttl_days": 90 to your remember request body. This auto-expires old conversation turns and keeps the memory store lean.
• Extract semantic facts explicitly. After each conversation, add an LLM node that extracts key facts ("User is on Pro plan", "User speaks French") and stores them with memory_type="semantic" and no TTL.
• Rate limiting. Kronvex recall calls add ~80ms of latency. If your workflow is latency-sensitive, run recall in parallel with other initialization steps using Dify's parallel execution feature.
• Error handling. Wrap HTTP nodes in a condition node: if the recall call fails (network error), route to the LLM without context rather than failing the whole workflow.