Architecture
What is the Areev architecture?
Areev is a single Rust crate compiled into one static binary that combines an HTTP/gRPC server, an LSM-tree storage engine, full-text and vector search indexes, a knowledge graph, and envelope encryption into a self-contained context database.
The server layer uses Axum for HTTP (serving ~200 REST endpoints under /api/) and Tonic for gRPC. Both protocols share the same underlying AI memory engine, which coordinates writes, recalls, and forget operations across the storage and index subsystems. The engine enforces governance policy on every operation — retention checks, consent verification, and audit event emission happen inline, not as post-processing steps.
The storage layer uses Fjall, an embedded LSM-tree engine written in Rust, for durable grain persistence. On top of Fjall, three index subsystems provide different query modalities: Tantivy for BM25 full-text search, HNSW (via USearch or FAISS) for vector similarity search, and a hexastore for entity-relation triples. The autonomous memory engine routes each query to the appropriate index and fuses results using reciprocal rank fusion (RRF) when multiple indexes contribute hits.
How does a write flow through the system?
A write request enters through HTTP or gRPC, passes through authentication, policy enforcement, and encryption, then lands in Fjall LSM storage with parallel index updates.
The AI agent memory engine receives the grain payload and first validates it against the active governance policy — checking retention rules, required consent scopes, and content constraints. If the policy check passes, the engine serializes the grain into the .mg binary format (9-byte header + canonical MessagePack), encrypts the payload with a random per-user AES-256-GCM data encryption key (DEK) wrapped by the customer master key (CMK), and writes the encrypted .mg blob to Fjall.
In parallel, the engine updates the applicable indexes: inserting the grain’s text content into Tantivy for full-text search, computing and storing the embedding vector in the HNSW graph for similarity search, and adding any entity-relation triples to the hexastore. A bloom filter over the superseded set provides fast probable-not-superseded checks. Finally, the engine emits a GrainStored audit event and, if hooks are enabled, enqueues a CDC event for webhook delivery. The context database confirms the write only after all durable operations complete.
How does recall query multiple indexes?
Recall scatters the query across applicable indexes (BM25, HNSW, hexastore), gathers ranked results, and applies reciprocal rank fusion (RRF) to produce a unified ranking.
The AI memory engine analyzes the recall request to determine which indexes to query. A text query hits Tantivy BM25. A vector query hits the HNSW graph. A relation query hits the hexastore. Hybrid queries fan out to multiple indexes simultaneously. Each index returns a ranked list of grain IDs with scores. The engine applies RRF fusion to merge these lists into a single ranking that balances contributions from each index.
After fusion, the engine applies post-retrieval filters: governance policy checks (excluding grains with expired retention or revoked consent), diversity reranking (reducing redundant results), and contradiction detection (flagging grains that contradict each other). The entity_latest partition provides fast lookups for the most recent version of entity-type grains, supporting use cases where only the current state matters. The context database returns the final ranked list with content, metadata, and relevance scores.
What capabilities run inside a cell?
Every Areev cloud cell runs the same fully-featured engine: Tantivy BM25 full-text search, HNSW vector search via USearch, Axum REST API, Tonic gRPC, Model Context Protocol, Agent-to-Agent protocol, email/password + OAuth authentication, CDC + webhooks, PDF/DOCX/PPTX/HTML document import, Context Assembly Language, conversational memory, COSE Sign1 Ed25519 signing, and HSM-backed key management.
These capabilities are always available in cloud — there is no profile selection or feature toggling for customers to manage. The control plane provisions cells with the right capacity, region, and compliance configuration based on your subscription tier.