Local-first agentic memory - daemon available now

A cognitive memory kernel for agents that ship.

LibraVDB Memory gives serious agent teams a local daemon for scoped recall, causal continuity, constraint protection, predictive context, and operator-owned memory lifecycle. It is not a prompt trick, not a vector wrapper, and not a cloud dependency.

No telemetry. No phone home. No required LLM, reranker, hosted embedder, or API key.

Daemon available now

Run the local cognitive memory daemon today.

libravdbd ships as a compiled static binary through apt, AUR, Chocolatey, and Homebrew. It runs as operator-managed infrastructure; source code is closed source and protected by the LibraVDB Memory LICENSE and EULA.

apt AUR Chocolatey Homebrew

Host support

Use the daemon from the agent stack you already run.

LibraVDB Memory keeps recall, compaction, graph maintenance, and lifecycle state inside libravdbd. Host integrations stay thin and explicit.

Live memory test

See LibraVDB Memory running in public.

Join the Discord and visit #bots-everywhere, where community-run bots stay connected around the clock with LibraVDB Memory behind them. Tell a bot a fact, come back sessions later, and test whether durable recall survives real conversation.

24/7 bots global testers cross-session recall
Join the Discord

Continuity is the difference between a demo and a system.

LibraVDB Memory keeps facts, constraints, decisions, and temporal context connected across turns and sessions, so agents can carry what matters forward without treating memory like a pile of nearby chunks.

Vectors are not enough

Embedding-only recall drops exact identifiers, file paths, flags, stale decisions, hard constraints, and the causal path that made a result useful.

Context needs scope

Session turns, durable user facts, global rules, summaries, and current working context need distinct boundaries instead of one blended transcript pile.

Realtime agents need local paths

Robotics and autonomous runtimes cannot put every recall decision behind a remote memory service and still protect response time.

Useful recall needs credit

A serious memory kernel must learn which prior facts enabled the useful result, not only which item happened to be returned.

The cognitive kernel

Not a plugin. A cognitive memory kernel.

libravdbd owns the hard parts of memory: what to recall, what to protect, what to compact, what to forget, and what to reinforce. Host adapters stay thin; the daemon carries the cognitive load.

Recall

Exact and semantic memory in one path

Identifiers, file paths, constraints, decisions, and natural-language context are retrieved together instead of forcing agents to choose between brittle keyword search and fuzzy vector recall.

technical facts semantic context bounded recall
Control

Homeostatic retrieval control

TSK fuzzy controllers adapt retrieval, compaction pressure, contradiction handling, authority balance, exploration, and habit suppression from live memory signals.

TSK control adaptive scoring stable behavior
Causality

Memory that knows why it mattered

Useful recall reinforces the constraints, decisions, and causal paths that made the result possible, so the system learns more than access frequency.

causal graph counterfactual credit goal alignment
Compaction

Compression without amnesia

Long sessions are compacted with protected anchors, rules, decisions, constraints, and recent working context preserved, instead of being flattened into lossy summaries.

anchor protection constraint preservation local compaction
Reasoning

Symbolic protection for serious instructions

Rules, prohibitions, permissions, identity facts, and hard constraints are treated as protected operational state, not decorative text inside a summary blob.

deontic logic protected rules hard constraints
Consolidation

Important memory stops behaving like cache

Repeated usefulness strengthens durable memory and its supporting causal context, while low-value noise can decay, compact, or be removed under operator control.

synaptic tagging stability signals operator lifecycle
Deployment

Local-first by default, hosted when you want it

Run the daemon where the agent runs for response-time-sensitive workloads, or join the managed-service waitlist when hosted operations are the right tradeoff.

apt / AUR Chocolatey Homebrew
Operations

Memory belongs in infrastructure

Status, health, export, forget, journal, tenant isolation, and lifecycle hooks give teams a memory runtime they can operate instead of a hidden SDK side effect.

observable daemon isolated scopes controlled deletion

Hybrid recall core

Semantic recall, BM25-style exactness, graph proximity, temporal comparison, and optional second-pass precision work together for technical memory.

Causal graph memory

Memory is scoped state connected by why, how, temporal, and associative relationships instead of flat transcript fragments.

TSK homeostatic control

Fuzzy controllers tune scoring, compaction pressure, contradiction gates, authority, hop decay, information gain, and habit penalties from live signals.

Multi-timescale scheduler

Micro credit, meso structure learning, and macro consolidation let memory stabilize while the agent keeps working.

Counterfactual credit

Useful recall reinforces the decisions, constraints, and ancestor paths that made the result possible.

Synaptic consolidation

Stability signals, engagement credit, and proactive sweeps keep important memory from behaving like disposable cache.

Runtime architecture

The agent host stays thin. MCP bridges, OpenClaw plugins, or Hermes providers pass lifecycle events into libravdbd. The daemon owns recall, inference, graph maintenance, compaction, persistence, and lifecycle control behind a narrow operational boundary.

Agent / Robot HostAdapter / MCPlibravdbdHybrid Vector Graph StoreCognitive Scheduler

Private release

Be first to the hosted service.

The local daemon ships now through apt, AUR, Chocolatey, and Homebrew. The hosted managed version is in private release; join the waitlist for early access.