* fix(memory): truncate mem0 context injection on entry boundaries Mem0Manager.get_context built the injection block and then hard-cut it at max_injection_chars, which could sever the last memory mid-line and leave a dangling partial entry in the agent prompt. Accumulate whole entries against the remaining budget instead: a memory that does not fit is skipped (a shorter later one may still fit). When not even the first memory fits, fall back to the previous hard-truncation behavior for that single entry rather than injecting nothing. Tests: entry-boundary truncation, skip-oversized-keep-later, and the oversized-first-entry fallback. * fix(memory): keep entry-boundary guarantee when no mem0 memory fits Follow-up to PR #4600 review: remove the hard-truncation fallback that could inject a partial memory when max_injection_chars is smaller than every recalled entry. Instead return empty context and log a warning that surfaced the undersized budget.
mem0 memory backend
Uses mem0 (Platform hosted API, or any API-compatible self-hosted server) as DeerFlow's memory store. Fully stateless in-process: dedup, fact extraction, and storage are server-side, so it is safe for multi-worker Gateway deployments.
Configuration
memory:
enabled: true
injection_enabled: true
manager_class: mem0
mode: middleware # or "tool"
backend_config:
api_key_env: MEM0_API_KEY # key read from env, never in config.yaml
base_url: https://api.mem0.ai # or your self-hosted mem0 server
allow_insecure_http: false # true only for trusted local HTTP dev
top_k: 8
score_threshold: 0.1
max_injection_chars: 12000
timeout_seconds: 10
startup_policy: fail_fast # fail_fast | tolerate
failure_policy:
read: fail_open # fail_open | fail_closed
write: log_and_drop # log_and_drop | raise
Set the key in the environment: export MEM0_API_KEY=...
base_url must use HTTPS because every request carries the API key. For a
trusted local-development server that only exposes HTTP, opt in explicitly
with allow_insecure_http: true; do not use that setting across an untrusted
network.
Identity mapping
| DeerFlow | mem0 |
|---|---|
user_id |
user_id |
agent_name |
agent_id |
thread_id |
run_id |
Limitations
mode: middlewarerecall is query-less (theget_contextcontract carries no query): the bucket's most recenttop_kmemories are injected. For query-aware semantic recall usemode: tool.mode: toolretains the passive per-turn write middleware for this backend, because mem0 extracts and deduplicates facts from conversations throughadd(). The agent still gains query-awarememory_search, while new conversations continue accumulating memory even though fact CRUD is not available.- Fact CRUD,
import_memory, and Settings-page memory editing are not implemented (gateway returns 501). DeerMem remains the default backend. - No migration of existing DeerMem data.
log_and_dropwrite policy is at-most-once: a failed write is dropped.memory_add/memory_update/memory_deleteare backed by fact CRUD, which this backend does not implement; they return a clear unsupported-operation error. Conversation writes still happen through the retained middleware.
Async execution and failure behavior
The mem0 HTTP client is synchronous for compatibility with the
MemoryManager contract. DeerFlow offloads it at every async boundary: the
async middleware uses the manager's a* methods, and Gateway memory routes run
sync management calls in worker threads. A slow mem0 request therefore does
not block unrelated ASGI handlers or SSE heartbeats.
failure_policy.read: fail_open logs a recall failure and continues without
new memory context. fail_closed propagates the backend error through prompt
construction and aborts the run instead of silently degrading.