High-Level Architecture
Trix is a managed memory service. You interact with a REST API (or SDK), and Trix handles storage, embedding generation, enrichment, and search behind the scenes.
1. API Layer
Your application sends requests to the Trix API. Create memories, search them, organize with spaces and clusters. All operations are authenticated via API key.
2. Storage
Memory content is persisted immediately. The raw text, metadata, timestamps, and associations are stored durably before any async processing begins.
3. Embedding Pipeline
After storage, embeddings are generated asynchronously. These vector representations power semantic search — finding memories by meaning, not just keywords.
4. Search Engine
Queries are embedded and matched against stored memory embeddings using semantic similarity, combined with full-text search for keyword precision. Results are ranked and returned.
What Happens When You Store a Memory
When you call POST /v1/memories, Trix processes your memory through several
stages:
- Validation and storage — The content is validated, stored in the database, and assigned an ID. The API returns a response immediately.
- Embedding generation — Asynchronously, the memory content is converted into a vector embedding. This typically completes within seconds.
- Enrichment pipeline — Optional enrichment modules extract additional structure: topics, entities, sentiment, temporal references, and relationships. These become searchable metadata.
- Indexing — The embedding is indexed for fast similarity search. Full-text search indexes are also updated.
Because embedding and enrichment happen asynchronously, a newly stored memory may not appear in search results for a few seconds. For most applications this is imperceptible.
What Happens When You Search
When you call GET /v1/memories?q=..., Trix combines multiple retrieval
strategies:
- Query embedding — Your search query is embedded using the same model that embedded the stored memories.
- Semantic similarity — The query embedding is compared against all memory embeddings in the target space using cosine similarity. This finds memories that are conceptually related, even if they use different words.
- Full-text matching — A parallel full-text search catches exact keyword matches that semantic search might rank lower.
- Result ranking — Results from both strategies are merged and ranked by relevance. The top results are returned with similarity scores.
This hybrid approach means searching for "user's programming language" will find a memory that says "Alex prefers Python" — even though the words don't overlap.
Multi-Tenancy Model
Trix provides isolation through a three-level hierarchy:
- Accounts — Your Trix account. All resources belong to an account, and billing is at the account level.
- Spaces — Isolated containers for memories. Each space has its own set of memories, and searches are scoped to a single space. Use spaces to separate users, tenants, or domains.
- Memories — Individual pieces of information stored within a space. Each memory has content, optional metadata, and auto-generated embeddings.
For a typical multi-user application, you would create one space per end-user. Memories in one space are never visible when searching another space. See the Multi-User Guide for implementation patterns.
OpenAPI Documentation
The Trix API server generates OpenAPI 3.0 documentation at runtime. You can browse the full API specification, including all endpoints, request/response schemas, and authentication requirements, at the API documentation endpoint:
The OpenAPI spec is generated from the actual route definitions by the Fastify Swagger plugin, so it always reflects the current API surface. You can also use the spec to generate client libraries or import into tools like Postman.
Next Steps
- Quick Start — Store and search your first memory in 5 minutes
- Memories — Deep dive into memory operations
- Spaces — Learn about isolation and organization
- Benchmarks — See how Trix performs on standardized memory benchmarks