Use a structured episodic store with summarised recall, not a raw vector memory

The default comes from x-memory-bench, a four-way bake-off on a 40-session support corpus with held-out decision-consistency questions. Episodic store with summarised recall beat raw vector recall by 19 points of recall precision and ran at 0.6× the latency once accumulated history passed 50k tokens (c-agentic-memory-1, c-agentic-memory-2). The graph-structured variant won only on entity-lookup tasks and lost on everything else (c-agentic-memory-3), so it is a special case rather than a default.

The failure this replaces is in the graveyard as g-vector-memory-v1. The vector-store design was not wrong on day one; it was wrong at scale, and the scale it broke at is exactly where banking servicing and insurance claims agents live. The cost of that failure showed up as the same policy decision being re-derived differently 31% of the time; with consolidation it fell to 8%.

The store is harness-independent. Claude Code, LangGraph and a bespoke Python loop all ran against the same store through a thin adapter, so this recommendation does not bind a delivery team to a vendor memory product. Two vendor memory layers launched in August expose the same working/episodic/semantic shape but neither documents the consolidation policy, which is the part that carries the value and the part we still hand-roll.

Scope: agents with more than ten sessions of history. Below that, the memory layer is overhead. Not yet covered: a forgetting mechanism that satisfies APP 11 for client PII inside episodic entries. Do not put client PII in the episodic store until that exists; use a case reference and retrieve from the system of record.