Jido plugin that replaces Jido.Memory.BasicPlugin with Gralkor-backed memory. Claims the :__memory__ slot so it is the only memory plugin attached to the agent.

session_id is the current Jido thread id, read from agent.state[:__thread__].id. One Jido thread per Gralkor session — the capture buffer rotates naturally when the thread rotates, and concurrent agents for the same principal never collide on the buffer. group_id is sanitize_group_id(agent.id) since memory graph partitioning is per-principal.

Recall fires on ai.react.query: Gralkor is always called with the agent's group_id and the current thread's session id (or nil when no thread has committed yet — first query of a fresh agent, before the ReAct strategy's ThreadAgent.append runs inside @start). When a thread is committed, its session id is planted on the signal's tool_context so in-turn tool calls (e.g. MemorySearch) key on the same session; when it isn't, no session id is planted. The returned memory block (when present) is stashed on tool_context under :__gralkor_memory__ regardless of thread state. The plugin does not mutate :query — the recalled memory is delivered to the LLM by a request transformer at prompt-build time (see Jido.AI.Reasoning.ReAct.RequestTransformer and Jido.AI.PromptBuilder), keeping :query the user's actual words everywhere downstream (buffer, request store, capture).

Capture fires on ai.request.completed / ai.request.failed: the full request trace and assistant answer are normalised via JidoGralkor.Canonical.to_messages/3 into Gralkor's canonical [%Gralkor.Message{role, content}] shape and shipped to the server, which keeps the rolling conversation buffer keyed by session_id. Because nothing in the turn mutates :query to add harness context, canonicalisation doesn't strip envelopes — the user message it persists is the user's actual words. Capture is skipped if the thread isn't present (first-turn failure with nothing committed) or if the canonical message list is empty.

Recall failures are best-effort under the retry-ownership doctrine (see gralkor/TEST_TREES.md › Retry ownership): if the Vertex-upstream retries at the google-genai SDK exhaust, Client.recall/3 returns {:error, _} and the plugin logs a warning and continues the turn without :__gralkor_memory__. Retrying here would amplify load without a meaningful chance of success, and failing the turn would turn a memory outage into a user-facing outage. Capture failures still raise (Gralkor capture is server-side buffered and its retry lives in the capture buffer, not here — a raise from capture/3 means the server is unreachable, which is a different failure class).