Axis II · Memory Management
What can change while the agent is running?
The survey separates systems by the scope of change they allow during deployment. In T1, memory is fixed after it is built. In T2, memory is updated through a stable management policy. In T3, feedback also evolves that policy.
Policy π
No write or maintenance policy after formation.
Try a question, then change the world and ask again.
Memory M (fixed)
- Kitchen & living-room map
- Mug — counter
- Keys — hallway table
- User drinks tea at 8am
- Charging dock — living room
Policy π (stable)
Hard-coded or learned before deployment; it does not change during inference, though it may choose different operations for different inputs.
Apply the five operations in any order. Numbers show how many corpus systems use each one.
Memory M (changing)
- Kitchen & living-room map
- Keys — hallway table Mon
- Tea at 8:02 Mon
- Tea at 7:58 Tue
- Tea at 8:05 Wed
- Charging dock — living room unused 30 days
Experience xt
The user drops their keys on the desk.
Task & feedback ft
Waiting for the next task…
Memory M
- Kitchen & living-room map
- Sofa — living room
- Mug — counter Mon 08:10
Policy π v1
- Store large objects and rooms
- Drop items unused for a day
- Retrieve by similarity to the question
Where the 297 systems sit
74.4% of systems let memory change during use (T2 or T3), yet only 17 evolve their own policy. Policy evolution concentrates in systems with explicit memory records, which are easier to inspect and revise.
- 107 hybrid T2 systems: the largest group
- 17 of 17 self-evolving systems keep explicit records
- 0 source/modality-specific-only or latent/parametric-only systems evolve their policy
Each system counted once, at its highest tier. Circle area shows the value. Hover to compare with chance; click to list the systems.
T2 is growing fastest
Cumulative systems by highest tier and the year of the latest paper version. T2 Dynamic Memory dominates the recent surge; self-evolving memory appears only from 2025.
| Series | 2023 | 2024 | 2025 | 2026 |
|---|---|---|---|---|
| T1 Static Memory | 5 | 16 | 34 | 76 |
| T2 Dynamic Memory | 8 | 28 | 77 | 204 |
| T3 Self-Evolving Memory | 0 | 0 | 1 | 17 |
How T2 systems change memory
Systems using each of the paper's five operations, by modality. A system can use several. Open the breakdown below for the specific mechanisms.
Mechanism breakdown
Update 190
Adds new observations or integrates them into existing records.
Consolidation 105
Merges related records or abstracts repeated experience into compact knowledge.
Revision 55
Corrects or replaces stored information that has become inconsistent or outdated.
Reorganization 49
Changes how records are grouped, linked, indexed, or moved across memory levels.
Forgetting 47
Removes records or lowers their retention or retrieval priority.
What T3 systems evolve
The 17 self-evolving systems target three kinds of policy.
Write policy 2
Feedback changes what raw experience is selected and how it is transformed into memory.
e.g. TaskMem, ABot-AgentOS
All 2 systemsMaintenance policy 1
Feedback changes which representations are retained, revised, or removed over time.
e.g. H²-EMV
All 1 systemsRetrieval policy 15
Feedback changes how queries are formed and which memories are prioritized.
e.g. RRM, ABot-AgentOS, SkeMex
All 15 systemsWhat each tier asks of its memory
Each step up adds a requirement, and with it a new way for memory to fail.
| Tier | Scope of persistent change | Core requirement | Key bottlenecks |
|---|---|---|---|
| T1 Static Memory | None after formation | Preserve task-relevant information in a form that can be accessed and reused. | Failure to preserve task-relevant information during formation; ineffective access to retained information. |
| T2 Dynamic Memory | Memory state | Apply a controlled change to the correct target while preserving unrelated content and dependent representations. | Limited editability or excessive operation scope; insufficient traces for verifiability; limited reversibility; incomplete update propagation and cross-representation inconsistency. |
| T3 Self-Evolving Memory | Memory state and management policy | Attribute outcomes to policy decisions, revise the responsible policy, and validate the revision across subsequent use. | Limited policy addressability; insufficient policy-decision traceability and feedback attribution; nonpersistent policy revisions; insufficient policy-level validation. |