A practical model of working, episodic, semantic, and procedural memory, with a coding example, record fields, and retrieval and update decisions.
Memory architecture: current context, past experience, stable knowledge, and the operations used to write, retrieve, update, and delete records.
Agent memory preserves useful information from earlier interactions and makes it available to later tasks. The context window holds what the model can read now. Persistent memory keeps selected information across sessions. Retrieval connects them.
Records also need sources and conditions of use, so later tasks can check whether old information still applies.
Follow one task into memory
Suppose an agent fixes form validation in a web workspace, discovers that the workspace has its own test command, and obtains a passing result. During the task, it holds plans, errors, and tool output. Afterward, it can preserve the repair history, the workspace convention, and the validation procedure.
- Conversation and tool results
- Select and preserve sources
- Persistent records and index
- Retrieve for the task
- Check and use
- Update from results
These operations can use files, relational databases, vector indexes, or a combination. A single service can handle several steps.
Working and long-term memory describe lifetime
Working memory includes the current goal, active steps, temporary evidence, and unresolved questions. In the example, the latest stack trace and investigation plan belong here.
Long-term memory holds content intended for later tasks, such as a validated repair. Its form may be an original excerpt, summary, or structured record. Retrieval selects material within the current context budget, while source access allows the agent to recover details omitted from a summary.
Persistent records can also be classified by content
CoALA includes episodic, semantic, and procedural memory in its conceptual framework for language agents. These categories describe how information is used. One database can hold all three.
| Content type | Record from the example | Later use |
|---|---|---|
| Episodic | Failed attempt, eventual repair, and test result | Inspect a specific previous experience |
| Semantic | The workspace's test entry point and module responsibilities | Locate relevant code and environment |
| Procedural | Checks required for this kind of change | Organize execution and validation |
One task can produce several kinds of record. Each needs a clear scope. A test command, for example, should be tied to the project where it was verified.
Fields that make a record usable
A general-purpose memory record might contain these fields: { "content": "The web workspace test entry point and its conditions", "scope": {"repository": "example-project", "workspace": "web"}, "kind": "semantic", "source": "Confirmed project configuration and task record", "valid_for": "The code version that was checked", "status": "active", "supersedes": null }
Scope limits applicability, the source supports inspection, and the version identifies what was checked. When a rule is explicitly replaced, record relationships help retrieval find the current rule and explain its history.
Preserve conditions from writing through updates
Preserve conclusions with their conditions when writing, and consolidate equivalent records. During retrieval, enforce access scope before searching for task-relevant content, then check whether records have been superseded. Verify changeable facts against current files or tool results before acting.
After the task, store confirmed changes. Correct an obsolete rule; retain an existing rule when the new instruction is only a scoped exception. Compression should preserve conditions that change future actions and references that recover the evidence.
How MemoraX Code organizes memory
MemoraX Code documents Coding, Repo, Personal, and Procedure Memory for engineering experience, repository knowledge, collaboration preferences, and workflows.
These categories serve a different purpose from the academic taxonomy. Repository knowledge, for example, may contain a stable module description and links to a particular refactoring event. Start with the user's retrieval need, then choose the representation that supports it.
References https://github.com/memorax-ai/memorax-code/blob/935993230853c8bf56f610afda50f9ef57307558/README.md https://arxiv.org/html/2309.02427v3
