The memory layer for AI agents

One memory for every AI agent and every agent framework.

  • Agents forget. Semurg remembers: facts and relationships written once, found again by the next agent, the next session and the next framework, each fact with where it came from.
  • Every framework, one memory: LangChain and LangGraph, CrewAI, Microsoft Agent Framework, OpenAI Agents SDK, LlamaIndex, Mastra, Google ADK, Pydantic AI and the Vercel AI SDK have run end to end; Claude Code, Hermes Agent and OpenClaw connect with their own configuration (the integrations).
  • Knowledge graph, vector search and graph RAG, built in: six memory tools over MCP or plain HTTP (remember, recall, relate, forget, context and status), with vector search and graph RAG on the same copy of the data. Memory recall starts from the names you give it and walks their relationships.
  • Bigger than RAM, on your own hardware: the engine's data lives on your disks, on-premises with no external cloud; built to grow past one node, licensed per node.
  • One engine, written from scratch, for ten data domains: the memory is the same store that serves graph, vector, document, time-series, relational, columnar, key-value, object, streaming and search, in one on-disk format, each measured in the open.
curl -fsSL https://one.semurg.io/install | sudo bash

Ubuntu 24.04 on x86_64, as root. What it needs, and what it changes.

The memory layer for AI agents and agent frameworks

Every agent, every framework

Point any MCP client at your node, or call the same verbs over plain HTTP and the client SDKs. Nine frameworks have run end to end and three agents have connected, each on a named release.

Memory that outlives the session

What one agent learns, the next agent, session and framework finds again. Scopes keep a team's memory shared and a user's private; forgetting supersedes, nothing is erased.

Knowledge graph, vectors and graph RAG in one engine

Facts and their relationships are kept as a knowledge graph, vectors live in the same store, and graph RAG finds the nearest vectors and then walks the graph: no separate vector database, graph database or retrieval service to run or keep in step. Memory recall starts from the names you give it and walks their relationships.

Why one engine

Graph Vector Docu-ment Time-series Rela-tional Colum-nar Key-value Object Stream-ing Search TEN STORES, TEN COPIES COLLAPSE SEMURG one engine, one on-disk format one copy of the data One thing to run. One to back up. One copy, so nothing to keep in step.
Memory spans every shape of data. Ten stores would be ten copies to keep in step; one engine holds one copy, read every one of those ways. The engine is written from scratch: its storage is its own, not a layer over PostgreSQL, RocksDB, Lucene or any other database.

Measured in the open, across ten data domains

  • Graph and vector recall first, then the other eight domains, each against the engines teams use today.
  • Same data, same question, both engines: the answers must match before anything is timed.
  • Results publish per domain as they are measured, win or lose. There are no figures on this site that were not measured on a named release.
  • A fairness bar applies to both sides: same data, same questions, both engines driven as hard as the machine allows, and the answers checked to match before any timing counts.

Start free, on your own hardware

Download the signed installer, verify it, and run a node. Your data stays on your machine: there is no account, no upload and no call home.

The first node is free, forever. Paid licences begin at the second node, either bought once for the life of that hardware or paid year by year, and updates are free.

Free
first node, forever
Free
updates, every node, forever
Per node
licence, lifetime or annual
Ten
data domains, one store

What to know before you start

The things worth saying plainly, on the front page rather than in a footnote.

  • Writes go straight to disk. Semurg writes each 64-byte container straight to the drive, append-only: no RAM buffer first, no write-ahead log, no page cache and no fsync. A write is acknowledged only after the drive has completed it, each container lands whole or not at all, and nothing already on disk is ever rewritten, so a stopped or killed process loses nothing it acknowledged. A single node is free and is what it is: a sudden power cut or an operating-system crash can lose its most recent writes (the last few seconds on ext4, the filesystem we run on; longer on xfs).
  • Network durability starts at the second node. Replication across nodes is being wired in now: once it lands, most writes will also be copied to another node's disk, or to more than one, as you choose, and that second copy is what disaster recovery will use; object writes, deletes and guarded writes stay on one copy at first. A write whose copy cannot be made still succeeds on its home node and its reply says it is degraded (a strict setting refuses it instead). The newest write of a container is the one that counts, so no consensus protocol is needed. We have designed, but not yet built, a rule for a split network: the newest write wins when the two sides meet again, and the other copy is kept and flagged as a conflict. Today, a write whose home node is out of the cluster is refused, never taken silently by another node.
  • The second node and every one after it are licensed per node, and the keys come from us: start on the free node, then talk to us about the cluster you need.
  • Serving open-weight models from the same store is in progress, and the speed work is not finished.
  • Benchmarks publish domain by domain as they are measured, against the incumbents on one box, wins and losses alike (the results); some results are being measured again on the current release.