Local-first TypeScript SDK · npm install wolbarg

Wolbarg

Shared semantic memory for AI agents

Wolbarg gives multiple agents one persistent memory they can all write to and search — stored locally in SQLite, retrieved by meaning, with a tiny TypeScript API.

No Redis glue. No JSON scratch files. No custom locking. Just remember() and recall().

$ npm install wolbarg

Get Started Documentation

Planner writes · worker recalls · same shared memory

Why it exists

Agents forget. Shared state gets messy.

Most multi-agent setups store knowledge in process memory, JSON files, or a generic key-value store. That works until you need persistence, concurrency, and search by meaning — not just by key.

Without Wolbarg

Each agent keeps its own isolated context
Developers invent shared state with globals or Redis
JSON dumps become the source of truth
No semantic search across what agents learned
Concurrency and crash safety are DIY

With Wolbarg

One shared semantic memory for the whole system
SQLite or PostgreSQL with durable, concurrent writes
Natural-language recall via embeddings
A small, stable TypeScript API
Local-first — no memory SaaS required

How it works

Write once. Recall by meaning.

The whole product fits in one loop: store text as vectors, keep the original, search later with natural language.

Step 1
Agent remembers
One agent calls remember() with a fact and optional metadata.
Step 2
Embedding generated
content.text is embedded through your OpenAI-compatible endpoint.
Step 3
Stored in SQLite + sqlite-vec
Original text, metadata, and vector land in a local ACID write.
Step 4
Another agent recalls
A different agent asks in natural language and gets ranked hits.

Core features

Built for real agent systems

Local-first

Start with a SQLite file on disk, or run PostgreSQL when you need shared multi-tenant storage. No hosted vector SaaS required.

Semantic recall

Agents ask in natural language. Wolbarg embeds the query and returns the closest memories by meaning.

Multi-agent by design

Many agents can write and read the same store safely. WAL mode (SQLite) and transactions handle concurrency.

SQLite + PostgreSQL

Pick the backend that fits: in-process SQLite with a vector index, or PostgreSQL with optional pgvector.

Tiny API

remember, recall, compress, forget, history, stats. Easy to drop into an existing agent loop.

Zero infrastructure

No Redis cluster, no queue, no sidecar. Install the package and point it at SQLite or Postgres.

Performance

Benchmarked for SQLite and PostgreSQL

v0.2.1 Storage suite with mock embeddings — dual-backend, full SDK path, reproducible in this repo. Storage (mock) ≠ LIVE (real providers).

SQLite search @ 1k

2.02 ms

Storage suite · mock embeddings

SQLite insert @ 1k

1.72k/s

remember() throughput

SQLite cold start

7.91 ms

ready() on clean store

PG 16 writers

1.12k/s

Local Docker pgvector

Compression @ 200

99.5%

Active-set reduction

Same workloads on SQLite and PostgreSQL (local Docker pgvector). Pick the backend that matches your deployment — numbers stay honest.

Feature comparison

✅ Supported · ⚠️ Partial · ❌ No · ❓ Unknown. No invented competitor timings.

Feature	Wolbarg	Mem0	Zep	Letta	Chroma	Qdrant	Weaviate	LlamaIndex	LangGraph Memory	Mastra
SQLite-based	✅	⚠️	❌	⚠️	⚠️	❌	❌	⚠️	⚠️	⚠️
PostgreSQL	✅	⚠️	⚠️	⚠️	❌	❌	❌	⚠️	✅	⚠️
Local-first	✅	⚠️	⚠️	⚠️	✅	⚠️	⚠️	⚠️	⚠️	⚠️
Memory Compression	✅	✅	⚠️	✅	❓	❌	❌	⚠️	⚠️	❓
Semantic Search	✅	✅	✅	✅	✅	✅	✅	✅	⚠️	⚠️
Hybrid Search	✅	⚠️	✅	❓	⚠️	✅	✅	✅	❓	❓
Open Source	✅	✅	⚠️	✅	✅	✅	✅	✅	✅	✅
Public Storage Benchmarks	✅	❌	❌	❌	⚠️	✅	✅	❌	❌	❌

View full benchmarks Methodology

Install and go

One dependency. Point it at SQLite or PostgreSQL and an OpenAI-compatible embedding endpoint.

$ npm install wolbarg

Setup Guide Quick Start

Read the docs

API reference, configuration, concurrency notes, and guides for shared multi-agent memory.

Open Documentation