Choose memory for your application

Memory answers several different needs. Start with the state you need to retain, then enable only the stores that serve that task. An Agent without explicit memory still keeps fallback conversation history in process; reusing an owned session can recall earlier turns. Persistence across restarts requires a storage-backed configuration.

The mental model

Need	Use	Lifetime and boundary
Earlier turns in this conversation	Sessions	Session ID; host authorizes its owner
History across a restart	`memory.storage` with a persistent driver	Storage lifecycle belongs to the host or owning Agent
Compact older conversation context	Summaries	Session-scoped, model-generated
Preferences across sessions	User facts or profile	Verified user scope
People, companies, and relationships	Entities, graph	Store-specific ownership and retrieval
Reusable insights or reviewed fixes	Learnings, corrections	Vector retrieval and explicit sharing scope
Suggested tool sequences	Procedures	Guidance, not executable workflow recovery
Authoritative documents	Knowledge retrieval	Source corpus and retrieval policy

Quick Start

Inspect storage and ownership without involving a model. This example runs with @agentium/core@4.0.0 in an ESM TypeScript project:

import { InMemoryStorage, MemoryManager } from "@agentium/core";

const storage = new InMemoryStorage();
const memory = new MemoryManager({ storage, summaries: false, userFacts: true });
try {
  await memory.ensureReady();
  await memory.remember("Prefers concise answers", { userId: "alice" });
  console.log(await memory.getUserFacts()?.getActiveFacts("alice"));
  console.log(await memory.getUserFacts()?.getActiveFacts("bob")); // []
} finally {
  await storage.close();
}

The example records a manual fact and clears process-local storage on exit. To run a real conversation with persistent history, continue to Agent memory or the memory tutorial.

Full Configuration

UnifiedMemoryConfig requires storage. The optional fields choose behavior; they are not a reason to enable every store at once.

Field	Default / purpose
`maxMessages`	50-message soft history limit; complete recent turns are retained
`maxTokens`	Optional history token budget
`summaries`	On; `maxCount` defaults to 10 and `maxTokens` to 2,000
`userFacts`	Off; optional `maxFacts`, default 100
`userProfile`	Off; optional additional `customFields`
`entities`	Off; optional namespace, default `global`
`decisions`	Off; optional `maxContextDecisions`, default 5
`learnings`	Off; requires `vectorStore`; optional collection, topK, minScore
`corrections`	Off; requires `vectorStore`; retrieval and contradiction-invalidation options
`graph`	Off; requires `store`; optional `autoExtract` and `maxContextNodes`
`procedures`	Off; optional `maxProcedures`, default 50
`contextBudget`	Optional memory-context token allocation and section priorities
`model`	Optional extraction model; Agent primary model is the fallback
`timezone`	Optional IANA timezone for date-relative extraction; default UTC
`tenantId`	Scope used for tenant-aware learned/procedural retrieval; not authentication
`eventBus`	Optional memory event observer

See store configuration for typed composition. Vector and graph drivers have separate dependencies, credentials, and lifecycle responsibilities.

How It Works

Before a run, the memory manager builds context from enabled stores. Session history is a separate part of the model request. After a run, enabled extraction work can save new records. Extraction can incur model/embedding calls and finish asynchronously; drain owned work before closing resources. A saved record is not proof that a future model will follow it. Use deterministic application validation for rules that must hold. Inspect actual context and evaluate answers after memory changes.

Simplified API

remember, recall, and forget are convenience methods with specific store coverage. They are not universal CRUD across every store. Read their supported behavior, especially before exposing recall or deletion through an API.

Accessing Stores Directly

Getter methods return null when their feature is disabled. Check the result instead of hiding it with a non-null assertion. Direct access bypasses your HTTP authentication layer; the host must validate identities and resource ownership.

Multi-User Isolation

Use scoped storage and verified identity. Session IDs alone do not establish ownership. Learnings, procedures, corrections, entities, and graph records have different scope contracts; memory isolation describes where application control is required.

Observability

Observe extraction errors and inspect records from the same verified scope used by the run. Reconcile vector-backed stores after partial writes when needed. Keep maintenance, token budgets, and evaluation in the application development loop.

Build

Agent applications

Harness runtime

Teams and workflows

Data and capabilities

Interfaces and jobs

Voice and telephony

Verify and manage

Choose memory for your application

The mental model

Quick Start

Full Configuration

How It Works

Simplified API

Accessing Stores Directly

Multi-User Isolation

Observability

​The mental model

​Quick Start

​Full Configuration

​How It Works

​Simplified API

​Accessing Stores Directly

​Multi-User Isolation

​Observability

The mental model

Quick Start

Full Configuration

How It Works

Simplified API

Accessing Stores Directly

Multi-User Isolation

Observability