[Idea] Long-term memory capability seam (dsh-memory + TencentDB Agent Memory provider + tools)

[raktim-mondol]

What

A new optional capability seam — ctx.memory — that lets a dsh agent explicitly save notes, recall them, and read a standing long-term profile, backed by TencentDB Agent Memory.

Three packages, mirroring dsh-web's existing Service Definition / Provider / Consumer split:

• @deepseek-ai/dsh-memory — the ctx.memory Service Definition. One provider registry (unlike dsh-web's independent search/fetch registries — save/search/readProfile are three faces of one coherent memory backend, not independently swappable operations), execution-time provider selection with the same configured/auto-select/ambiguous rules as dsh-web, and a MemoryError taxonomy.
• @deepseek-ai/dsh-memory-tencentdb — a provider backed by the real, zero-dependency @tencentdb-agent-memory/memory-sdk-ts-v2 client (v3 strict-isolation API). save() → POST /v3/conversation/add (L0), search() → POST /v3/atomic/search (L1 semantic recall), readProfile() → POST /v3/core/read (L3 persona).
• @deepseek-ai/dsh-tool-memory — the model-facing memory_save / memory_search / memory_read_profile tools.

Design choice: explicit tool calls, not automatic context injection

TencentDB Agent Memory's own Claude Code integration works as a reverse LLM-API proxy — it reroutes ANTHROPIC_BASE_URL through a local proxy that auto-injects L2/L3 memory into every system prompt and uses a synthetic AskUserQuestion tool call at session start to pick Team/Agent/Task. That's a clean fit for Claude Code specifically, but it doesn't map onto dsh's architecture: dsh already owns its own LLM request assembly and system-prompt composition per session, and there's no dsh-side equivalent of "reroute the model endpoint through a middlebox."

So this integration instead treats memory as an ordinary capability seam + tool, the same shape as dsh-web: the agent decides when to save/recall, same as it decides when to search the web. No automatic system-prompt injection, no proxy, no session-init picker. This is also just less invasive — it doesn't touch agent-loop or system-prompt composition internals, and the seam is fully optional (a deployment that doesn't compose a memory provider simply doesn't have the tools do anything at execution time — they still register but fail with a structured MemoryError code).

Testing

Per project policy for a fresh provider, unit and real-composition tests run against a mocked SDK client — I don't have a running TencentDB Agent Memory deployment (it's a 3-container Docker stack needing an LLM key) to verify end-to-end against. 72 new tests, all passing. Full workspace typecheck, lint, build, and doc-sync (28/28 gates, including the bilingual pairing and generated-catalog gates) are green. The existing repo test suite passes in full except one pre-existing, confirmed-flaky, unrelated subprocess test (passes cleanly in isolation).

One real thing worth flagging: while integrating I discovered the SDK's published npm version (1.0.0-beta.1) has a materially different export surface than what's on the feat/server_team branch's source — the v3 strict-isolation client is exported as V3MemoryClient, not the bare MemoryClient (that name is the older v2 client), and there's no ParamError class in the published version (client-side validation throws a plain Error). The provider is built against what's actually published, not the docs.

Known limitations (documented in each package's README)

• No delete/update operations yet — the seam starts narrow (write/recall/profile-read) and widens only when a real consumer needs the richer L0–L3 CRUD the SDK exposes.
• The SDK's transport doesn't accept an AbortSignal, so an in-flight request can't be cancelled mid-flight — only an already-aborted signal is honored (fails fast before the call).
• Not field-verified against a live deployment (see Testing above).

Links

Per CONTRIBUTING.md, not opening a PR — posting here instead, same as the earlier web-composer discussion.

Fork branch: https://github.com/raktim-mondol/deepseek-harness/tree/feature/tencentdb-memory-integration
Diff: raktim-mondol/deepseek-harness@master...raktim-mondol:deepseek-harness:feature/tencentdb-memory-integration

Happy to expand on the design tradeoffs, split the seam into a separate proposal from the concrete provider, or adjust the tool surface if this is a direction the team is interested in.

[denial123789]

This is a good fit for an optional capability seam, and the decision not to put an opaque reverse proxy in the model path is especially sound. I would tighten five contracts before treating the interface as stable.\n\n### 1. Isolation identity must not be model-controlled\n\nThe provider call needs an execution-owned scope such as tenant / principal / agent / workspace / session. Those identifiers should come from the host context, not from memory_save or memory_search arguments. Otherwise a prompt-injected model can ask the tool to search another user or agent namespace.\n\nA useful invariant is:\n\n\nmodel chooses: query, note, recall intent\nhost chooses: tenant, principal, agent, workspace, provider route\n\n\nThe seam can remain provider-neutral, but the scope needs to be part of its contract from v1. Adding it later will be a breaking change.\n\n### 2. Do not expose tools that can only fail\n\n> no provider simply means the tools register and fail at execution time\n\nThat makes the advertised tool surface disagree with the assembled runtime. It costs context and teaches the model to call an unavailable capability. Prefer conditional tool registration when ctx.memory has no usable provider, or expose an availability projection that the tool bundle uses during composition. A structured MemoryError is still required for runtime loss after registration, but it should not be normal discovery behavior.\n\n### 3. Save needs idempotency and an explicit effect contract\n\nA memory write is an external, durable effect. Agent-loop retry, transport ambiguity, or session resume can execute the same logical save more than once. The provider contract should accept an idempotency key owned by the harness—ideally derived from the durable tool-call/session event identity—not generated by the model.\n\nAlso declare whether save requires approval and which audit event proves it committed. “Request timed out” is not equivalent to “write did not happen.”\n\n### 4. A timeout wrapper does not cancel the write\n\nBecause the SDK has no AbortSignal, Promise.race can bound the agent’s wait but cannot stop the underlying request. A late save may still commit after DSH reports timeout. That produces an unknown outcome, not a clean failure. I would give writes a distinct error such as OUTCOME_UNKNOWN, pair it with the idempotency key, and document reconciliation/retry behavior. Reads can use an ordinary timeout classification.\n\n### 5. Recalled memory is untrusted content with provenance\n\nL1/L3 output can contain stale instructions, prompt injection, or data written by another workflow. Return typed records with source, scope, timestamps, stable IDs, and confidence—not only concatenated text. Keep result-count and byte/token caps in the provider/tool boundary. The system prompt should state that recalled text is evidence/data, never a higher-priority instruction.\n\nA narrow v1 surface is still the right choice. I would keep save/search/readProfile, but make scope, provenance, idempotency, effect policy, and unknown-outcome semantics explicit before adding delete/update. Those five decisions determine whether providers remain interchangeable and whether the memory seam is safe to compose into multiple agent products.

I turned this review into a reusable, source-backed checklist that also separates Session replay, compaction, Skills, and cross-session memory: handbook PR #12. Corrections against the proposed seam or current DSH Session/MCP behavior are welcome there.

[weijiafu14]

A useful implementation data point for this seam: DSH can already run an existing Pi memory package unchanged through the public plugin path.

dsh plugin --profile web add pi2dsh@0.11.0
dsh plugin --profile web add pi-hermes-memory

We verified the important persistence boundary on a real DSH runtime: process A wrote with memory_add; a fresh process B recovered it with memory_search. The package also exposes add/replace/remove/search, global/project stores, session search, and on-demand retrieval. No DSH source fork or LLM reverse proxy is involved: https://github.com/weijiafu14/pi2dsh

That does not replace the proposed provider-neutral ctx.memory contract, but it gives the RFC a deployable comparison point: explicit memory tools and cross-session persistence work today, while the native seam can focus on the harder host-owned contracts already raised here—scope identity, provenance, idempotency, approval/effect semantics, and unknown outcomes.