Glossary

Short-term memory

Conversations and messages, with sequential FIRST_MESSAGE / NEXT_MESSAGE linking and embedded message content for similarity search. Accessed via client.short_term.

Long-term memory

Entities (POLE+O or custom typed), preferences, and facts. The declarative knowledge layer. Accessed via client.long_term.

Reasoning memory

Reasoning traces, reasoning steps, and tool calls — captured per agent task. The "how did we get there" layer that complements the "what we know" of long-term memory. Accessed via client.reasoning.

POLE+O

The default entity ontology — Person, Object, Location, Event, Organization. See POLE+O Model.

:Entity super-label

The label every long-term memory entity carries in addition to its type/subtype labels (e.g. :Entity:Person:Individual). The library MERGEs on (:Entity {name, type}) for deduplication.

Adoption

The process of attaching the :Entity super-label and library-managed properties (id, type, name) to nodes from a pre-existing domain graph, so the library’s writes link to the existing nodes instead of duplicating them. See Adopt an Existing Domain Graph.

Backend

Which storage MemoryClient talks to: bolt (your own Neo4j, the historical default) or NAMS (the hosted service). Selected at config time; the high-level API is identical. See Bolt vs NAMS.

NAMS

Neo4j Agent Memory Service — the hosted, multi-tenant backend at memory.neo4jlabs.com. A managed REST API; you bring an API key, not a database.

Workspace

The unit of hard isolation on NAMS — its own graph. A workspace key is bound to one workspace; an admin key selects it per request via the X-Workspace-Id header. The user_identifier= axis sub-divides users within a workspace. See Tenancy & scoping and key categories.

Bridge protocol

The non-REST wire format (POST /{snake_case_method}) used by the cross-language TCK reference clients. The SDK transport auto-selects REST (for /v{n} endpoints) or bridge; override with NamsConfig(transport_mode=…​).

Provider string

A shorthand for an LLM or embedding model — "anthropic/claude-3-5-sonnet-latest", "openai/text-embedding-3-small" — resolved to a native adapter or LiteLLM. Used on the bolt backend; on NAMS, embedding runs server-side. See Bring Your Own Model.

Agent Skill (Preview)

A portable, self-contained procedure — an agentskills.io SKILL.md package — that NAMS distils from a workspace’s accumulated memory so another agent can load and reuse it. See Agent Skills.

Skill distillation (Preview)

The server-side NAMS pipeline that turns a scoped slice of memory (messages, entities, reasoning traces) into an Agent Skill: scope → snapshot → grounded synthesis → quality gates → package. Reachable over REST + MCP only.

Provenance grounding

The rule that every claim and procedure step in a distilled skill is GROUNDED_IN specific source nodes — the graph is the authority and the LLM only writes from cited sources, so a skill is auditable, not invented.

Attestation

A detached JWS signature over a published skill’s contents, verifiable offline against the public JWKS at /.well-known/skill-attest-jwks.json.

Context graph

The full three-layer graph this library builds (short-term + long-term + reasoning).

Zep uses "context graph" to describe a persisted graph attached to a session. neo4j-agent-memory’s closest analogue is the unified graph spanning the three memory layers, with cross-layer edges like `(ReasoningTrace)-[:INITIATED_BY]→(Message).

Memify / memification

Long-term memory ingestion (add_entity, add_preference, add_fact) plus the entity-extraction pipeline.

Cognee’s "memify" pipeline corresponds roughly to entity extraction
deduplication + embedding here. The library does not bundle a single-call "memify(text)" entry point — extraction and storage are separate by design.

Core memory

Long-term memory (entities, preferences, facts) — the persistent, queryable layer.

Letta’s "core memory" maps to long-term memory, especially preferences and entity-attached attributes that persist across sessions.

Episodic memory

Short-term memory (messages and conversations).

Several agent frameworks distinguish "semantic" (long-term) from "episodic" (per-session). neo4j-agent-memory uses short-term / long-term, with reasoning memory as a third axis that doesn’t fit either label cleanly.

Working memory

Not a first-class concept here.

What other systems call "working memory" (current-turn context) is typically assembled per-call via client.get_context(…​) rather than persisted as its own layer.