Skip to main content
Store agent knowledge in MongoDB Atlas with per-tenant user_id / agent_id / run_id scope on every read and write.

Quick Start

1

Agent with MongoDB knowledge

2

Direct Knowledge API


How It Works

The adapter persists user_id / agent_id / run_id on each document and applies any provided scope as a pre-filter on search. On Atlas $vectorSearch, the scope becomes the stage-level filter. Without Atlas vector search, the adapter falls back to MongoDB text search and merges the scope into the find() query. None values are dropped — omit an identifier to broaden the search on that dimension.

Configuration Options

Config keys read from MongoDBKnowledgeAdapter.__init__ under vector_store.config. Embeddings are configured via the top-level embedder key:

Common Patterns

Isolate a single customer’s session by combining all three scopes:
Broaden across all sessions for one customer by omitting run_id:

Best Practices

use_vector_search=True needs a MongoDB Atlas cluster with a vector index on the embedding path (similarity cosine). Without Atlas, the adapter transparently falls back to text search.
Provide user_id (and optionally agent_id / run_id) on both add() and search() to keep tenants isolated. Omitted scopes broaden the search on that dimension.
Passing knowledge={...} and user_id=... on the Agent handles scoping and context injection automatically. Use the direct Knowledge class only for custom indexing or search control.
Atlas connection strings start with mongodb+srv:// or contain mongodb.net — the adapter detects these to enable vector search.
As of PR #3810, the MongoDB adapter honors user_id / agent_id / run_id on both add() and search(). On earlier releases these kwargs were silently ignored, producing cross-tenant results. Upgrade to a release built after commit 6b6707c1.

Knowledge Backends

Compare Chroma, mem0, and MongoDB storage backends

MongoDB Memory

Use MongoDB as the agent memory store