[Feature Request] Opt-in self-improving memory for all Agent's #280

Strong FR, and the evaluator/critic gate you specify is the load-bearing part — it's also the part that determines the answer to AC5 (untrusted content must not silently become instruction). A few observations from building a memory-and-learning layer with the same shape:

1. You already ship an unstructured version of this, with no gate on it.
shared/bot-prompt.ts (L35-43) tells every bot to keep notes in its workspace: "Use computer_write_file to save notes, lists or data you will want later, and computer_read_file to read them back." That's cross-thread persistence with full prompt visibility, but with zero provenance and zero promotion step — whatever a bot writes into notes.md (including content it read from a page) comes back into every future turn. So this FR is not adding a new subsystem; it's adding a structured promotion layer on top of a write path that already exists — and the gate you're proposing is what closes the poisoning surface that the notes path already opens.

2. The gate needs provenance, not just a critic call.
A separate evaluator step alone doesn't satisfy AC5 — the evaluator and the bot usually share the same model and the same context, so the critic can inherit the poisoned belief. What made the separation hold in our case was three rules: (a) every candidate carries provenance (source run id, origin: tool result / user correction / evaluator), (b) promotion requires the claim to be verifiable against system state, not just plausible — a candidate like "the site's login flow changed" only promotes after the change was actually observed in a tool result, and (c) the retrieval channel that injects into the prompt is distinct from the channel that stores raw page content. That last one is the real AC5 mechanism: untrusted content stays in a store the prompt never reads; only promoted, provenance-carrying entries are injected.

3. The audit half is nearly free.
server/src/audit.ts already has the append-only trail with sensitive-key redaction. memory.created / memory.updated / memory.retrieved / memory.deleted slot in as new event types, and AC6 inherits the retention/redaction machinery instead of building a parallel one. The write-path check that "memory writes include source task/run, timestamp, confidence, scope, version" (AC3) is exactly the event shape auditEvents already carries for tool calls.

4. The completion hook exists.
server/src/routines/run-turn.ts is a headless turn with a known completion point — the natural place to extract candidate memories for scheduled routines; interactive threads have the same signal one level up. Since you already have routines + per-agent computers + the workspace, the minimal landing is: candidate extraction at turn completion → evaluator pass → promote into a structured memory file (source/ts/confidence/scope/TTL per AC3) → inject only promoted entries into the prompt assembly point. Everything else (review UI, export, rollback) is the admin surface on top.

One design note on TTL: volatile facts (site credentials rotated, page structure changed) need expiry, but verified workflow lessons shouldn't expire — they should only be superseded by a newer verified fact. A single expiry policy will get one of the two wrong; separate the two classes at the schema level rather than at the TTL level.

Happy to dig into any of these if useful.

Self-improving / long-term agent memory is a substantial roadmap topic rather than something scoped for now, and it overlaps #522. Closing as not planned.