doc: replace Task Tracking with Memory Recall in IDEAS.md

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

doc/IDEAS.md

@@ -188,4 +188,4 @@ Since agents have access to `execute_code`, a session can write and execute a wo
 
 ### Persistent Memory
 
-**Task tracking** — Agent sessions are ephemeral by nature: context windows fill, processes crash, work gets lost. [9beads](https://github.com/lneely/9beads) addresses this by exposing a structured, version-controlled task database as a 9P filesystem. Any session can read the task list, claim work, track dependencies, and mark completion through ordinary file operations. If a session is interrupted, another can pick up exactly where it left off. Task lists are scoped per-project, keeping them focused and bounded. Combined with olliesrv, agents get both a communication surface and a memory layer, with no special integration required between them.
+**Memory Recall** — Agent sessions are ephemeral by nature, but some knowledge should outlive them. Memory recall gives an agent the ability to persist and retrieve facts across sessions via two abstract tool contracts: `memory_remember` and `memory_recall`. When the agent learns something worth keeping — a user preference, an architectural decision, a hard-won debugging insight — it calls `memory_remember` with a concise, self-authored summary. On a future session it calls `memory_recall` to retrieve relevant memories before reasoning. Memories are LLM-generated rather than raw chat logs: the agent decides what matters and phrases it canonically, so memories remain meaningful long after the conversation that produced them is gone. The tool contract follows the same pattern as `reasoning_plan`: the agent owns the content, the tool owns the storage.