false acks

[dylangrant]

Environment

• neo4j-agent-memory: 0.5.0
• Backend: NAMS hosted (memory.neo4jlabs.com)
• MCP server launched via uvx from claude_desktop_config.json
• Python: 3.14.5 (pyenv)
• Platform: macOS

Bug 1: memory_store_message false-acks
memory_store_message returns {stored: true, id: , session_id: "dylan"}
but the message never appears in Neo4j. Verified via graph_query:

MATCH (m:Message) WHERE m.id = '' RETURN m
→ 0 rows

Also verified: GET /v1/conversations/dylan returns 404 ("conversation not found"),
suggesting the MCP layer is passing raw session aliases to the API instead of
resolving them to conversation UUIDs first.

Reproduced twice with different session_ids and content. Direct API writes
(via Python SDK outside MCP) persist correctly to the same workspace.

Bug 2: memory_add_entity throws "too many values to unpack (expected 2)"
Every call to memory_add_entity fails unconditionally regardless of payload size:

memory_add_entity(name="Test", entity_type="PERSON")
→ error: "too many values to unpack (expected 2)"

Suspected location based on traceback pattern:
/neo4j_agent_memory/memory/long_term.py (entity resolution/creation path)

Impact
Both write tools silently fail while read tools (memory_search, graph_query,
memory_get_entity) work correctly. The false-ack on store_message is
particularly dangerous as it causes silent data loss with no indication
to the caller.

Workaround
Direct Python SDK calls outside MCP work correctly. Using those as a
temporary fallback.

[chengyixu]

Living Memory then Proactive Execution

This looks like a write-receipt bug, not only a session-alias bug: stored: true should mean the caller can independently observe the stored message, not merely that a request reached the MCP layer.

A small provider-neutral regression contract could make the failure deterministic without touching the separate entity-creation path already being handled elsewhere:

1. Resolve a caller-supplied session_id alias to the canonical conversation UUID before the write. If resolution returns 404, return an explicit error and never return stored: true.
2. Write the message and retain the returned message ID plus canonical conversation ID.
3. Read the message back by ID (and verify it belongs to that canonical conversation) before acknowledging success.
4. Return stored: true only after the read-back matches the submitted role/content. If the write or read-back fails, surface the phase and return a failed result rather than a false success.
5. Add synthetic tests for alias resolution, canonical UUID input, missing conversation, read-back mismatch, retry/idempotency, and the invariant that no orphaned success receipt is emitted.

That gives downstream agents a useful boundary: Living Memory is not considered durable until its evidence is attributable and observable; Proactive Execution can then prepare a next step, but a write acknowledgement must not silently create authority for a new permission, judgment call, or external commitment.

Design context only: Klik's pre-launch direction uses “Living Memory then Proactive Execution” as a similar principle of reviewable retained context before a future step. This is not a Klik integration, benchmark result, endorsement, or validation.