Skip to content

Memory Service

Cognition Memory Service is the typed memory authority for standalone agent reasoning. Distinct from Runtime memory bank scopes (which serve runtime-canonical memory), Cognition memory is about how an agent thinks with its memory — episodic, semantic, observational records with explicit lifecycle.

Six Artifact Families In Cognition

Cognition has six top-level artifact families. Memory is one.

FamilyPurpose
agent_model_kernelThe agent's local model of itself
world_model_kernelThe agent's local model of its world
memory_substrateTyped memory records
knowledge_projectionsTyped knowledge pages with first-class relations
skill_artifactsTyped advisory bundles (capability blueprints)
working_stateTransient cognition scaffolding (not durable)

Memory sits in the advisory tier — kernels are core truth; memory / knowledge / skill are advisory; working state is never served as truth.

Memory Operations

OperationBehavior
SaveSave a typed memory record
LoadLoad by id
ListList under typed filter
SearchSearch under admitted query
DeleteExplicit delete (not silent decay)
History / lineageRead history of memory record changes
Derived viewRead service-derived metadata views

Service-derived metadata (support, lineage, invalidation, cleanup) is service-owned, not caller-persisted. Apps don't construct metadata themselves; they read service-derived views.

Cognition Scope

Every cognition artifact belongs to exactly one scope. One scope contains exactly one agent_model_kernel + one world_model_kernel. Deleting a scope removes scope-owned artifacts.

PropertyValue
Scope cardinalityOne agent kernel + one world kernel per scope
Cross-scope referencesForbidden
Scope deletionRemoves scope-owned artifacts

A memory record cannot reference an artifact in a different scope; that would create cross-scope leakage.

Memory Artifact Lifecycle

StateReachable via
CreatedExplicit Save
Listed / RecalledList / Search / Load
Derived view readService-derived view methods
ArchivedDigest cleanup pass (reversible)
RemovedLater digest pass after archival, or explicit destructive delete

Archive and remove are separate passes. Same-pass archive-and-remove is forbidden — the platform refuses it. This is what makes archives reversible.

Reader Scenario: An Agent Saves And Recalls A Memory

An agent learns the user's birthday.

  1. Save. Agent calls MemoryService.Save with a typed memory record describing the learning. Service admits.
  2. Service-derived metadata. The service computes support, lineage, etc. Caller does not need to construct these.
  3. Recall later. Agent searches; the record is returned under typed query.
  4. Use in next turn. Brain layer consumes the recalled memory; behavior reflects "I remember your birthday."

The memory is durable; the recall path is typed.

Reader Scenario: A Digest Pass Archives Stale Memories

The digest routine periodically proposes which memories to clean up.

  1. Digest scans. The first admitted routine; acts on memory / knowledge / skill (never kernels).
  2. Refgraph reasoning. Each candidate is checked against the refgraph — incoming support, broken refs, dependency health.
  3. Archive proposals. Stale candidates proposed for archival.
  4. Archive (reversible). Approved candidates archived.
  5. Later pass. Subsequent digest pass may remove already-archived items.
  6. Audit lineage. Each step is traceable to specific refgraph reasoning.

Cleanup is explainable — not heuristic. A user (or auditor) asking "why was this archived" gets a typed answer pointing to specific broken refs.

Reader Scenario: An Explicit Delete

A user wants a specific memory to be deleted permanently.

  1. Explicit delete request. User invokes MemoryService.Delete on the record id.
  2. Cascade check. Service checks dependencies; explicit delete is destructive.
  3. Removed. Record is deleted under admitted contract.
  4. Audit. Deletion event recorded.

Explicit delete is separate from digest cleanup. Digest is proactive cleanup; explicit delete is user-driven destructive.

Cleanup Eligibility

FamilyCleanup eligibility
Kernels (agent / world)Never
Working stateOnly via explicit clear
Memory / knowledge / skillVia digest

Kernels are inviolate. They are core truth; advisory cleanup never touches them.

Boundary Summary

ConcernOwner
Memory recordsCognition Memory Service
Service-derived metadataService (not caller)
Refgraph reasoningCognition refgraph
Cleanup decisionsDigest routine + admitted policy
Cross-scope referenceForbidden

Source Basis

Nimi AI open world platform documentation.