Feature: portable app memory — exchange verified memory bundles between Dify apps and external agents

Start by confirming whether maintainers want an MCP tool plugin or an examples write-up, then review Dify's existing MCP tool bridge and the contributor's implemented transfer layer. Done means a scoped contribution path with explicit acceptance criteria for memory import/export or its documentation.

Maintainer of cognicore-env (open-source, MIT) — an agent memory layer running as an MCP server, consumable by Dify agents today via the MCP tool bridge. This issue proposes making memory portability first-class.

The gap: Dify apps have datasets and knowledge inside the platform, but app memory does not cross apps, and nothing leaves Dify with provenance. An internal-support agent that learned a company's actual escalation patterns cannot hand that knowledge to an ops agent or an external framework's agent — each Dify app is a memory island.

Proposal: memory export/import at the app level. The bundle format carries per memory: proof (command, result, exit code, output hash), chain of custody, observed-until-reverified import semantics, trust decay across unverified hops, validity intervals (facts verified in March are not evidence about April), and release rules so memory from a private dataset cannot surface in a public-facing app — the disclosure boundary is what makes cross-app memory safe to enable by default.

Concrete case: a support Dify app runs for a quarter, accumulating verified knowledge of how refunds actually resolve; a new sales app imports it as observed, re-verifies, and stops promising what support will not deliver.

Our transfer layer is implemented and tested across four platforms. I can contribute a tool plugin exposing memory import/export to Dify agents, or an examples write-up — whichever the team prefers. Where should ecosystem memory features be proposed — here or the forum?