Dify Integration

Dakera Memory is a tool plugin on the Dify Marketplace. It gives Dify Agent, Chatflow, and Workflow apps six memory tools — store, recall, search, get, update, forget — backed by a Dakera server you host yourself. Agents remember what matters across sessions, and stale context decays instead of piling up.

Plugin at a glance

When to use it

Dify is one of the fastest ways to build an LLM app, but its apps are stateless between runs — an Agent forgets everything the moment a conversation ends, and a Workflow starts every execution from a blank slate. Reach for Dakera Memory when you want your Dify app to:

• Remember users across sessions — preferences, decisions, and facts persist beyond a single chat.
• Keep context fresh, not bloated — memories are importance-scored and decay over time, so old low-value facts stop competing with what matters now.
• Stay on your own infrastructure — the plugin is a thin HTTP client for a Dakera server you run; nothing goes to Dakera AI or any third party.

If you only need short-term, in-conversation memory, Dify's built-in conversation variables are enough. Dakera is for durable memory that outlives the conversation and is shared, ranked, and prunable.

How a Dify tool plugin fits in

A Dify tool plugin registers a provider (here, credentials for your Dakera server) and a set of tools your apps can call. Once installed and authorized, each of the six Dakera tools becomes available in all three Dify app types — the difference is only who decides to call them:

Because it is a tool plugin (not a model plugin), Dakera Memory requests only the tool permission and never touches your LLM configuration.

Quick Start

git clone https://github.com/dakera-ai/dakera-deploy
cd dakera-deploy && docker compose up -d

# server + object store, API on :3000

The six tools

Every tool is namespaced by agent_id (default dify-agent) so different apps or users never see each other's memories. Recall and Search return each memory's ID, which chains directly into Get, Update, and Forget. Each tool maps to one REST call on your Dakera server:

Tool reference

Every parameter below is taken from the plugin manifest. agent_id appears on all six tools (optional, default dify-agent); it is listed once per tool for completeness.

Recall vs. Search — when to use which

The two read tools look similar but answer different questions. Recall is the in-conversation call: a semantic match that returns the best hits ranked most-relevant-first, over a store where Dakera weights memories by importance and lets old ones decay — use it when the agent needs the most useful context right now. Search is the deterministic browse: filter by tags and min_importance to pull a specific slice, with a larger top_k ceiling (50 vs. 20) — use it when you want everything matching a rule, or to list and audit what an agent remembers. Both return memory IDs you feed into Get, Update, and Forget.

A worked loop

Wire memory into any Dify app in two moves:

1. Early in the flow, call Recall with a query like "user's preferred programming language and coding conventions" (same agent_id) to pull prior context into the prompt.
2. When the agent learns something durable, call Store — e.g. "Alice prefers Rust over Python for backend services" with importance = 0.9.

Next session, recalling with the same agent_id surfaces that fact — ranked ahead of older, lower-importance memories. Over time, use Forget with below_importance = 0.3 to prune the noise, and Update when a fact changes (a moved office, a switched framework) so the memory is re-embedded instead of duplicated.

Wire it into a Chatflow

In a Dify Chatflow or Workflow app the memory tools become nodes you chain around your LLM. A minimal remember-then-answer loop uses two of the six tools:

The same pattern works in an Agent app: expose Store and Recall as tools and let the agent decide when to remember and when to look things up. Because each tool ships an LLM-facing description (e.g. "Store a memory for future recall … write it as a concise, self-contained fact"), the agent gets guidance on how to use them without extra prompting.

How it works under the hood

1. The plugin is a thin HTTP client — every tool call is a JSON request to the Dakera server URL you configured, and nowhere else. There is no code execution, no filesystem access, and no arbitrary URL fetching; the destination is fixed per credential set.
2. Store sends your text to the server, which embeds it server-side (no embedding model runs inside Dify) and persists it with an importance weight under the tool's agent_id namespace.
3. Recall runs semantic retrieval on the server and returns a ranked list with similarity scores. Because Dakera importance-scores memories and decays them over time, frequently-useful facts stay prominent while stale ones fade — the context you inject stays fresh instead of growing unbounded.
4. The dk- API key is stored as a Dify secret and attached only as an Authorization: Bearer header. Requests use bounded timeouts (5s for the health check, 15s for tool calls), and comma-separated tags / memory_ids are trimmed before being sent.

Concretely, a Store call with an importance of 0.9 and two tags sends a single JSON request like this to your server, and gets back the stored memory's ID:

POST /v1/memory/store   # Authorization: Bearer dk-...
{
  "content": "Alice prefers Rust over Python for backend services",
  "agent_id": "support-bot",
  "importance": 0.9,
  "tags": ["preference", "language"]
}
# → { "memory": { "id": "mem_abc123", ... } }

Privacy and security

The plugin's threat surface is deliberately small, and it ships a PRIVACY.md referenced from its manifest:

• One fixed destination. Every request goes to the base URL in your credentials — the plugin never fetches arbitrary per-invocation URLs, executes code or SQL, touches the filesystem, or drives a browser.
• Secrets stay secret. The dk- API key is stored as a Dify secret, attached only as a Bearer token, and never written back into tool output.
• Bounded requests. The credential health check times out at 5 seconds and every tool call at 15 seconds, so a stalled server can't hang your flow.
• Your data, your server. All memory content lives on the Dakera server you operate. Dakera handles no third-party accounts and no health, financial, or biometric data on your behalf.

Troubleshooting

Related integrations

Links

• Dify Marketplace — Dakera Memory
• Source PR — langgenius/dify-plugins #2642
• Plugin source repository — dakera-py
• Dakera deploy — Docker Compose setup
• All integrations

Frequently Asked Questions