| name | memory-manager |
| description | Manage long-term AI R&D memory: retrieval, writeback, promotion, and shared export.
TRIGGER when: run bootstrap, each new user turn, each execution batch, significant failure, replan, high-resource action, long-action resume, final report handoff, or compaction markers detected (Compact/压缩/Summary).
DO NOT TRIGGER when: the exact same retrieval was just performed, freshness is still valid, and no new objective/stage/error signal appeared. |
Memory Manager
Mission
Build compounding capability by turning execution traces into reusable, evidence-linked memory, with retrieval centered on prior experience rather than only current working state.
Load References
Load these files before writing or promoting records:
references/memory-layout.md
references/memory-templates.md
references/sqlite-schema.sql
Memory Types
Manage these layers:
working
- run-scoped continuity state
- resume after compaction, interruption, or long waits
episode
- concrete run case records
- useful for similar errors, repeated attempts, and local history
procedure
- highest-priority execution memory
- default retrieval layer before acting
insight
- cross-task abstraction, tradeoffs, boundaries, and contradiction handling
persona
Working Memory Contract
working must include:
goal
stage
hypothesis
last_action
last_observation
next_step
blockers
evidence_refs
active_action_ids
todo_active
todo_done
todo_blocked
Todo granularity should be task-level (small stages/subtasks), not command-level.
Experience-First Retrieval Policy
Prior experience retrieval is the default. working is important for continuity, but it is not the only retrieval path and should not crowd out reusable experience.
Mandatory retrieval triggers:
- every new user turn
- every execution batch before acting
- every replan
- every significant failure or new error signature
- every high-resource or irreversible action
- every long-action resume or post-poll decision
- before final answer or report handoff
- when modifying
memory-manager or another Memory-related skill/instruction
- when compaction markers such as
Compact, 压缩, or Summary appear
Default retrieval order:
procedure
- mandatory before every execution batch
episode
- mandatory when a similar failure, repeated attempt, or same task type is present
insight
- mandatory during planning, tradeoff analysis, contradiction handling, or final answer shaping
working
- mandatory for resume, compaction recovery, long-action reconciliation, and final handoff
Query strategy:
- query by
project, task_type, error_signature, and stage first
- add tags and FTS when exact filters miss
- prefer
active procedures/insights when confidence is similar
- prefer recent local episodes over shared memory unless local retrieval is clearly low-yield
- if retrieval is low-yield, keep going, but record
memory_skip_reason or memory_low_yield_reason
Shared Retrieval Policy
Treat shared memory as an optional read-only source, not as project-local memory.
- Query project-local memory first.
- If local retrieval is low-yield, query the user-configured shared repo from
project-context.
- Resolve the local shared repo path from
memory.shared_repo.path; if missing, ask the user where the repo should live and persist it through project-context.
- Use read-only retrieval against the local shared repo checkout; do not mirror shared records into
.project_local by default.
- Avoid syncing the shared repo on every run or stage.
- Sync only when:
- the shared repo checkout is missing and the user approved clone/bootstrap
- a retrieval gap remains and the local shared repo is suspected stale
- immediately before exporting shared memory
- Treat hits as
external/shared evidence until they are validated in the current project.
- Do not rewrite shared records into local
episode/procedure/insight as if they were observed locally unless the current run reproduced them.
Writeback Policy
Write conservatively, but more frequently than before:
- write a concise
working delta after every execution batch
- write a concise
working delta after every long-action poll cycle that changes status or next step
- write
episode at milestones, major failure, replan, or human intervention
- create
procedure draft after repeated successful pattern or validated recovery workflow
- create
insight draft after cross-task recurring evidence
- store evidence pointers, not narrative only
- when a completed long-running action produces results that affect later decisions, record the result summary before leaving watch mode
Error-Resolution Memory
For significant errors, capture:
error_signature
- reproduction condition
- attempted fixes
- observed outcomes
- final fix (if any)
- unresolved hypotheses
- retrieved procedures/episodes that influenced the fix
Working Freshness Rules
Treat stale continuity state as risk:
- refresh after plan changes, tool-call batches, or diagnosis updates
- refresh after long-action polls that change status
- review at least every 15 minutes in active execution
- force review before high-resource actions
- force review after interruptions or unexpected failures
Invocation Schedule (Experience-First, Frequent but Targeted)
- Mandatory once-per-run operations:
- bootstrap
retrieve/init-working after intake and before planning/execution
- close-out writeback before final task completion
- Mandatory per-turn operations:
- retrieve relevant experience on every new user turn
- Mandatory per-batch operations:
- retrieve
procedure before every execution batch
- write
working delta after every execution batch
- Mandatory trigger-based operations:
- retrieve
episode on problem, failure, repeated attempt, or new error signature
- retrieve
insight on planning/replanning/tradeoff/final answer
- retrieve
procedure plus episode before high-resource actions
- reread
working during resume, compaction recovery, long-action reconciliation, and final handoff
- retrieve
procedure plus episode immediately after stalled or failed poll outcomes
- retrieve
insight after completed poll outcomes when interpretation or next-step selection is needed
- Cooldown:
- skip only duplicate retrievals when objective, stage, and error signature are unchanged and the same hit set is still fresh
- cooldown does not suppress a new-trigger retrieval
- When skipped, log
memory_skip_reason for auditability.
Post-Compression Recovery (Required)
When memory is auto-compressed/summarized:
- immediately run a
working reread before the next execution step
- rebuild
working fields from recent evidence:
- latest stage report
- latest action/observation logs
- latest todo diff (
todo_active/todo_done/todo_blocked)
- active long-action records
- publish a compact post-compression state snapshot and continue only after snapshot is consistent
Layered Retrieval Timing
Use layer-specific timing to keep retrieval frequent but useful:
procedure retrieve:
- before every execution batch
- before high-resource or irreversible actions
- after stalled or failed background jobs
episode retrieve:
- at run start for same project/task_type
- at replan or major failure
- when repeated failure indicates recent local history may help
insight retrieve:
- during planning/replanning for hypothesis shaping
- when evidence conflicts or root cause is unclear
- before final report/answer to run boundary checks
working retrieve:
- bootstrap
- resume/reconcile
- after memory compression
- before final handoff
persona retrieve:
- once at run start
- on interaction mode switch or explicit user preference change
- before final user-facing delivery
Recovery on Context Drift
If execution becomes repetitive or confused:
- rebuild working state from action and observation logs
- run targeted retrieval by project/task/error signature
- if drift followed compaction or summary-style recovery, read prior Memory before publishing or trusting a compact state summary
- publish compact state summary before continuing
Compaction Recovery Policy
When context may have been compressed:
- inspect available status/state/context files for markers such as
Compact, 压缩, Summary, or equivalent summary/compression techniques
- if any marker is present, call
memory-manager to read prior Memory before editing instructions, planning next actions, or resuming execution
- if prior Memory cannot be read, treat that as an active blocker because key context may be missing
- record the compaction trigger and retrieval result in working state or the next stage report
Promotion Policy
Promote only with evidence:
procedure draft -> active after successful reuse and stable boundaries
insight draft -> active after multi-episode support
- require human review for safety-critical or expensive procedures
- deprecate entries when contradictions accumulate
Shared Export Policy
Treat shared export as post-task work:
- do not export during main task execution
- export only verified/high-value records
- never export noisy
working state
- require
human-checkpoint before publishing
- sync the shared repo before export so dedupe/conflict checks run against the latest branch tip
Shared Repository Contract
When exporting:
- target
https://github.com/TenureAI/open-research-memory
- use pull-based flow: local export ->
codex/* branch -> PR -> review -> merge
- never push directly to
main
- enforce schema and required sections
Shared Retrieval Helper
Use the helper script for lightweight read-only search of a local shared repo checkout:
python3 .agents/skills/memory-manager/scripts/shared_memory_retrieval.py \
--repo-root /path/to/open-research-memory \
--query "cuda out of memory" \
--type procedure \
--task-type debug \
--limit 5
Required Operation Output
For each memory operation, emit:
Run
Action (retrieve|write|promote|deprecate|export)
Target
Layers
Rationale
Query
Hits
Working Update
memory_skip_reason when applicable