Embedding Models Explained — And Why Embeddings Alone Are Not Memory
What embedding models do, and why embeddings alone are not AI memory.
Every AI team eventually hits the same wall. You ship a RAG pipeline, wire it up to a vector store, and it works great in the demo. Then it goes into production and starts confidently retrieving the wrong version of a document, mixing up two customers with similar names, or surfacing a fact that was true six months ago but has since been corrected. The embeddings did their job. The system still failed.
This is the gap between semantic search and memory. They are not the same thing, and conflating them is one of the most common architectural mistakes in applied AI right now. Let's unpack why.
What an embedding model actually does
An embedding model takes a piece of text (or an image, or audio) and converts it into a vector, a list of floating point numbers that represents its meaning in a high-dimensional space. Models like OpenAI's text-embedding-3, Cohere's embed models, or open-source options like BGE and E5 are all trained so that semantically similar inputs land close together in that space, and dissimilar inputs land far apart.
This is what makes semantic search possible. Instead of matching keywords, you can ask a system to find text that means the same thing, even if it doesn't share a single word. "Customer churn risk" and "accounts likely to cancel" can sit right next to each other in vector space, even though they share almost no vocabulary.
At query time, the workflow is simple:
1. Embed the incoming query into a vector. 2. Compare it against stored vectors using cosine similarity or a similar distance metric. 3. Return the nearest neighbors, ranked by similarity.
This is a genuinely powerful primitive. It's why vector databases (Pinecone, Weaviate, pgvector, and others) became core infrastructure for RAG almost overnight. But a nearest-neighbor lookup over unstructured text is a retrieval mechanism, not a model of what an organization knows, when it knew it, or what still matters.
Where embeddings run out of road
Vector similarity answers one question well: "what text is semantically close to this query?" It cannot answer the questions that actually matter for organizational memory.
No entity resolution. A vector store has no concept that "Acme Corp," "Acme Corporation," and "the Acme account" are the same customer. Each mention gets embedded independently. Ask a question that requires stitching together everything known about Acme, and you get a scattershot of loosely related chunks, not a unified answer. There is no identity layer underneath the vectors.
No temporal awareness. Embeddings are timeless by construction. A fact stated in a Slack message from January and a contradicting fact from a contract signed in September are equally "similar" to a query about the customer's contract terms. Nothing in the vector itself encodes which one is current, which one superseded the other, or when either became true. Similarity is not recency, and it is definitely not validity.
No notion of what matters. Vector search retrieves by proximity, not by importance. A one-off comment can outrank a decision made by leadership if it happens to use closer phrasing to the query. There is no mechanism for salience, no way to distinguish a settled fact from a passing remark, and no way to prioritize information based on its actual weight in the organization.
Stack enough documents into a vector store and these failures compound. You get context windows padded with near-duplicate, contradictory, or stale chunks, which means more tokens spent, more hallucination risk, and agents that act on outdated information with full confidence.
Memory requires resolution, time, and structure
Real memory, the kind a human colleague has, isn't a bag of similar sentences. It's resolved (you know which "Acme" someone means), it's temporal (you know what's still true), and it's structured around relationships between entities, not just text proximity.
This is why Sentra is built as a resolved, bi-temporal knowledge graph, not a vector store with a nicer UI. Every fact that enters Sentra gets tied to a resolved entity, connected to related entities and events, and stamped with both when it was true in the world and when the system learned it. That second timestamp matters as much as the first: it lets Sentra distinguish between a fact that changed and a fact that was simply corrected, which is exactly the kind of nuance flat embeddings destroy.
The result is a company brainone memory layer that agents and teams query for context, instead of every agent re-deriving its own fragile, embedding-only recall from scratch. Because Sentra resolves entities and reasons over time before anything reaches a model's context window, teams see roughly 70% lower token spend compared to stuffing raw retrieved chunks into prompts, and agents built on Sentra's memory layer score around 88% on Terminal-Bench 2.1, well ahead of what raw vector recall achieves on the same tasks.
Raw embeddings vs. Sentra resolved memory
| Sentra (resolved bi-temporal memory) | Raw embeddings / vector store | |
|---|---|---|
| Entity handling | Entities resolved and deduplicated across all sources | No entity resolution; same entity fragmented across chunks |
| Time | Bi-temporal: tracks when something was true and when it was learned | No temporal model; all vectors treated as equally "now" |
| Contradiction handling | Detects and reconciles conflicting facts automatically | Returns contradictory chunks side by side with no resolution |
| Relevance | Ranked by resolved relationships and salience, not just text similarity | Ranked purely by vector distance |
| Token efficiency | ~70% lower token spend via precise, resolved context | High token overhead from redundant, overlapping chunks |
| Agent performance | ~88% on Terminal-Bench 2.1 | Materially lower on the same benchmark |
| Scope | Org-wide memory layer shared across teams and agents | Typically siloed per app, index, or pipeline |
| Deployment | Self-hosting available, SOC 2 and ISO 27001 compliant | Varies widely; often no compliance guarantees built in |
Embeddings are an ingredient, not the architecture
None of this means embeddings are a bad idea. Vector similarity is still a useful signal inside a broader retrieval strategy, and Sentra uses it too, as one layer among several. The mistake is treating a vector index as if it were memory on its own. Memory requires knowing who is being talked about, when something was true, and whether it still is. That's a graph problem and a temporal reasoning problem, not a nearest-neighbor problem.
If you're building agents that need to reason reliably over your organization's actual state, not just retrieve text that sounds relevant, that distinction is the whole ballgame. Sentra was built around it from day one, as infrastructure teams can self-host, audit, and trust at SOC 2 and ISO 27001 standards.
Embeddings help you find. Sentra helps you remember.