MongoDB.local London 2025: AI, RAG, and the Future of Data

I made it to MongoDB.local London on May 7th, and I am glad I did. The event was held in a stunning venue in the heart of the city and it was packed from the moment the doors opened. Hundreds of engineers, architects, and product people all in one place, all talking about the same thing: what AI actually looks like in production.

This is my honest report from the day.

MongoDB.local London 2025: the energy in the room

Before I get into individual sessions, I want to say something about the atmosphere. There is a version of this kind of conference that feels like a product catalogue being read at you. This was not that.

The conversations between sessions were as good as the sessions themselves. People were working through real problems, not theoretical ones. Whether it was an engineer from a UK fintech figuring out how to structure their memory layer for an agent, or a staff engineer from an enterprise thinking about RAG retrieval accuracy, the problems in the room were concrete.

That matters. It tells you the industry has moved past "should we do AI?" and into "how do we actually build this well?"

Session: From Prompts to Persistence

One of the highlights was the session on agent memory and context engineering, delivered by Rahul Krishnan R A from Barclays and Steffen Hausmann from LangChain.

The core argument was simple but important: when you move from a stateless prompt-response model to an autonomous agent, memory stops being an implementation detail and becomes a first-class design concern. You have to decide what to store, where to store it, and how to retrieve it at the right moment.

The session broke memory into categories: short-term context, long-term episodic memory, and semantic memory (the agent's understanding of concepts and relationships). Each has different retrieval patterns and different storage requirements. MongoDB fits into this picture naturally as the persistence layer, because a document store can hold structured and unstructured memory alongside each other in a way that a relational schema makes awkward.

What stuck with me was the point about memory lifecycle. Most teams think about writing to memory. Fewer think about pruning it. An agent that accumulates everything eventually suffers from retrieval noise, and that noise degrades output quality in ways that are hard to debug. Intentional forgetting is part of good memory design. I have written separately about how agent memory architecture works in practice, if you want to go deeper on the design decisions.

Workshop: Designing Memory Systems for AI Agents

Afi Gbadago from MongoDB ran a hands-on workshop on memory architecture that complemented the earlier session well. This one required a laptop, and the room filled up fast.

The practical piece was building a simple agent with a MongoDB-backed memory store and experimenting with how different retrieval strategies changed the agent's behaviour. We looked at combining vector similarity with recency signals and metadata filters, rather than relying on semantic search alone.

The insight that landed hardest: vector search retrieves what is conceptually similar, but that is not always what is most relevant. A memory from three weeks ago might score well on similarity but be stale. A memory from yesterday might be less similar but far more useful. Combining signals is how you close that gap. The same principle applies to RAG chunking strategy, where the shape of your chunks determines what retrieval can and cannot surface.

Session: Advancing RAG with Temporal Knowledge Graphs

James Melvin from LexisNexis Risk Solutions presented work that felt genuinely ahead of where most teams are. The premise: standard RAG gives you semantically similar documents. But for legal and financial data, you often need to know not just what is similar, but what was true at a specific point in time.

Their solution is a Temporal Knowledge Graph built on top of MongoDB, powered by a Rust engine for high-performance graph traversal. The key insight is treating relationships as time-indexed edges, not static links. Two entities might be connected in 2022 and disconnected by 2024. A standard knowledge graph flattens that history. A temporal one preserves it.

The result is that their RAG system can answer questions like "what was the regulatory relationship between these two firms in Q3 2023?" and return grounded, accurate context, not just semantically plausible text.

This is where I think enterprise RAG is heading. The question will shift from "can we retrieve relevant documents?" to "can we retrieve accurate, time-aware facts?"

Session: Auto Embedding and the Next Era of Vector Search

Parth Shaw and Prakul Agarwal from MongoDB announced Auto Embedding in Atlas Vector Search, and the demo was impressive. The feature lets you run semantic search on text with plain natural language queries, powered by Voyage-4 embedding models, without managing the embedding pipeline yourself.

The part that matters most for production teams: Atlas handles keeping data and embeddings in sync, manages model selection, batches large datasets intelligently, and handles rate limits during indexing. These are the operational headaches that consume disproportionate engineering time in most vector search setups.

They also walked through how to balance cost and retrieval accuracy using Matryoshka Representation Learning dimensions and quantization options. This is exactly the kind of knob that teams need when they are trying to hit both a latency target and a cost ceiling.

The general sessions

CJ Desai's morning keynote set the tone well. The framing was direct: your AI ambitions are only as strong as what you build them on. It is not a flashy message, but it is the right one for an audience of engineers who have watched hype cycles come and go.

The afternoon conversation between CJ and Harry Stebbings from 20VC was unscripted and more interesting for it. Harry's perspective from the investor side, watching which AI infrastructure bets are paying off, added a dimension that most technical conferences miss.

What I took away

Three things stayed with me after the day:

Memory is the hard part of agents. Everyone can wire up an LLM. The teams that will build durable, useful agents are the ones who design memory architecture with the same rigour they bring to database schema design. This is a systems design problem, not a prompt engineering problem.

Temporal awareness is the gap in most RAG systems. If your retrieval layer does not understand when something was true, you are building on shaky ground. This is especially true for any domain where the world changes: finance, law, compliance, healthcare.

Operational simplicity is now a competitive feature. Auto Embedding and similar abstractions matter not because they are clever, but because they let small teams ship semantic search without dedicating an engineer to infrastructure. That changes the economics of building AI features.

A genuine thank you

To the MongoDB team who organised the day: it was well run, thoughtfully curated, and the venue was genuinely excellent. Thank you for bringing together a community of people who are building seriously.

To the speakers, including Rahul Krishnan R A, Steffen Hausmann, Afi Gbadago, James Melvin, Parth Shaw, and Prakul Agarwal: thank you for sharing work that was real, not polished for consumption. The practical details matter more than the high-level narrative, and you delivered both.

If you want to keep thinking through these topics, I write about system design and architecture decisions every week. Subscribe to Monday BY Gazar on Substack and follow along.

I also cover sessions like these in more depth on Gazar Breakpoint on YouTube, where I break down architectural decisions for senior engineers moving into staff and principal roles.

If you are working through agent architecture, RAG design, or memory systems and want a second perspective, book a free intro call and we can talk through your specific situation.