Engrava

The memory database for AI agents.

Graph memory, hybrid search, and an optional tamper-evident journal.
Runs on SQLite. No server required. No LLM in the core write path.

$ pip install engrava

Building a serious AI agent means dealing with memory.

A vector index alone misses structure. A separate graph database adds operational weight. LLM-written memory can store too much by default. Engrava keeps the data layer local, typed, and deterministic.

Engrava is different.

Quick start

Two calls: remember to store, recall to search. Auto-embed. No IDs, no vector plumbing.

import asyncio

from engrava import SqliteEngravaCore


async def main():
    # from_config opens and owns the connection (schema + PRAGMAs applied).
    async with await SqliteEngravaCore.from_config("engrava.yaml") as store:
        # Store a memory in one call — no IDs, no record to assemble.
        await store.remember("User prefers concise answers")
        await store.remember("User works in Berlin")

        # Hybrid search: FTS5 + vector + recency + priority + graph.
        result = await store.recall("what does the user prefer?")
        for thought_id, score in result.results:
            print(score, thought_id)


asyncio.run(main())

Full API reference in the docs.

What you get

Twelve primitives. One pip install. No required service, no per-operation meter, no egress unless you configure a remote provider.

Why engrava.

The memory database for AI agents — not a layer over someone else’s store. Engrava ships graph memory, hybrid search, deterministic consolidation, and an optional tamper-evident journal in one local developer workflow. No service to run unless you choose one, no per-operation meter, and no data leaving your process unless you configure a remote provider.

Built from two years of cognitive-architecture research. MIT-licensed.

How engrava compares

Graph-first. Local by default. No required service. Everything in one developer workflow.

FeatureEngravaHosted MemoryGraph DBVector DB
Default deploymentembedded SQLitehosted or server pathseparate graph store or embedded modeserver or embedded options
Memory structuretyped thoughts + typed edgesvaries by platformrich graph modelprimarily vectors
Retrieval modelFTS + vector + recency + priority + graphvaries by platformgraph traversal firstvector search first
Deterministic consolidationlocal signals and gatesplatform-dependentnot usually memory policynot usually memory policy
Audit postureoptional thought/edge journalvaries by platformdatabase logs varydatabase logs vary
Language-model extractionoutside the databaseoften built inbring your own layerbring your own layer
Operating modelone local file, one writerexternal service boundarygraph persistence boundaryindex persistence boundary
License modelMITvariesvariesvaries

Why Engrava over managed alternatives?

  • The bundle is the point. A query language, optional tamper-evident journal, thought→action records, and typed edges live together in one local developer workflow, without multi-service wiring.
  • Deterministic, not a black box. Consolidation runs on fixed signals and gates. You can reproduce the consolidation path; when journaling is enabled, mutations are recorded in a hash-chain journal.
  • One file, truly embedded. Engrava is for the local-file case: typed edges, thoughts, and search metadata in one SQLite store, with no daemon and no LLM key for the core write path.
  • Your data stays put. Engrava runs in your process. Data only leaves that process if you configure a remote provider yourself.

How dreaming works

Every thought in Engrava has a score. Engrava computes it from five signals — recency, staleness, confirmation, confidence, and frequency — then passes them through gates — a minimum-confirmations check, a promotion threshold, and a per-cycle cap — to decide what gets promoted and consolidated.

No language-model call. Deterministic. Configurable in YAML.

Read the full story →

Install & configure

One pip install. Optional extras for embedding backends. One YAML file for the rest.

Install

# Basic
pip install engrava

# With local embeddings (sentence-transformer)
pip install engrava[embeddings-local]

# With OpenAI-compatible embeddings (OpenAI, Azure, Groq, vLLM, LiteLLM)
pip install engrava[embeddings-openai]

# Alt: Ollama (local LLM server) or HuggingFace Inference API
pip install engrava[embeddings-ollama]
pip install engrava[embeddings-hf]

Configure — engrava.yaml

# engrava.yaml
database:
  path: "./agent.db"

embeddings:
  provider: "sentence-transformer"    # or "openai-compatible", "ollama", "huggingface"
  model: "all-MiniLM-L12-v2"
  auto_embed: true

extensions:
  dreaming:
    enabled: true
    promote_threshold: 0.75
    signals:                # name -> weight (sum ~1.0)
      recency: 0.25
      staleness: 0.20
      confirmation: 0.20
      confidence: 0.15
      frequency: 0.20
    gates:
      min_confirmations: 2
      max_promoted_per_run: 20

journal:
  enabled: true   # optional tamper-evident journal (SHA-256 hash chain)

Full configuration reference in the docs.

Built from research.

Engrava was extracted from research at Sovantica on cognitive architectures for AI agents — what kinds of memory, attention, and consolidation a long-running agent actually needs to operate beyond a single session. After a requirements-first implementation and a large test suite, the persistence layer proved useful enough to ship standalone.

The dreaming algorithm is deterministic consolidation, not a language-model rewrite step. The optional audit journal gives you integrity evidence for thought and edge mutations when journaling is enabled.

Built on foundations from sleep consolidation, hippocampal pattern separation, and predictive coding. Read the full story →