> **RFC — discuss, do not implement yet.** Goal: explore *how* Workgraph should > relate to agent memory services, not to build it. ## Motivation Agents already use semantic memory (mem0, Cloud-Temple live-memory/graph-memory, cortex, …). Workgraph is **durable work state**; memory is **semantic recall**. They overlap but are not the same. We want them to reinforce each other without Workgraph becoming a memory system (explicit non-goal in the spec) or memory becoming a shadow task tracker. ## Questions to answer - **Direction.** Push (Workgraph → memory: index item/decision summaries for recall)? Pull (memory → Workgraph: surface candidate items into `triage`)? Both? - **What crosses the boundary.** Only durable objects (items, decisions) and their compact summaries — never chain-of-thought or full bodies? - **Identity & provenance.** How does a memory record point back to `ITM-…` / `DEC-…`? Reuse the `source_ref` convention (`mem0:<id>`)? Keep it idempotent. - **When.** On mutation (event-driven), on a schedule, or on demand from a coordinator? - **Trust.** Memory-suggested items must land in `triage`, never `ready` (same rule as imports). ## Sketch of approaches 1. **Adapter, one-way export.** A small `workgraph memory push` that upserts compact object summaries into a memory backend keyed by object id. Cheapest; no new core concepts. 2. **Enrichment, one-way import.** `workgraph memory suggest` pulls related memories for an item into its body/links as *proposals*. 3. **Bidirectional.** Powerful, but multiplies conflict cases — the V0 spec explicitly deferred two-way sync. Probably not first. ## Cross-cutting Any multi-write ("save the item **and** write to memory") raises atomicity: what if the memory write fails after the Git commit? Tracked in the atomic cross-system RFC (see linked issue). This RFC should assume that mechanism rather than reinvent it. ## Non-goals - Vector memory inside Workgraph. - Storing transcripts. - Making a memory backend a required dependency.