SenseLab vs Vector Databases

If you are considering building a memory layer on top of a vector database, this page is about what that project turns into.

The Short Version

A vector database answers one question: what is most similar to this query? It returns the nearest embeddings and stops there. SenseLab answers the questions that actually decide whether an agent should act: who learned this, how confident should we be, what happened the last time someone acted on it, who else on the team knows it, and can I see the reasoning six months later. Those are not two flavours of the same product. A similarity index has no notion of an author, a version, an outcome or a teammate, and no amount of metadata columns adds one. Everything on this page that a vector database does not do is something you would be signing up to build and then maintain.

Side-by-Side Comparison

Dimension	Vector Database	SenseLab
Primary operation	Similarity search over embeddings	Read/write versioned knowledge with provenance
Collaboration model	Shared index — last write wins	Git model — branch, diff, PR, merge, rollback, access control
Data model	Vectors + metadata	Structured entries with entity/key scoping, confidence, memory type, provenance
Versioning	Overwrite or append	Copy-on-Write — every write creates a new version, full history preserved
Who wrote it?	Not tracked	Provenance: agent ID, session ID, timestamp, pattern refs
Trust signal	None	Confidence score that evolves based on real-world outcomes
Feedback loop	None	Outcome back-propagation — incidents boost confidence, clean deploys decay it
Query style	”Find similar to X"	"Read key Y”, “Search by entity/agent/confidence”, “What happened over time?”
Temporal queries	Snapshot at query time	Full version history with time-range filtering
Explainability	None	Causal chain: which entries + external contexts informed a decision
Multi-agent	Shared index	Per-agent provenance, auto-causal linking, cross-agent reads logged on both sides
Disagreement	Last write wins, silently	Both versions survive with their authors; disagreement is visible
Teams of people	None — an index has no members	Rooms: many people’s agents on one topic, with collaborator and viewer roles
Onboarding a new agent	It must know what to query for	A joining briefing hands it what the team already knows
Document retrieval	The core job	Built in — documents are chunked, embedded and searched inside SenseLab
Improving the model itself	Out of scope	Models fine-tuned on your decision traces, trained and hosted for you
Update pattern	Re-embed and upsert	CoW write with automatic version increment

What Vector Databases Don’t Do

Vector databases are stateless retrieval indexes. They don’t track:

Who wrote the data — No provenance. You don’t know which agent or process created an entry.
How trust evolves — No confidence scoring. A vector’s relevance score is similarity to a query, not a measure of how trustworthy the information is.
What happened when you used it — No outcome tracking. If an agent retrieves a vector and acts on it, and that action causes an incident, the vector database has no way to learn from that.
How data changed over time — Vectors are overwritten or appended. You can’t ask “what did this entry say last week?”
Why a decision was made — No causal chain linking retrieved data to actions and outcomes.
How to collaborate on changes — No branching, no review process, no way for one agent to propose a change and another to approve it. It’s like coding without Git.

What SenseLab Does Differently

SenseLab is designed for agent memory — the layer between retrieval and action:

Knowledge has identity

Every entry has an entity_path and key that give it a stable address. Agents read and write to specific keys, not anonymous vectors.

mem.write("checkout-service", "retry-pattern", {"max_retries": 3})
entry = mem.read("checkout-service", "retry-pattern")

Knowledge has provenance

Every entry records who wrote it, when, and in which session:

print(entry.provenance.agent_id)    # "review-agent"
print(entry.provenance.written_at)  # 2026-03-15T14:30:00Z

Knowledge evolves with outcomes

When a deploy succeeds or an incident occurs, confidence scores on related entries adjust automatically:

mem.commit_outcome("INC-1042", OutcomeType.CRITICAL_FAILURE)
# All entries this agent read get their confidence boosted

Knowledge has full history

Every write creates a new version. You can replay the state at any point in time:

versions = mem.history("checkout-service", "retry-pattern", since=last_week)

Decisions are explainable

The causal chain shows exactly what informed a decision — both SenseLab entries and external tool context:

chain = mem.explain("DEP-500")
# → causal_entries: entries the agent read
# → external_contexts: tool/API inputs the agent consulted

What it costs to build this yourself

Teams rarely set out to build a memory platform. They add a versions table to a vector store, and eighteen months later they own one. Here is what sits between a similarity index and something an agent can safely act on:

You would have to build	What it turns into
Versioning	Copy-on-Write storage, a supersede rule instead of an overwrite, and history queries that stay fast as versions accumulate. Then diff, and rollback, because a history you cannot act on is a log.
Provenance	An identity on every version, not every row. Then the migration when you realise reads need attributing too, and the schema change when one agent reads another’s work.
An outcome loop	Recording which entries were read on the way to a decision, propagating success and failure back to each one, and a decay model that distinguishes a fact from a belief and slows down for anything an outcome has validated.
Decision traces	Capturing the causal chain as it happens rather than reconstructing it from logs, then storing it so it is still answerable in a year, with integrity checks if anyone will rely on it.
Team access	Membership, roles, and a write path that refuses a viewer below the interface rather than in the UI. Then the audit trail, because the reason you needed roles is the reason you will be asked for one.
Onboarding	Deciding what a new agent should be handed on day one, and keeping that current as the team’s knowledge moves.
Conflict handling	Deciding what happens when two agents write the same key — and resisting the easy answer, last-write-wins, which is how the knowledge silently gets worse.

Each row is a system, not a sprint. Each one grows edge cases the first production incident finds for you. And none of it is your product — it is the substrate your product needs in order to stop repeating itself. SenseLab is that substrate, already built, already carrying other teams’ traffic.

You probably do not need a second database

The usual reason to keep a vector store alongside a memory layer is search. SenseLab does that itself:

Hybrid search — full-text, semantic similarity through pluggable embedders, recency and confidence, combined into one ranked result rather than a similarity score you then have to re-rank by hand.
Documents, chunked and embedded in place — upload a document to a room and SenseLab splits it on sentence boundaries with overlap, sizes each chunk to the embedding model’s real token budget, and makes it searchable alongside everything the team has learned. No second pipeline, no second copy, no sync job between them.
A knowledge graph you did not have to build — entity relationships and causal links materialize from normal reads and writes, surfacing connections similarity search cannot.

If you already run a vector database for product search or retrieval over millions of documents, keep it. That is a different job from remembering what your agents decided and whether it worked, and nothing here asks you to migrate it. What is not worth doing is standing up a second system to hold your agents’ memory, and then building the seven rows above on top of it.

The Compounding Loop

The fundamental difference becomes clear over time. A vector database stores static embeddings that you retrieve. SenseLab builds a compounding knowledge asset that gets more valuable the longer you use it:

Week 1:   Agents write what they learn      → memory with an author
Week 4:   Outcomes validate it              → confidence reflects reality
Week 8:   A room shares it across the team  → nobody solves it twice
Week 12:  Decision traces accumulate        → precedent, not folklore
Week 24:  Patterns surface                  → recurring failures found early
Week 52:  Enough traces to train on         → a model tuned on your own work

Week 52 is the part no retrieval layer reaches. By then the record of what your agents decided is large enough to fine-tune on, and we run that for you: we spin up the training job, score the candidate against a holdout of your own decisions, and host the result for serving. Pro also adds cross-system context over webhooks, decision traces that are still answerable months later, and pattern detection that finds recurring failures before they become incidents. A vector database is the same on week 52 as it was on week 1. SenseLab is a memory system that compounds, and the compounding is the product.

Summary

	Vector Database	SenseLab
Think of it as	A search index for embeddings	GitHub for agent memory
Best for	Finding relevant data	Knowing what your agents learned, and whether it held up
Collaboration	None — shared index, last write wins	Branch, diff, PR, review, merge, rollback, access control
Teams	None	Rooms: several people’s agents on one topic, with roles and an activity trail
Data lifecycle	Write once, query many	Write, version, track outcomes, decay, explain
Multi-agent	Shared index	Provenance, causal chains, and disagreement that stays visible
Document search	The core job	Included — chunked, embedded and searchable in place
Cross-system context	Manual ingestion	Pro: webhook ingestion, with PagerDuty shipping as a connector
Pattern intelligence	None	Pro: recurring failures, stale clusters, confidence drift
Improves the model	No	Pro: fine-tuned on your traces, trained and hosted for you
Enterprise readiness	Auth varies by vendor	Pro: RLS isolation, RBAC, scoped API keys, audit logging
Build effort to match it	—	Seven systems, per the table above

Product

Getting Started

Guides

Self-Hosting

Core Concepts

Pro Features

SenseLab vs Vector Databases

The Short Version

Side-by-Side Comparison

What Vector Databases Don’t Do

What SenseLab Does Differently

Knowledge has identity

Knowledge has provenance

Knowledge evolves with outcomes

Knowledge has full history

Decisions are explainable

What it costs to build this yourself

You probably do not need a second database

The Compounding Loop

Summary

​The Short Version

​Side-by-Side Comparison

​What Vector Databases Don’t Do

​What SenseLab Does Differently

​Knowledge has identity

​Knowledge has provenance

​Knowledge evolves with outcomes

​Knowledge has full history

​Decisions are explainable

​What it costs to build this yourself

​You probably do not need a second database

​The Compounding Loop

​Summary

The Short Version

Side-by-Side Comparison

What Vector Databases Don’t Do

What SenseLab Does Differently

Knowledge has identity

Knowledge has provenance

Knowledge evolves with outcomes

Knowledge has full history

Decisions are explainable

What it costs to build this yourself

You probably do not need a second database

The Compounding Loop

Summary