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

[githb-ac]

Problem

OpenBot has persistent coworkers, per-Agent computers, governed tool use, and auditability, but it would benefit from an optional long-term memory layer that helps each Bot improve across completed tasks and threads.

For recurring autonomous work—such as monitoring multiple websites, producing weekly insights, researching, drafting, and maintaining operating procedures—a Agent should be able to retain validated lessons: preferences, successful methods, failed approaches, and task-specific context.

Feature request

Add opt-in self-improving memory for all Agents. This should be a memory-and-learning layer, not model-weight training.

Proposed behaviour

• After a task completes, create a short candidate memory from the task outcome, tool results, and evaluator feedback.
• Store and retrieve relevant memories across that Bot's threads and future tasks.
• Support optional Team memory shared only with explicitly selected Agents.
• Use a separate evaluator/critic step before promoting candidate memories into durable memory.
• Let Bots learn from verified successes, failures, user corrections, and repeatable workflows.
• Allow scheduled reflection/cleanup to merge duplicates, expire stale facts, and flag conflicts.

Required controls

• Disabled by default; enabled per Agent.
• Memory scope: private Agent, selected Team, or organisation.
• Immutable audit log showing why a memory was created, changed, retrieved, or deleted.
• Review, edit, pin, export, rollback, and delete controls.
• Version history and expiry/TTL for volatile facts.
• Clear separation between trusted operator instructions and untrusted web/tool content to reduce prompt-injection or memory-poisoning risk.
• Never automatically alter system prompts, permissions, policies, credentials, or tool grants.
• Configurable token, storage, and cost budgets.

Why this matters

This would make OpenBot more competitive for unattended recurring workflows while preserving its core advantages: per-Agent isolation, gateway policy enforcement, and action-level auditability. It would be particularly useful for a self-hosted team that monitors and improves multiple websites weekly, where the Bot needs to remember verified site-specific history and prior outcomes.

Acceptance criteria

1. An administrator can enable long-term memory for an individual Agent.
2. The Agent retrieves relevant approved memories in a later, separate thread.
3. Memory writes include source task/run, timestamp, confidence, scope, and version.
4. An administrator can inspect, edit, roll back, export, expire, and delete memories.
5. Untrusted browser/page content cannot silently become durable instruction memory.
6. All memory reads/writes appear in the existing audit trail.
7. The feature works for scheduled routines as well as interactive chats.

Suggested name

Agent Memory or Continuous Memory

[pm25coder]

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.