At this point in the industry, we're far past the question of, "can we build an AI demo?" We know we can. In fact, if you're reading this, we're sure you've built plenty.
Today, the question is, "can we run in production reliably and without anyone needing to hand-wring over it?" The shift from the former to the latter is where MongoDB Atlas and Temporal earn their place together.
MongoDB and Temporal#
MongoDB Atlas is the data platform for AI. It holds operational data, embeddings, vector search, and agent memory and it does it all in one place. You don't need to bolt a separate vector store, cache, and search engine onto your app's database.
Voyage AI, MongoDB's embedding and reranking service, works directly over Atlas data. Retrieval quality is what ultimately gates answer quality, so having embeddings live next to the data they describe matters. Teams are drowning in AI infrastructure sprawl right now, and consolidating data, vectors, search, and memory into one operational platform is an essential simplification, not a nice-to-have. Vector search is already table stakes for AI applications.
Now we weave in Temporal. Temporal is the durable platform for AI. Our specialty, "Durable Execution," means application code survives process crashes, retries failed steps automatically, and resumes exactly where it left off following recovery. This applies to data processing, like ingestion pipelines and backfills, and it applies to agents running multi-step reasoning loops. The gap between an AI demo and a production system is reliability. Agentic and RAG systems are long-running and make many fallible external calls to models, tools, databases, and APIs. Temporal is the layer that makes all of that dependable.
Better together#
Here's how the two come together: Atlas owns the data stores and services (the stores themselves, embeddings, vectors, memory), and Temporal owns the reliable motion of that data, both into and out from that data platform. Reliable ingestion pipelines and the reliable behavior of the agents acting on it, these are both long-running systems where Temporal preserves state and delivers durability.
Teams building AI today run into two versions of the same problem. On the ingestion side, without a complex system designed to compensate for a host of failure scenarios, like network or API outages, the data stores serving data to agents can drift out of sync with the sources of truth. Atlas consolidates many data services, but Durable Execution is needed to ensure the data that gets there is consistent and true.
On the agent side, similarly complex machinery is needed to keep agents from needing to start over (and reburn tokens) when a crash happens mid-run. Again, Durable Execution exists to relieve the developer and agent operator of that burden.
This reference architecture pairs the two: one platform holding the data agents retrieve, one durable execution layer making sure ingestion and agents never lose their place.
The use case#
To make this concrete, we built a RAG knowledge base and a research agent over an existing body of content: the Temporal documentation. This shape is a canonical enterprise AI pattern. Take your content, make it retrievable, and put an agent in front of it. A large portion of AI applications are some version of this.
There are two halves, and both MongoDB and Temporal add value to both. On the data ingest side, raw content becomes embeddings that live in the Atlas vector store. On the agent side, a durable agent retrieves from that content to answer questions. The two halves connect directly: ingestion writes the vectors that the agent later reads, from the same Atlas database. You won't have to worry about a second copy or sync lag between the data and what the agent sees.
A variety of data sources trigger data ingestion pipelines, Temporal workflows that are orchestration MongoDB data chunking, embedding and indexing services. And a user engages with an agent that has vector search and reranking tools available, with Temporal driving the agentic loop, tool calling and security controls.
Getting the data ready for agents#
A production ingestion system has a short (but extremely important) list of things it needs to get right.
Servicing downstream agents#
It has to service downstream agents. The entire reason to ingest anything is to give agents and LLMs access to more timely or relevant data than what the model was trained on. Embeddings and vector stores make data queryable by meaning, not just keywords.
Concretely, content gets chunked, embedded, and indexed so an agent can pull back the most relevant passages for any question. An agent is only as good as what it can retrieve, and these are the exact chunks the agent's vector search tool returns later on.
Vectorizing content#
This is the core of RAG: split each document into chunks, convert every chunk into an embedding, a numeric vector that captures its meaning, and store those in a vector index.
At query time, you create an embedding for the question and retrieve the nearest chunks. This grounds the model in your specific and most up to date data, which improves accuracy and reduces hallucination. It also means you update knowledge without retraining a model. RAG is the default pattern for grounding LLMs in proprietary and up-to-date information.
Bulk ingestion and incremental ingestion, together#
An initial backfill loads an entire existing corpus at once, potentially thousands or millions of documents. Ongoing incremental updates handle documents as they're added, changed, or removed over time. Updates matter just as much as the adds do: a changed document has to replace its old vectors rather than pile new ones on top. The idempotent workflow-id design below is what keeps that clean.
Accounting for deltas#
It has to lose no deltas, meaning every add or change eventually has to make it into the index. This is higher stakes than it might sound. A dropped change doesn't throw a visible error. The knowledge base just silently drifts out of sync with the source of truth, and agents start returning stale or wrong answers that nobody flags. To ensure every change is fully processed and indexed, the system needs a durable, at-least-once guarantee, which is exactly what Durable Execution provides.
Performing and scaling#
If a corpus is large enough, initial ingestion of that data into the vector store can take a long time, so the design has to parallelize embedding within a document, allowing workers that process the many chunks, over many documents, to be scaled horizontally. The goal is to get faster by adding compute, not by redesigning the pipeline.
Building with these expectations in mind#
Here's how we built it to meet those bars. Data sources are pluggable: S3, an RDBMS, and others. The pattern is source-agnostic; only the trigger differs per source. Temporal guarantees no change record is lost: the moment the ingestion Workflow starts, the work is durably recorded and will run to completion through failures, retries, and restarts.
Because of that, no Kafka is required. A common way to avoid losing events is to put Kafka between the source and the processor for durable buffering. Here, Temporal's Durable Execution provides that same guarantee, so Kafka isn't needed in the architecture. That's one fewer distributed system to operate and pay for, and a meaningful cut in operational complexity.
In the reference implementation, S3's native ObjectCreated event invokes a thin AWS Lambda the moment a file lands (locally, this is emulated with a MinIO webhook that posts the same event to the trigger service's /ingest-event endpoint).
The Lambda holds a Temporal client and starts an ingest Workflow for the object. As soon as that start call returns, the delta is safe: that return is the "won't be lost" guarantee.
The Workflow ID is derived from a SHA hash of the object's S3 URI, paired with a conflict policy that terminates any in-flight run for that same object. If the same file gets re-uploaded while an ingest is still running, the new run cleanly replaces the old one instead of racing or duplicating it. That's what keeps incremental updates correct.
The Workflow itself has three steps. Fetch, chunk, and stage: download the object, extract and split it into chunks by file type, and stage those chunks in Atlas. Embed: call Voyage to embed each chunk, running in-parallel batches for throughput. Index: upsert the embedded chunks into the searchable Atlas collection and make sure the vector index exists. Splitting the work into discrete steps is deliberate. Each step is independently retryable and resumable, so a failure never forces redoing the whole pipeline, and the parallel embed step is how the performance and scale requirement gets met: add more workers to scale out.
What does durability actually buy you here?#
A network blip means the affected step retries automatically; the pipeline doesn't fail. A dependent service going down, like the embeddings API or the database, means Temporal waits and retries; no data drops while a dependency is unavailable. Infrastructure going down means that if a worker dies mid-embed, another worker picks the Workflow up and resumes from the last completed step, with no lost progress and no human intervention.
There's a maintenance benefit too. Long-running jobs, especially large backfills, make it hard to find a safe window to patch or replace infrastructure. Because Temporal resumes interrupted work automatically, you can drain and restart workers whenever you need to; the work simply continues afterward. Durable Execution completely eliminates the "we can't touch that box while the job runs" problem.
The output of all this is a fresh, queryable vector store in Atlas, which is exactly what the agent consumes next.
Putting an agent to work on that data#
The use case here is a research agent that answers questions over the ingested content. You can build it with any framework and still get durability from a Temporal integration. Agent frameworks are multiplying, and you shouldn't have to abandon yours to get reliability. Frameworks with a Temporal integration run the agent's reasoning loop as a durable Workflow, so a multi-step agent that crashes mid-run (or we have a need to "touch that box" mid-run), resumes instead of starting over. Temporal has integrations for the OpenAI Agents SDK, Strands SDK, Google ADK, Pydantic AI, Spring AI, Mastra, and more.
Agents are long-running and brittle. They make many model and tool calls, and any of those calls can fail. Most agent loops today are ephemeral and in-memory, so a crash loses all progress. Durable Execution is the production piece that's missing, and it doesn't cost you your framework of choice.
Two MongoDB tools cover the RAG retrieval, or read, path. It's worth being precise here, because it's an easy point to get wrong: these tools are not the ingestion activities described above. Ingestion is the write path (chunk, embed, index). The agent uses the read path (search, rerank). Same RAG, opposite direction, different activities for different jobs. vector_search embeds the question with Voyage and searches the active Atlas knowledge collection. rerank reorders the candidate chunks with Voyage reranking to surface the best few.
The connection back to the ingestion side is that the read path runs over exactly the data and embedding space the write path produced: the same Atlas collection, and the same Voyage model used to embed documents at ingest time is used to embed the query at search time. They have to match, since query and document vectors need to live in the same space for vector search to work. Ingestion writes it; the agent reads it. In the reference implementation, this retrieval logic is written once and reused whether it's invoked as a plain query pipeline or handed to the agent as tools. What changes on the agent side is control: instead of a hard-wired search-then-rerank-then-answer chain, the agent decides which tool to call, and how many times. That shift, from a fixed pipeline to a model choosing its own tools, is the whole point of the agent.
The agent's system instructions tell it to decompose multi-part questions and search each sub-topic separately, rerank before answering, prefer the ingested docs over the open web, and answer only from gathered sources with inline citations. That's what produces genuine multi-step research, and grounded, cited answers instead of one shallow lookup.
Because the loop runs as a Temporal Workflow, every step is recorded. The agent pushes human-readable progress, like "searching the docs" or "reranking" or "reasoning," that a Temporal query exposes and the UI polls, so users watch it work in real time at the step level rather than as token streaming. Observability and auditability of agent decisions, being able to see and replay exactly what an agent did, is a growing production requirement for trust, debugging, and compliance. A durable Workflow gives you that for free. An ephemeral agent does not.
The reference architecture#
Let's call this pattern durable RAG and agents on MongoDB and Temporal. We recommend it as the pattern for building retrieval-backed, agentic AI: a reusable blueprint, not a one-off demo. The same shape works for any content regardless of source, as long as you're running a Temporal-integrated framework.
What to adopt: Atlas for operational data, embeddings, vector search, and agent memory, all in one store. Voyage for embeddings and optional reranking. Temporal ingest Workflows triggered directly from source events, with no Kafka required, made idempotent per source object. The agent loop as a Temporal Workflow, using a Temporal-integrated framework for durability.
The same two-word promise, durable over an AI-ready data platform, shows up identically on the ingestion side and the agent side. That repetition is the argument.
What's not yet in the sample#
Candidly, there are a few honest gaps worth naming here. Agent memory isn't used meaningfully yet; the agent doesn't currently read or write long-term memory in its loop. That doesn't weaken the positioning, since Atlas is an ideal store for agent memory: it lives in the same database as retrieval, so memory, vectors, and operational data share one platform with no copies. Memory is widely seen as the next frontier for useful agents.
Ingestion isn't batched. Embeddings are generated per chunk, in parallel, rather than through batched embedding API calls; batching would cut API calls and cost further. Tokens aren't streamed to the UI either. Progress is step-level, through query polling, rather than token-by-token, and token streaming is a straightforward next enhancement.
None of that changes the core value, though: the foundation holds, and these are refinements on top of it.
Where this leaves you#
Atlas gives AI an operational, vector-native data platform and Temporal makes both the ingestion pipeline and the agent durable, resumable, and observable. Together, they're a production-grade foundation for RAG and agents: the reliability layer that turns AI demos into systems you can actually run.
If you want to see it in action, you can:
Explore the reference repo.
Reach out to us in our community hubs, Temporal and MongoDB. Meet us at MongoDB.local NYC next month.