Classification method
Why agent memory type lists disagree
Agent memory type lists disagree because they flatten different dimensions into one hierarchy. Some labels name an item's job. Others name form, duration, operation, or access boundary. Labels become useful when their axes are explicit. The method below is guide-created, not a field standard, and must be adapted to the workload.
Illustration
This guide's classification method
representation form × functional role × lifecycle operation × retention horizon × scope
Dimensions in reading order
- Representation form names how information is carried.
- Functional role names the job the information serves.
- Lifecycle operation names what happens to the record.
- Retention horizon names which boundary the record survives.
- Scope names where authenticated authority permits access.
External research CoALA contributes proposed functional modules T05. Hu and colleagues contribute a forms, functions, and dynamics frame T06. Zhang and colleagues survey sources, forms, and operations T07. No cited source proposes this exact combination.
Category errors to reject
- A vector index is an access mechanism, not a functional role.
- Short retention does not make a cache working memory.
- An entity view does not raise source authority.
- A procedure does not grant execution permission.
- A delayed intention needs durable workflow state.
Functional roles
What functional roles can agent memory serve?
Functional roles name the job retained information performs. Working, episodic, semantic, and procedural memory provide a core vocabulary. Factual, experiential, prospective, and entity roles cover other workload objects. These cognitive terms are design analogies, not human equivalence. One record can serve several roles, but no label establishes truth or authority.
External research Baddeley and Hitch ground working memory T01. Tulving distinguishes episodic and semantic memory T02. Squire reviews interacting human memory systems T03. The software terms are analogies, not a biological model.
Core roles
- Working memory
- Facts, intermediate results, and control state used in current work. Active use, not duration, defines the role.
- Episodic memory
- Events or trajectories with time, source, participants, and outcomes. Later change does not erase the historical event.
- Semantic memory
- Reusable knowledge not bound to one event. Derivations should link to supporting episodes.
- Procedural memory
- Methods, skills, code, or reviewed instructions. Retrieval remains separate from execution authority.
External research Peer-reviewed UIST work on Generative Agents uses a memory stream, retrieval, reflection, and planning in its simulation T08. Voyager, a peer-reviewed TMLR paper, uses a retrievable executable skill library in Minecraft T10. Both are specific designs, not a complete taxonomy.
Extended roles
- Factual memory
- A proposition with source, time, and status. The label does not make it true.
- Experiential memory
- Cases, strategies, or lessons derived from outcomes. It can overlap other roles.
- Prospective memory
- A delayed intention tied to a time, event, or state cue. It needs task state and cue detection.
- Entity memory
- An entity-centered view of attributes and relations. It requires identity resolution beyond a display name.
External research Rummel and Kvavilashvili review prospective memory as memory for delayed intentions T04. That cognitive account does not define an agent scheduler.
External research Peer-reviewed AAAI work on ExpeL retains trajectories and derives insights in evaluated tasks T09. PM-Bench, a COLM paper with a linked arXiv record, evaluates delayed intentions and cues in its published task T11. Neither defines a universal implementation.
Representation forms
What form can an agent memory take?
Representation form names the physical or logical carrier of retained information. It may be an explicit record, model parameter, continuous state, or hybrid of source material and access aids. Form does not determine function, retention, or authority. A form without addressable records needs an inspection and erasure contract.
- Explicit or symbolic
- Text, fields, events, relations, or executable procedures that can be addressed and inspected.
- Parametric
- Information encoded in model weights or adapters, with update and deletion boundaries tied to the model process.
- Latent or continuous
- Hidden state or dense representations whose meaning may require a decoder or downstream task.
- Hybrid
- A sourced record paired with derived summaries, relations, or retrieval representations.
Separate record and retrieval contracts
Illustration
A record contract names identity, source, time, version, status, scope, authority, and retention. A retrieval contract names queries, filters, ranking, stale behavior, and limits. An embedding is commonly a derived retrieval representation, not the authoritative record. Another design must declare its provenance, update, access, and erasure rules.
Retention and scope
How long and where should memory persist?
Retention horizon says what boundary an item survives, while scope says who may write, retrieve, change, export, or delete it. A short horizon does not make a record working memory, and a broad horizon does not make it shared. Each design must name the authenticated scope and the event that ends retention, which may differ across derived copies.
| Horizon | What survives | Who can retrieve it | What ends retention |
|---|---|---|---|
| Inference call | Current model input and temporary state | The active runtime | The call completes |
| Run | Intermediate task state across calls | The authorized run | Completion, cancellation, or expiry |
| Session | State needed across one interaction session | Actors and services in that session | Session policy closes it |
| Cross-session subject | Sourced history for a resolved subject | Authorized work for that subject | Retention policy or scoped erasure |
| Workspace | Team tasks, methods, and reviewed lessons | Authorized workspace members and agents | Workspace policy or object removal |
| Shared organization | Approved organizational knowledge | Authorized organizational roles | Withdrawal, replacement, or policy expiry |
| Archive | Historical evidence retained for a declared purpose | Restricted archive roles | Archive schedule or erasure duty |
Scope comes from authenticated authorization. Model arguments, display names, or retrieved identifiers may narrow but cannot establish access.
Short-term and long-term are retention horizons, not functional roles. A short-term item may be episodic or factual. Working state can survive through a durable checkpoint. Living AWS AgentCore documentation uses short-term and long-term as one current vendor vocabulary T12. Those labels are not a neutral standard.
Workload selection
Which memory roles does this agent need?
Choose memory roles by listing the objects later work must recover, not by selecting a storage product first. For each object, decide its source, authority, retrieval trigger, update rule, and erasure rule. The result is a workload contract, not a universal taxonomy. Some agents need a small role set, while others need overlapping views.
| Workload object | Candidate role | Selection question |
|---|---|---|
| Active task state | Working | What must survive the next step or retry? |
| Event history | Episodic | Which event, time, source, and outcome matter later? |
| Reusable claims | Factual and semantic | Which source and validity state support reuse? |
| Methods | Procedural | Which version applies, and who may use it? |
| Learned lessons | Experiential and semantic | Which outcomes support the derivation? |
| Delayed intentions | Prospective | Which cue, owner, task state, and cancellation rule apply? |
| Entity-centered view | Entity plus underlying roles | How is identity resolved and each field sourced? |
Write the chosen object's source and authority before choosing its retrieval trigger. Then define correction, supersession, expiry, and erasure behavior. Use the architecture guide to assign those contracts to components and the evaluation guide to turn them into cases.
Retrieval-augmented generation, or RAG, retrieves external items for a query and conditions generation on them. It can provide an access path for records classified here, but it does not determine their role, scope, or update semantics. The agent memory and RAG guide owns that comparison.
Synthetic inventory
Incident-response memory inventory
Synthetic classification inventory for INC-204. It
explains contracts and reports no measured result.
-
Active mitigation hypothesis
- Object or claim
- Active mitigation hypothesis
- Source
- Incident commander note and linked telemetry
- Functional role
- Working and factual candidate
- Representation form
- Structured claim with evidence links
- Retention horizon
- Incident
- Scope
INC-204response team- Lifecycle state
- Unconfirmed candidate
- Retrieval trigger
- Mitigation planning or hypothesis review
- Authority
- Operational hypothesis, not service truth
- Retention and erasure check
- Expire at closure or supersede when evidence changes
-
Failed deployment and rollback attempt
- Object or claim
- Failed deployment and rollback attempt
- Source
- Deployment system and rollback log
- Functional role
- Episodic event
- Representation form
- Explicit records with event time
- Retention horizon
- Service incident history
- Scope
- Checkout operations
- Lifecycle state
- Observed event with later outcome
- Retrieval trigger
- Timeline review or another rollback proposal
- Authority
- Event evidence from operating systems
- Retention and erasure check
- Retain by incident policy and erase covered identifiers
-
Current service owner
- Object or claim
- Current service owner
- Source
- Live ownership system
- Functional role
- Factual and entity-oriented
- Representation form
- Structured entity projection
- Retention horizon
- Cross-session
- Scope
- Authenticated incident workspace
- Lifecycle state
- Current until rota change
- Retrieval trigger
- Escalation or assignment
- Authority
- Live ownership system
- Retention and erasure check
- Replace on rota change and clear stale projections
-
Approved rollback runbook
RB-17- Object or claim
- Approved rollback runbook
RB-17 - Source
- Versioned runbook registry
- Functional role
- Procedural
- Representation form
- Document with structured steps
- Retention horizon
- Workspace
- Scope
- Authorized Payments SRE roles
- Lifecycle state
- Approved version
- Retrieval trigger
- Rollback consideration
- Authority
- Method guidance, not execution permission
- Retention and erasure check
- Withdraw the version and its retrieval entries
-
Derived comparison lesson: compare pool saturation before repeating rollback
- Object or claim
- Derived comparison lesson: compare pool saturation before repeating rollback
- Source
- Review linked to supporting incidents
- Functional role
- Experiential and semantic
- Representation form
- Derived claim with source links
- Retention horizon
- Cross-session workspace
- Scope
- Checkout reliability team
- Lifecycle state
- Reviewed derivation
- Retrieval trigger
- Before repeating rollback
- Authority
- Lower than supporting event evidence
- Retention and erasure check
- Recheck when support changes and erase covered derivatives
-
Delayed certificate check
- Object or claim
- Delayed certificate check
- Source
- Incident action item
- Functional role
- Prospective
- Representation form
- Durable task and named trigger
- Retention horizon
- Until completion, cancellation, or expiry
- Scope
- Checkout deployment workflow
- Lifecycle state
- Pending
- Retrieval trigger
- Next deployment reaches its stated wait point
- Authority
- Intention, not execution permission
- Retention and erasure check
- Scheduler tracks completion and removes expired task copies
-
Checkout service view
- Object or claim
- Checkout service view
- Source
- Projection over sourced records and live systems
- Functional role
- Entity view joining roles, not a new cognitive store
- Representation form
- Hybrid entity projection
- Retention horizon
- Workspace
- Scope
- Authorized checkout responders
- Lifecycle state
- Derived current view
- Retrieval trigger
- Service page or incident query
- Authority
- Each field retains its own authority
- Retention and erasure check
- Rebuild or erase projections when sources change
The runbook cannot authorize a rollback. The delayed check cannot wake itself. A scheduler or workflow must hold the trigger state, while a trusted host still decides whether a permitted operation may run.
Bounded product mapping
Current ContextDB mapping
Current ContextDB behavior
As checked against repository snapshot d59c1b9 on , the pinned Apache SDK is Available. Direct factual extraction is Alpha. Asynchronous Formation is Hosted Alpha. The SDK and hosted paths implement a narrower set of memory operations than the neutral roles described here. Hosted Formation produces sourced factual candidates. Those facts do not mean ContextDB forms working, episodic, procedural, experiential, prospective, entity, or multimodal memory.
Types FAQ
Questions about agent memory types
Can one agent memory record belong to more than one type?
Yes. A deployment event can be episodic because it records what happened, factual because it states an outcome, and entity-oriented within a service view. Keep each role explicit. Multiple labels do not increase authority. Source, time, status, and scope still determine how later work may use the record.
Is short-term memory the same as working memory?
No. Short-term names a retention horizon, while working memory names active task use and manipulation. A session cache may be short-lived without supporting current work. Working state may also be durably checkpointed across calls. Agent designs use both terms by analogy, so name role and horizon separately.
Is entity memory a separate cognitive type?
Entity memory can be an entity-centered organization or projection, not evidence of a separate software faculty. It can assemble facts, events, procedures, and pending tasks for one resolved entity. The design must preserve each item's source and role. Identity resolution must not rely on a display name alone.
When does an agent need prospective memory?
An agent needs prospective memory when it must retain a delayed intention, then react to a named time, event, or state cue. The record should include task state, trigger, owner, cancellation, and expiry. A scheduler or workflow must detect the cue because storing an intention does not execute it.
Is an embedding itself a memory?
An embedding can carry a representation for similarity retrieval, but it is not inherently authoritative memory. One contract keeps the sourced record, status, version, time, and scope separately, then uses the embedding as an index entry. Another contract must still explain provenance, updates, access, and erasure.
How should procedural memory be scoped?
Scope procedural memory to the actors, agents, environments, versions, and tasks allowed to use the method. Keep execution authority separate. A rollback runbook can explain approved steps without permitting service changes. Supersede withdrawn procedures, and apply erasure or archival rules to copies and retrieval entries.
Source ledger
Primary sources and maturity
The ledger records direct primary URLs, publication maturity, and the boundary of each source. Cognitive research supplies analogical terms. Agent research supplies proposed designs and evaluated examples, not a universal taxonomy.
- External research Baddeley and Hitch, Working Memory, 1974. Foundational scholarly chapter. Grounds the human working-memory term, not an agent implementation.
- External research Tulving, Episodic and Semantic Memory, 1972. Foundational scholarly chapter. Grounds the human distinction, used here by analogy rather than as software equivalence.
- External research Squire, Memory Systems of the Brain, 2004. Peer-reviewed review. Supports interacting human systems, not separate software stores.
- External research Rummel and Kvavilashvili, Current Theories of Prospective Memory, 2023. Peer-reviewed review. Grounds delayed intentions but does not define an agent scheduler.
- External research Sumers and colleagues, CoALA, 2024. Peer-reviewed TMLR paper. Supports proposed working, episodic, semantic, and procedural modules.
- External research Hu and colleagues, Memory in the Age of AI Agents, 2025 (revised 2026). External preprint. Supports a proposed forms, functions, and dynamics frame, not consensus.
- External research Zhang and colleagues, ACM TOIS, 2025. Peer-reviewed survey. Supports a survey frame across sources, forms, operations, and limits.
- External research Park and colleagues, Generative Agents, 2023. Peer-reviewed UIST paper. Illustrates a memory stream, retrieval, reflection, and planning in its simulation.
- External research Zhao and colleagues, ExpeL, 2024. Peer-reviewed AAAI paper. Illustrates retained trajectories and derived insights in its evaluated tasks.
- External research Wang and colleagues, Voyager, 2024. Peer-reviewed TMLR paper. Illustrates an executable skill library in the studied Minecraft setting.
- External research PM-Bench, 2026. COLM conference paper with linked arXiv record. Supports delayed-intention and cue evaluation in its published task.
- External research AWS AgentCore memory types. Living vendor documentation. Illustrates one vendor's labels, not the neutral classification method.