Ferrosa Memory · Developer Preview

Agent memory with structure, not just search.

Most tools bolt a vector store onto your app and call it memory. Ferrosa Memory gives agents typed primitives — plans, bi-temporal facts, an entity graph, trajectory folds, and feedback-aware recall — over a durable, S3-backed distributed store you run yourself. MCP-native and self-hosted today, with a managed service on the way.

Set Up Ferrosa Memory See what it does →

Why it's different

Memory that's typed, linked, and inspectable — not a blob of embeddings.

Generic memory layers store text and rank it by similarity. Ferrosa Memory models the things agents actually need to remember as first-class data you can query, update, and audit — nearly 80 MCP tools across two tiers, on durable Ferrosa storage.

Typed memory primitives

Plan trees, bi-temporal facts with supersession (most-recent-valid retrieval), a named entity graph with phonetic dedup and multi-hop Cypher, trajectory folds (branch-and-collapse with semantic recall over summaries), and memoization to skip redundant LLM calls.

PlansBi-temporalEntity graphFolds

Recall that improves with use

Hybrid retrieval over vector (HNSW), full-text (BM25), and phonetic candidates, with task-aware query decomposition and feedback-aware reranking that adapts to your workspace. Forgetting is explicit and auditable, with Datalog-derived facts on top.

Hybrid retrievalRerankingAuditable forgettingDatalog

Built on a real distributed store

Not a wrapper around your vector DB. Memory lives in Ferrosa Database — durable, S3-backed storage with vector, BM25, and phonetic indexes plus a property graph in one engine, so a new node serves from object storage in seconds.

S3-backedDurableOne engine

How it compares

Most "agent memory" is a vector store with a wrapper.

The common pattern bolts a memory SDK onto a vector database or Postgres: text in, similar text out. That covers semantic recall, but not the structure agents need — plans, evolving facts, relationships between entities, or why a memory was retrieved.

Ferrosa Memory keeps those as typed data on a store designed for it: hybrid indexes, a property graph, bi-temporal facts, and inspectable operations — so memory is something you can query, correct, and audit, not a black box of embeddings.

See the full comparison →

Memory layer vs. memory service

Typical memory layer: an SDK over your own vector DB; add and search; similarity only; you own durability and ops.

Ferrosa Memory: a self-hosted service with typed primitives, hybrid + graph retrieval, bi-temporal facts, and auditable forgetting on a durable distributed store.

Memory viz preview. Inspect linked memory as a graph.

Operations view. Inspect node status and metrics from a running Ferrosa system.

From workgroup to enterprise

Start on one box. Grow into a cluster. Managed is coming.

Small team, self-hosted

Run the MCP server with native binaries and local filesystem storage on a single machine — your team's shared memory in minutes. Point Claude Code or any MCP client at it.

Scale to a real cluster

The same memory runs on a Compose cluster with S3/MinIO durability and replication. The distributed Ferrosa store underneath handles growth, with a new node serving from object storage in seconds.

Managed service — coming

A hosted, managed memory service is on the roadmap for teams that want the API without running infrastructure. Same primitives, same model.

Follow the roadmap →

The store underneath

Built on Ferrosa Database.

Ferrosa Memory runs on Ferrosa Database — a Rust-native, CQL-compatible distributed store with S3-backed durability, secondary and vector search, Cypher graph queries, SPARQL, and transactions. It's also usable on its own for operational workloads.

Explore the Database →

Ferrosa Database

CQLGraphSPARQLVector searchS3-backed

Developer-preview behavior should be tested with your workload before production use.

Give your agents memory in a few minutes.

Install a local developer preview for macOS or Linux, then point your MCP client at it.

# Ferrosa Memory + LLM onboarding
curl -fsSL https://ferrosadb.com/setup-memory.sh | bash

# Just the database
curl -fsSL https://ferrosadb.com/install.sh | bash

Memory setup runs minimal native binaries with local filesystem storage, or a full Compose cluster with optional MinIO. Nomic embeddings are optional; without them semantic/vector search is degraded.

Memory Quickstart How it works