Dashboard
Applications
Subjects
Chunks
Sources
Source Extraction
Subjects
Embeding Strategies
Ask Grounded Answer
Source Inspector
API Credentials
Connectors

Inspiration

We're three engineers who wanted to build something real in AI and grow it into a startup. We kept building AI apps for hackathons and for ourselves, and every time we learned the same thing: an LLM is very good at reasoning when you give it the right data.

Giving it the right data was the hard part:

Context doesn't last. We'd give a model the right context one day, and two days later we couldn't explain it the same way again. The knowledge was in our heads and in a chat that was gone.
Relationships get lost. LLMs are great at finding connections between things, but we had no way to store those connections and feed them back. Every session started from zero.

So we stopped thinking of memory as a prompt problem and started treating it as infrastructure. If the LLM is the brain's central executive, the part that reasons and decides, then Memora is its memory. Memora stores good-quality knowledge durably, links it into relationships and evidence, and returns exactly the right part of it whenever the AI needs it.

What it does

Memora is a persistent memory engine that any AI application can plug into.

Ingest anything: upload files or chat sessions. A page-by-page document processor and an Extraction Agent turn raw documents into structured, versioned extractions.
Build relationships: an NVIDIA model reads each chunk and pulls out entities and relationships from a fixed ontology. Duplicates are merged into a knowledge graph, and every fact links back to its source and chunk.
Retrieve with evidence: chunks are embedded into pgvector and searched through a four-stage pipeline:

vector search (top 50) → MMR diversification (top 10) → cross-encoder rerank (top 5) → grounded answer with per-chunk evidence

Multi-tenant from the start: everything sits on one ownership chain, Tenant → Application → Actor → Subject → Source, so each application only ever sees its own memory.

The MMR step keeps the context the LLM sees relevant and non-redundant:

$$ \text{MMR} = \arg\max_{d_i \in R \setminus S} \Big[ \lambda \cdot \text{sim}(d_i, q) - (1-\lambda) \cdot \max_{d_j \in S} \text{sim}(d_i, d_j) \Big] $$

Embedding strategies are versioned and swappable (model + templates + normalization + metric). That lets several strategies run side by side for A/B evaluation, and we have a benchmark judge to score them.

Challenges we ran into

Ownership without leaks. A source must never be readable just because someone knows its id. We enforce ownership in the service layer, not in the routes. Ownership columns are always derived and never taken from the client. Requests across tenants get 404, not 403, so we don't even confirm that an id exists.
Turning relationships into memory. Getting good entities and relationships out of messy documents with a fixed ontology, and merging duplicates without losing provenance, took many iterations.

Accomplishments that we're proud of

A full pipeline from raw document to retrieval, where every answer points back to the chunk and source it came from
Graph and vector retrieval working together in one memory engine
Every extraction is a new version, with its model calls and cost recorded

What we learned

The quality of an AI application depends on the quality of its memory. Good retrieval isn't one search. It's diversification, reranking and evidence on top. And infrastructure you want other apps to trust has to get multi-tenancy and provenance right from the start.