Architecture
What is the Areev architecture?
Areev unifies an HTTP/gRPC server, a durable encrypted storage layer, full-text and vector search, a knowledge graph, and envelope encryption behind a single AI memory engine — presented as one cohesive context database.
The server layer serves ~200 REST endpoints under /api/ alongside a gRPC interface. 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 durably persists grains under content-addressed, encrypted storage. On top of it, three retrieval subsystems provide different query modalities: BM25 full-text search, vector similarity search, and a knowledge graph over 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 durable 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 AES-256-GCM using a per-memory data encryption key (DEK) wrapped by the platform’s managed key service, and writes the encrypted .mg blob to durable storage. The wrapped DEK is stored once per memory; per-user keys are HKDF-derived at runtime and never stored.
In parallel, the engine updates the applicable indexes: inserting the grain’s text content into the full-text index for BM25 search, computing and storing the embedding vector in the vector index for similarity search, and adding any entity-relation triples to the graph index. A fast in-memory check identifies superseded grains without a full lookup. 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 (full-text, vector, graph), 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 the BM25 full-text index. A vector query hits the vector index. A relation query hits the graph index. 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 index 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: BM25 full-text search, HNSW vector similarity search, REST API, 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 a managed key service.
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.