TL;DR

CrewAI can already query MongoDB Atlas through an agent tool, but it cannot use Atlas as the built-in store behind its own Knowledge feature (which today defaults to ChromaDB, with Qdrant as the only alternative). Add a crewai[mongodb] install extra plus a MongoDB BaseClient + MongoDBConfig so a developer can point CrewAI's Knowledge at Atlas with a one-line global config, choosing automatic or manual embeddings (Voyage AI by default), with no forking required.

Context

What CrewAI is. An open-source Python framework for building multi-agent applications. You give agents "Knowledge" – documents they can retrieve from at runtime – and CrewAI handles chunking, embedding, storing, and retrieving that content behind the scenes.

Concepts, in plain language:

• Knowledge (RAG): Retrieval-Augmented Generation. Before an agent answers, the framework fetches the most relevant chunks of your documents and feeds them to the model. The store that holds those chunks and finds the relevant ones is the Knowledge backend.
• Embedding: turning text into a numeric vector so similar meanings sit near each other. An embedding function does this. It can run client-side (CrewAI computes the vector, then stores it) or server-side (the database computes it).
• Vector search: finding the stored chunks whose vectors are closest to a query's vector. On Atlas this is the $vectorSearch step, executed server-side in the database.
• BaseClient: the internal interface CrewAI's Knowledge system calls to create collections, add documents, and search. Each backend (ChromaDB, Qdrant) provides its own implementation. MongoDB needs one too.
• Install extra: an optional dependency group (e.g. crewai[qdrant]) that pulls in a backend's driver only when you want it. MongoDB should follow the same pattern via crewai[mongodb].

The gap. CrewAI ships an agent tool for querying Atlas, but its own Knowledge feature can't persist to Atlas – a team standardized on MongoDB must run a second vector store (ChromaDB/Qdrant) just for agent knowledge. There is no native Atlas Knowledge backend, and no crewai[mongodb] install path.

Desired User Experience

Before – Atlas is not an option for Knowledge; the default is ChromaDB:

from crewai import Agent
from crewai.knowledge.source.string_knowledge_source import StringKnowledgeSource

# No way to select MongoDB Atlas as the Knowledge store.
# Knowledge silently persists to a local ChromaDB directory.
source = StringKnowledgeSource(content="Our refund window is 30 days.")
agent = Agent(role="Support", goal="Answer policy questions", knowledge_sources=[source])

After (A) – complete end-to-end: install, configure, query (automatic embeddings, the default experience):

pip install "crewai[mongodb]"     # bundles pymongo + the default Voyage embedder
export VOYAGEAI_API_KEY="..."        # client-side embedding key

from crewai.rag.config.utils import set_rag_config
from crewai.rag.mongodb.config import MongoDBConfig
from crewai.knowledge.source.string_knowledge_source import StringKnowledgeSource
from crewai import Agent, Task, Crew

# 1. Point CrewAI's Knowledge at Atlas globally -- zero-config embeddings.
#    The MongoDB provider defaults to Voyage AI's default model (uses VOYAGEAI_API_KEY).
set_rag_config(MongoDBConfig(connection_string="mongodb+srv://..."))

# 2. Add Knowledge. CrewAI chunks it, embeds each chunk client-side with
#    `voyage-4`, and stores the chunks + vectors in Atlas.
source = StringKnowledgeSource(content="Our refund window is 30 days from delivery.")
agent = Agent(role="Support", goal="Answer policy questions", knowledge_sources=[source])

# 3. Query. At runtime CrewAI embeds the question and retrieves the closest
#    chunks server-side via $vectorSearch, then feeds them to the model.
task = Task(description="What is our refund window?", expected_output="A short answer.", agent=agent)
print(Crew(agents=[agent], tasks=[task]).kickoff())

After (B) – same setup, manual embeddings with an explicit Voyage model override:

from crewai.rag.embeddings.providers.voyageai.voyageai_provider import VoyageAIProvider

# Only the config line changes vs. (A): override the default model.
set_rag_config(MongoDBConfig(
    connection_string="mongodb+srv://...",
    embedding_function=VoyageAIProvider(model="voyage-code-4"),
))

After (C) – same setup, a different embedding provider (OpenAI):

from crewai.rag.embeddings.providers.openai.openai_provider import OpenAIProvider

# Any existing CrewAI embedding provider works with the MongoDB backend.
set_rag_config(MongoDBConfig(
    connection_string="mongodb+srv://...",
    embedding_function=OpenAIProvider(model="text-embedding-3-small"),
))

Task

Goals:

• Let a developer pip install "crewai[mongodb]" and store/retrieve CrewAI Knowledge in MongoDB Atlas with a one-line config, no forking.
• Make Voyage AI (voyage-4) the zero-config embedding default for the MongoDB backend, while any existing provider can be swapped in.
• Ensure the integration identifies itself to MongoDB so it's attributable in server telemetry.

Where:

• Install extras to add mongodb to: pyproject.toml
• Backend interface to implement: base_client.py
• Provider registry to extend: factory.py

Acceptance Criteria

• [ ] A MongoDB backend passes the equivalent of the existing backend client test suite (the same behavioral coverage ChromaDB/Qdrant clients satisfy).
• [ ] The end-to-end example (A) works as written – pip install "crewai[mongodb]" pulls in the driver + default embedder, and the same config stores Knowledge in Atlas and answers the query via server-side $vectorSearch using voyage-4 by default. (This changes the framework's usual OpenAI default specifically for the MongoDB provider; see prerequisite in Additional Context.)
• [ ] The embedding variations (B) and (C) work – a developer can override the Voyage model or swap in any other existing CrewAI embedding provider, changing only the config line.
• [ ] The backend identifies CrewAI to MongoDB via client metadata on every connection (the driver-info handshake, identified as 'CrewAI-vector_store').
• [ ] A follow-up documentation ticket is created to add MongoDB to the Knowledge "supported providers" docs, covering examples (A)-(C).