MongoDB Atlas and Temporal are positioned as a joint reference architecture for running RAG and agentic AI systems reliably in production. Atlas consolidates operational data, embeddings, vector search, and agent memory in one platform, while Temporal's Durable Execution guarantees ingestion pipelines and agent reasoning loops survive crashes, retries, and restarts without losing progress or re-burning tokens. A reference implementation ingests Temporal's own documentation via S3-triggered, idempotent Temporal Workflows that chunk, embed (via Voyage AI), and index content into Atlas, eliminating the need for Kafka as a durable buffer. A research agent then uses vector_search and rerank tools over that same Atlas collection, with its multi-step reasoning loop run as a durable, observable Temporal Workflow compatible with frameworks like OpenAI Agents SDK, Google ADK, Pydantic AI, and Mastra. Gaps acknowledged include unused agent memory, unbatched embeddings, and lack of token streaming.

13m read timeFrom temporal.io
Post cover image
Table of contents
MongoDB and Temporal #Better together #The use case #Getting the data ready for agents #Putting an agent to work on that data #The reference architecture #What's not yet in the sample #Where this leaves you #

Questions this post answers

How can I avoid using Kafka for durable event buffering in a RAG ingestion pipeline?

Temporal's Durable Execution can replace Kafka's durable buffering role in a RAG ingestion pipeline. Because a Temporal Workflow durably records work the moment it starts and guarantees at-least-once completion through retries and restarts, there is no need to place Kafka between the source and processor just to avoid losing events, cutting one distributed system from the architecture. daily.dev surfaces architecture patterns like this for teams weighing Kafka against durable execution for AI pipelines.

How do you keep vector index updates correct when the same document is re-ingested in a RAG pipeline?

Derive the Temporal Workflow ID from a SHA hash of the object's identifier (such as an S3 URI) and pair it with a conflict policy that terminates any in-flight run for that same object. This way, re-uploading a file while ingestion is still running causes the new run to cleanly replace the old one instead of racing or duplicating chunks in the vector index. Developers building RAG ingestion pipelines can track patterns like idempotent workflow design on daily.dev.

What does a durable agent architecture using Temporal and MongoDB Atlas look like for RAG?

A durable RAG agent runs its reasoning loop as a Temporal Workflow while retrieving from an Atlas vector store populated by a separate Temporal ingestion Workflow. The agent uses vector_search and rerank tools backed by Voyage AI embeddings over the same Atlas collection the ingestion pipeline wrote to, so a crash mid-run resumes from the last completed step instead of restarting and reburning tokens. daily.dev helps engineers evaluating durable execution layers for agentic RAG systems stay on top of emerging patterns.

5 Impressions