MongoDB has expanded Atlas with new capabilities aimed at transforming the data platform itself into the layer of memory, context, and information retrieval for applications and AI agents. The company introduces automated embeddings with Voyage AI models, an independent API for embeddings and reranking, vector retrieval over streaming data, and the new voyage-code-4 model, specialized in finding relevant code for programming agents.
The keys to MongoDB’s new RAG (Retrieval-Augmented Generation) approach in 20 seconds
- Atlas can automatically generate and update embeddings as documents change.
- MongoDB offers Voyage AI models through an API that can be used even outside of Atlas.
voyage-code-4is specialized in code retrieval for programming agents.- The native reranking feature allows reordering results based on semantic relevance.
- The company aims to avoid architectures with separate operational layers, vector stores, and embedding pipelines.
This approach addresses one of the less flashy but most critical issues in retrieval-augmented generation systems, known as RAG (Retrieval-Augmented Generation). An agent’s performance depends not only on the language model used but also on the quality of the information it retrieves before making a decision.
A large language model (LLM) can be very capable but receive mediocre context.
If a vector search returns the wrong document, an outdated one, or irrelevant snippets, the model will reason based on incorrect information. When an agent has the ability to perform actions, the problem extends beyond receiving a poor response—it can impact subsequent steps and outcomes.
MongoDB aims to bring that retrieval closer to where operational data already resides.
Atlas generates embeddings when data changes
The core feature is Automated Embedding.
Previously, a typical RAG architecture could involve several steps: an application writes data to its database, an independent process detects changes, extracts text, calls an embedding model, stores the vector in another system, and then keeps both copies synchronized.
It worked, but added components and points of failure.
MongoDB now allows configuring a Voyage AI model over a Vector Search index. Atlas automatically generates the embedding for a chosen field when a document is indexed and creates the query vector at search time.
If the document changes, the platform re-generates its vector representation.
This removes the need for a separate process to detect modifications and update an external vector store.
This feature was introduced to Atlas as a public preview in May, and current documentation shows it available for free-tier clusters (M0), Flex, and dedicated clusters (M10 or higher). In dedicated clusters, auto-scaling of storage and compute is required to handle the initial construction of large indexes.
This is especially relevant for agents working on constantly changing data.
A nightly updated vector copy might suffice for relatively static document collections. However, it’s less effective if the agent needs to query orders, incidents, inventory, chats, or logs that have just been modified.
MongoDB aims to prevent outdated context problems
The company uses a simple analogy to explain its strategy: an agent should retrieve information directly reflecting the current state of the business.
This becomes more complicated with multiple independent layers.
An architecture could have MongoDB as the operational core, another product as the vector store, an external service for generating embeddings, and an additional model for reranking. Each component may function correctly, but delays can occur between the original data and the representation the agent consults.
MongoDB seeks to reduce this synchronization challenge by sharing the platform for operations and semantic retrieval.
This doesn’t mean all RAG architectures need to unify. Using specialized products still offers benefits in certain cases, especially when an existing infrastructure is stable or specific features are required from other engines.
MongoDB’s approach is to simplify components when such specialization incurs operational costs without sufficient benefit.
As a reference, the Financial Times uses Automated Embedding with Voyage AI models for semantic search, processing over 100,000 searches daily. They experiment with different models to balance accuracy and cost.
MongoDB also mentions Eve, a legal AI platform, as a user testing their embedding and reranking API to retrieve relevant legal documentation.
These are customer-reported experiences in the announcement, not independent benchmarks.
voyage-code-4: searching code requires a different model
One of the more specific updates is voyage-code-4, designed for code retrieval.
The challenge it addresses is increasingly common with agents like Codex, Claude Code, or tools working over large repositories.
Before modifying an application, the agent needs to find related files, functions, classes, or implementations. A purely textual search might not suffice, and a generalist embedding model may not accurately capture the semantic relations between software pieces.
MongoDB presents voyage-code-4 as a specialized model precisely for this type of retrieval.
This has broader implications than just generating documentation responses.
A programming agent might need to respond to requests like fixing an authentication error by finding:
- the session validation middleware;
- the user model;
- related tests;
- a token renewal function;
- configurations with different names for the same concept.
The quality of that first retrieval step influences everything that follows.
MongoDB claims that its Voyage models rank highly on the Retrieval Embedding Benchmark (RTEB). They previously demonstrated Voyage 4’s superiority on a public test set, based on benchmark results and MongoDB’s published interpretation. However, this does not guarantee it will outperform in all datasets or real-world applications.
Embeddings and reranking are now API-driven and platform-agnostic
Another important aspect of their strategy is:
The new Embedding and Reranking API allows consuming Voyage AI models directly from Atlas, even if data or applications reside elsewhere.
This positions MongoDB as a provider of retrieval models, not just data storage.
Developers can create an API key in Atlas to access Voyage AI services independently. MongoDB uses a token-based pricing model and does not require data to be stored within MongoDB.
This makes sense, especially after MongoDB acquired Voyage AI in 2025.
The acquisition’s value extends beyond improving Atlas Vector Search—models now can be used as standalone services.
Alongside embeddings, the reranking feature is available.
For example, a vector search might retrieve 50 candidates close to the query. The reranker then reorders these using a more precise model.
The first phase prioritizes speed and coverage, while the second maximizes relevance.
MongoDB added native support for this operation via the $rerank aggregation stage in MongoDB Search and Vector Search at the end of June.
This can be a significant advantage for RAG: reducing irrelevant documents sent to the LLM decreases noise and token consumption.
Agent cost management starts before calling the LLM
This relationship between retrieval quality and cost often remains behind the scenes.
Suppose an agent needs to answer a question based on internal documentation.
Imprecise retrieval might require sending 20 documents to the model.
Better search could reduce this to five.
Savings arise not from a cheaper LLM but from providing less, higher-quality context.
The same applies if an agent performs multiple searches per task. If each step adds unnecessary context, costs multiply with each call.
MongoDB has been working on this balance between quality, embedding size, and cost. Voyage 4 uses a shared embedding space, enabling the creation of document vectors with one model and querying that same space with a lighter model later.
It also supports different dimensions via matryoshka learning techniques, which can help reduce storage in certain scenarios.
These are technical options that should be evaluated case by case: reducing dimensions or using smaller models can cut costs, but maintaining sufficient accuracy for the use case remains a priority.
Vector Search now extends to streaming data
The fourth announced feature is the integration of vector retrieval into Atlas Stream Processing.
MongoDB Stream Processing already enables ingesting streams from sources like Kafka or database change streams, transforming data continuously, and writing results to collections, topics, or external destinations.
Adding vector search to this pipeline aims to enable agents to relate real-time events with semantically similar information.
This opens new use cases beyond traditional document-focused RAG.
For instance, an event stream could compare new incidents with past ones, relate telemetry to known scenarios, or enrich real-time messages before passing them to other systems.
MongoDB’s goal is that streaming data should not need to be converted into static collections first to participate in semantic retrieval.
The operational benefits are significant—agents focusing on observability, support, or incident detection need context while events are still occurring, not hours later.
MongoDB positions itself at the core of agent architecture
All these developments are part of a broader strategy that extends beyond just vector search.
At the Build Fest held on August 13 in San Francisco, MongoDB introduced its platform centered around four concepts: memory, state, context, and retrieval for agents.
The company also announced integrations with Claude, Claude Code, ChatGPT, Codex, Grok Build, and Devin, along with a managed MCP server for Atlas.
The commercial goal is clear: MongoDB should not only be where applications store documents but also serve as a layer from which agents can query live state, seek semantic context, and access tools.
This elevates databases within the emerging ecosystem of AI-enabled agents.
Early chatbots mainly worked with prompts and a model. Production agents need to remember, consult, act, and check what has changed since their last run.
As software becomes more autonomous, the importance of what might seem a less obvious factor increases: what information was retrieved before making a decision.
MongoDB bets that this layer will become a natural part of the data platform itself.
Frequently Asked Questions
What is MongoDB Atlas Automated Embedding?
It’s a feature that automatically generates embeddings using Voyage AI models when documents are indexed or queried. It also re-generates vectors when data changes, avoiding the need for a separate pipeline.
What is voyage-code-4?
It’s a Voyage AI embedding model specialized in code retrieval. It’s aimed at agents and applications that need to find relevant fragments within software repositories.
Is MongoDB required to access Voyage AI models?
No. MongoDB provides an independent Embedding and Reranking API via Atlas that can be used from applications built on other storage systems.
What is reranking in a RAG system used for?
It allows reordering an initial set of retrieved documents with a more precise model. The goal is to send less irrelevant information to the LLM and improve the final context quality.
