Memory

Memory defines the persistent and recallable knowledge surface that allows a Unitt to operate beyond the boundary of a single context window. Memory architectures inside Emergence are designed to extend short-lived runtime context into durable operational state, allowing agents to retain prior observations, decisions, reasoning traces, validated outcomes, and learned behaviors across long-running workflows and multi-session deployments. The platform treats memory as a first-class runtime substrate that combines working state, episodic recall, semantic knowledge, and procedural skills into a unified memory surface that is governable, inspectable, and optimizable over time.

Memory architectures in Emergence are informed by the cognitive memory typology used in modern agentic research, including MemGPT / Letta-style virtual context paging, Generative Agents observation-reflection memory streams, the CoALA cognitive architecture framework for language agents, A-MEM Zettelkasten-style self-organizing memory networks, Mem0 extraction-and-consolidation pipelines, and HippoRAG 2 neurobiologically inspired long-term indexing. Selection criteria for picking a memory architecture for a given Unitt workload are documented in Research › Memory Systems.

Memory Tiers

Emergence organizes memory into four functional tiers that mirror the cognitive-science memory typology adopted by CoALA and the modern agentic stack. Each tier has a distinct write trigger, recall strategy, eviction policy, and governance boundary, allowing the runtime to retrieve the smallest sufficient memory surface for any given workflow stage. Tiered memory reduces context bloat, controls retrieval latency, and keeps governance enforcement deterministic across long-running execution sessions.

flowchart LR
    R[Agent Runtime] <--> W[Working Memory]
    R <--> E[Episodic Memory]
    R <--> S[Semantic Memory]
    R <--> P[Procedural Memory]

    W -. consolidates .-> E
    E -. abstracts .-> S
    E -. distills .-> P

    classDef tier fill:#ffd541,stroke:#222021,color:#222021
    class W,E,S,P tier

Working Memory

Working memory holds the active runtime context that the agent is currently reasoning over. It includes the most recent user turn, the current Thought/Action/Observation trace, scratchpad notes, transient tool results, and the immediate planning surface used by the active runtime pattern. Working memory is intentionally bounded by the context window and managed by the State layer, which decides what is promoted into working memory, what is summarized, and what is evicted on each turn.

Episodic Memory

Episodic memory stores time-stamped runtime events; observations, decisions, tool calls, sub-objective completions, governance escalations, validation outcomes; so the agent can recall what happened during a prior session, workflow stage, or runtime episode. Episodic memory is the primary substrate behind reflection patterns, replay debugging, regression testing, and outcome attribution. Each episode is associated with importance, recency, and relevance scores so the recall pipeline can rank stored events similarly to the Generative Agents memory stream.

Semantic Memory

Semantic memory stores durable factual knowledge that the agent has learned, validated, or been authorized to use across sessions; company profiles, product specs, customer relationships, decision records, ontology definitions, and operational invariants. Semantic memory is typically backed by a hybrid vector + graph + structured store and is the default substrate for retrieval-augmented reasoning. Unlike episodic memory, semantic facts are not time-bound and may be deduplicated, merged, or updated when new validated information arrives.

Procedural Memory

Procedural memory stores reusable skills, validated patterns, and learned execution strategies that the agent should apply when similar workflows recur. Procedural memory is the substrate behind skill libraries inspired by Voyager, where validated tool-use sequences, reasoning shortcuts, and successful workflow templates are promoted into a reusable library that the runtime can recall and re-apply. Procedural memory connects directly to the Assembly Skills layer and is governed by the same policy and validation gates.

Memory Lifecycle

The lifecycle of a memory item moves through five stages; observe, write, consolidate, recall, and evict; each governed by explicit policies, validation gates, and audit trails. The lifecycle is designed to be inspectable and reversible, so that every memory item can be traced to its originating event, validated against governance constraints, and selectively forgotten when policies, retention windows, or runtime conditions require it.

flowchart LR
    O[Observe] --> WR[Write]
    WR --> C[Consolidate]
    C --> RC[Recall]
    RC --> EV[Evict]
    EV -. selective forget .-> WR
    C -. reflection writes .-> WR

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class O,WR,C,RC,EV stage

Observe

The runtime continuously emits observation events from tool calls, connector responses, user turns, validation outcomes, reflection passes, and governance decisions. Observations are filtered against a write policy that decides whether an event is durable, transient, or sensitive, and routes durable events into the appropriate memory tier with the correct provenance, scope, and retention metadata.

Write

A write commits an observation, summary, fact, or skill into one or more memory tiers. Each write records the source event, the writer (agent, subunit, or reflection pass), the destination tier, the tags or graph edges produced, the importance score, the retention policy, and the governance scope. Write paths are governed by Core › Policies so that sensitive observations never reach long-term memory, and so that all writes remain auditable.

Consolidate

Consolidation moves recent items from working to episodic memory, abstracts repeated episodes into semantic facts, and distills successful workflows into procedural skills. Consolidation runs both synchronously, during reflection passes inspired by Reflexion, and asynchronously, during quiet runtime windows when the agent is not under load. Consolidation is also the moment when A-MEM-style dynamic links are added between related memory items, allowing the memory network to self-organize over time.

Recall

Recall is the read path that pulls the smallest sufficient memory surface into working memory at each runtime step. Recall is a ranked retrieval over importance, recency, and relevance, optionally augmented with graph traversal, hybrid BM25 + dense retrieval, late chunking, and contextual preambles in the style of Anthropic Contextual Retrieval. The recall pipeline returns a packed, cache-friendly context block ordered to maximize prompt-cache reuse on the next model call.

Evict

Eviction removes items from a tier based on retention policy, decay, redundancy, or governance directive. Working memory items are evicted by the State layer at every turn. Episodic items decay by recency and are pruned once consolidated into semantic or procedural memory. Semantic and procedural items are evicted only by explicit policy or by validated supersession, ensuring that durable knowledge is never silently lost.

Recall Pipeline

The recall pipeline assembles the working memory surface for each runtime turn. The pipeline is designed to be deterministic, governance-aware, and prompt-cache-friendly, so that long-running sessions remain cheap, observable, and reproducible. Each stage is independently configurable, allowing different Unitts to tune the recall strategy to their workload profile.

flowchart TD
    Q[Runtime Query] --> R1[Recency Scan]
    Q --> R2[Vector Retrieve]
    Q --> R3[Graph Expand]
    Q --> R4[Structured Lookup]

    R1 --> M[Merge & Rank]
    R2 --> M
    R3 --> M
    R4 --> M

    M --> F[Policy Filter]
    F --> S[Summarize / Compact]
    S --> P[Pack Context]
    P --> A[Agent Runtime]

    A -. write-back .-> WR[Memory Writers]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class Q,R1,R2,R3,R4,M,F,S,P,A,WR stage

The runtime query is decomposed into parallel retrieval calls; a recency scan over recent episodic events, a dense vector retrieval over the semantic store, a graph expansion that follows links from anchor items in the style of HippoRAG personalized PageRank, and a structured lookup against indexed fields such as entity IDs, workflow stage, or session ID. Results are merged, deduplicated, and ranked using a configurable scoring function that combines importance, recency, relevance, and trust signals.

Ranked results pass through a policy filter that drops items violating scope, retention, or sensitivity rules from Core › Policies. Surviving items are summarized or compacted if they exceed the configured working-memory budget, then packed into the context window in cache-friendly order so the model can reuse prefix caches across consecutive turns.

Storage Substrates

Emergence does not prescribe a single storage backend. The memory layer is a substrate-agnostic interface that can be implemented over vector databases, graph databases, structured stores, object storage, or hybrid combinations of all of them. The recommended pattern is a hybrid layout that uses the right substrate for each tier and provides a unified read path through the recall pipeline.

Tier	Recommended Substrate	Why
Working	In-process context buffer + scratchpad	Bounded by context window, no I/O latency on hot path.
Episodic	Append-only event log + vector index	Time-ordered, replayable, supports recency + relevance scoring.
Semantic	Vector store + property graph	Hybrid dense retrieval with relational traversal for entities and facts.
Procedural	Versioned skill library + workflow store	Validated skills with provenance, version history, and replay tests.

Reflection And Self-Organization

Memory in Emergence is not passive storage. The runtime performs scheduled reflection passes that re-read recent episodic events, synthesize higher-level abstractions, propose new semantic facts, distill candidate procedural skills, and add cross-links between related memory items. Reflection passes are bounded by budget and validated against governance policies before any write is committed.

flowchart LR
    EP[Episodic Stream] --> RF[Reflection Pass]
    RF --> ABS[Abstract Facts]
    RF --> SK[Candidate Skills]
    RF --> LK[Cross-Links]

    ABS --> GV[Governance Gate]
    SK --> GV
    LK --> GV

    GV -->|approved| SM[Semantic Memory]
    GV -->|approved| PM[Procedural Memory]
    GV -->|approved| AM[Memory Graph]
    GV -->|rejected| AUD[Audit Trail]

    classDef stage fill:#ffd541,stroke:#222021,color:#222021
    class EP,RF,ABS,SK,LK,GV,SM,PM,AM,AUD stage

Reflection is the mechanism that turns raw execution history into durable operational knowledge. It is also the primary surface where governance enforces what may be remembered: sensitive observations are filtered, contested facts are escalated, and any rejected reflection result is preserved in the audit trail rather than silently dropped.

Governance Of Memory

Memory is one of the most governance-sensitive surfaces in the platform because what an agent remembers directly shapes its future behavior. Every memory write, recall, consolidation, and eviction is subject to the same policy and governance enforcement as tool calls and connector usage.

Memory Governance Requirements

• Every write records source event, writer, destination tier, scope, retention, and importance.
• Sensitive observations are filtered against policy.md before any persistent write.
• Recall results are policy-filtered before entering working memory.
• Reflection writes pass an explicit governance gate before they are committed.
• Eviction is reversible within the configured retention window and recorded in the audit trail.
• Selective forgetting can be triggered by policy directive, retention expiry, or compliance request.

Cross-References

• State describes how working memory is curated turn by turn.
• System describes the runtime patterns that drive memory writes and reflection.
• Subunits describes how memory is shared or isolated across subagents.
• WorldSim describes how memory behavior is validated under simulated workloads.
• Research › Memory Systems documents the selection criteria and source research behind each tier and pattern.