Write, Change, Recall, Forget: MongoDB's Pete Johnson on How Retrieval Drives Agent Performance

1. Sponsor: Mercury

Pete Johnson, field CTO of AI at MongoDB, welcome to The Cognitive Revolution.

Thanks so much for having me, Nathan. I appreciate it.

I’m excited for this conversation. I’ve been a database guy in the past, and now we’re all kind of everything guys these days, with our agents greasing the wheels for us. I think one of the big themes we’re going to get into is that the quality of data is still critically important to making things work. I’m excited to learn everything I can from you over the course of the next hour or so.

Maybe just for quick starters: I remember first encountering MongoDB about 15 years ago, when a young Guillermo Rauch who’s now the CEO of Vercel was showing it off in the context of what, at that time, seemed like crazy-futuristic Node.js applications. It was like, “Wow, you can make JavaScript do these kinds of things—and wait, there’s a database that works in this different way, where I’m not constrained by the schema that I already defined?” This was mind-blowing stuff.

I’m not sure we have a lot of technical people in the audience. AI engineer is probably our number-one profile, but I’m not sure everybody knows the broad lay of the land when it comes to database technology. I thought maybe it would be helpful to first contextualize SQL versus NoSQL and schema versus schemaless. Give us the high-level view so we know where MongoDB sits in this obviously bigger database space.

Sure. I like to think of this in terms of the history and the different kinds of problems we’ve had to try to solve with software over the last 60 years or so. Where it really starts for me is June of 1970, when E. F. Codd, an IBM researcher, wrote the original white paper that gave birth to SQL. That was June of 1970. I happen to have been born in February of 1970, so I’m as old as SQL, Nathan.

If you think about the kinds of applications we were building at the time as an industry, and the kinds of hardware we had at our disposal, the applications were very departmental in nature. Not every company had a computer, and those that did often had the people using it on the same floor or certainly in the same building. They were working 9-to-5 hours, and it was okay to have downtime on the weekend.

2. Global AI adoption

If you think about the big 3 pieces of hardware at the time—memory, compute, and storage—storage was by far the most expensive of those 3 things in 1970. So, if you think about how you might organize data, keeping in mind that the scarce resource was storage, you would of course do it in what’s now known as normalization. You may have learned things in university or coding school like first and third normal form, all about trying to lay out data on disk in the most efficient way so that you aren’t storing any piece of data more than once.

The simplest example I can give might be that my wife and I share an address, and a retailer might want to know what our address is. There are 2 people at that address. You might have the list of people in 1 table, the addresses in another table, and a third table that links the people to the address, so that you’re only storing that address 1 time. That’s the most efficient way to do it with some kind of normalization.

Fast-forward to 2007, when the first commit was made to MongoDB in October of that year. The world was a very different place in 2007. It had the internet, the cloud, and mobile devices. The iPhone came out in the United States for the first time that year, so it was a very different world.

The scarce resource in that world, because we had 47 years of Moore’s law between those 2 dates, became time. The kinds of applications we would write in the cloud or for mobile devices could not have downtime on the weekends. It was no longer about people confined to the same building or 9-to-5 use cases. It was a very different world that required a very different kind of database, and that’s what gave rise to NoSQL.

Our flavor of NoSQL, as I said, had its first commit in October of 2007 and uses JSON at its core. You mentioned the stuff with JavaScript. That’s why it was so popular 15 years ago: what you get back from your API call is JSON. We’re storing it in transit as JSON, and we’re storing it on disk in a binary form of JSON that we call BSON. That’s part of why we’re so fast: we’re keeping that format the whole time.

When you serialize it off a disk, when it goes through our servers, and when it ends up in your client, it’s essentially staying in the same format that whole time. If you think about the kinds of applications we’ve been building since 2007, disk space is no longer the scarce resource.

If you take that address example and denormalize the data just a little bit—if instead of storing it across 3 tables, you have a JSON structure with my name and my address, and then a second one with my wife’s name and the same address—you’re duplicating the address. But what do you get in return? You get 1 disk read. That’s why it’s faster. Instead of having to do 3 disk reads to get that same data, you can now do it in 1 disk read.

Does that mean that every problem is solved by a NoSQL database or by MongoDB in particular? No. But it also doesn’t mean that every problem has to be solved with SQL.

3. Enterprise database choices (Part 1)

That’s how it sort of evolved. SQL was invented at a time when the problems were slightly different, and a lot of those problems still exist. SQL is certainly a valid solution to lots of different problems that we still have. But when you need speed, when you need scale, and increasingly when you need better retrieval quality, that’s really where MongoDB shines.

4. Sponsors: Deepgram Flux TTS | Claude

That reminds me of the old saying that the problem has faded, but the solution persists. You see that in a lot of parts of life these days. Tell me a little bit more. You were just getting to it, but MongoDB is a pretty big company—$30 billion market cap—and has obviously made serious inroads into some of the biggest companies in the world as customers. Give me the next level of detail in terms of what the big decision factors are that would push an enterprise to go one way or the other with its database decision.

Before the AI moment—and then we’ll get into that in depth—do enterprises typically make that decision on an application-by-application basis these days, or do big companies feel that they need to have a single, consistent database technology for everything they’re doing?

It’s a mix. Like you just said, we’re in 75% of the Fortune 500, but if you look at the overall market—you mentioned our market cap—we’re about $2.5 billion in revenue. That was our revenue number for fiscal 2026. We’re currently in the middle of fiscal 2027, and that’s about 2–3% of the $100–$110 billion database market.

Where most enterprises choose us is based on those first 2 things that I mentioned: when you need it fast or when you need it at higher scale. You’re not storing that data across multiple places on disk. That’s how you get the speed, and that’s how you can get better scale.

If you’re going to retrieve JSON, every modern programming language can serialize JSON into some object format so that you can use it immediately in your business logic. That’s the other aspect of time. It’s not just runtime for the transaction; it’s also the developer time of figuring out what to do with the data I get back from my API call and then making some kind of useful business decision out of it.

What we see is the right solution for the right problem. Increasingly, what AI has done is open up the number of problems where we’re a better fit than a traditional SQL approach, especially at higher scale.

That’s why I mentioned the 3 things: speed, scale, and retrieval quality. Retrieval quality has really become an important factor, and it continues to become especially important later here in 2026 as people start to strategize around token maxing and evolve different kinds of agentic architectures in ways that we didn’t see in the first half of 2026.

Retrieval quality has become more important for AI, but it does end up being a mix. It depends on the corporation. Some of them will take it workload by workload: for this workload, we’ll use MongoDB, and for a different workload, we’ll use SQL. Others are taking an all-in strategy.

It really varies based, in some cases, on how much greenfield versus brownfield you have in your portfolio. In other cases, it’s where your talent already is. I was just at a major automotive company here in North America. I was at a hackathon where we trained up about 250 engineers and turned them loose for 3 days, and they’ve got some new product ideas that fell out of that.

There’s no single right answer. There are lots of ways to walk through that forest. But at the end of the day, it does come down to the right solution for the right problem. Where we typically help people is with those modern applications that need speed at scale and those gigantic use cases that increasingly need better retrieval quality.

I’m really interested in Big Three tech modernization, and I have a bit of a brush with it from time to time—just enough to know that there’s a lot of appetite, but there’s also a lot of friction. What was your experience of it? I’m sure a lot of these app concepts that people were working on are AI apps, right? Without naming names, what more can you tell us about the on-the-ground experience in the Big Three?

Some of them were customer-experience applications. Others were about how we can make the dealers more efficient or how we can make the mechanics more efficient. Some of it was about how we can make the in-car experience more efficient. It really spanned the gamut of different types of use cases that a Big Three automaker might have.

Our education system has a historical bias that thou shalt always normalize. For a lot of use cases, that’s valid, but there are an increasing number of use cases where these Big Three considerations matter. Increasingly, that retrieval-quality one is becoming a much bigger deal for agentic architectures as you start to try to take better advantage of the context window than just stuffing it with 1 million tokens every time.

We can get into some of the details as to why we’re a good fit for that and why that’s emerged in the wake of what happened to Uber earlier in the year, with them burning through their token budget for 2026 in 13 weeks. That grabbed a lot of headlines, and there have been similar stories about how maybe token maxing wasn’t such a great idea to begin with.

Yeah, it was a phase. We’ve all been through our phases.

I was really attracted to the schemaless database model way back when because I’m a free-flowing person who loves to make a mess now and tell myself I’ll clean it up later. This is one of the things I’m really interested in in terms of how the database interacts with AI applications, because it seems like, on the one hand, it’s more tempting than ever to do that. It’s more valuable than ever to just say, “Let me dump all the data in here, and maybe an AI will make use of it sometime later.”

But then you do have interesting challenges downstream of that. One is your example of the 2 records with the same address. Now you have to update it in 2 places, so that’s something to keep track of.

I’m also struck that the advantage of latency may be somewhat reduced. You may have a different take on this, but it feels to me like the advantage of latency is somewhat reduced because everything gets put through a slow step anyway. The ability to shave a little time off the database call when I’m then going to have to wait for tokens may matter less.

I’m also thinking that if I do start dropping all my data payloads into an extra field, I’m going to be doing exactly what you’re saying I shouldn’t be doing in terms of just bringing 1 million tokens into context all the time.

Take that in whatever direction you will. What do you see as the biggest trends in application development that have a bearing on your database choices as we’re AI-ing everything?

5. Enterprise database choices (Part 2)

Sure. First, let me push back on one thing you just said. Most people think that we're schemaless, and that's not actually true. It's not that we're schemaless; it's that we're schema-flexible. You can change the schema more easily over time because more of the data is denormalized and therefore centralized. It's not a strict requirement that every document in a collection have the same shape.

We don't have tables and rows, right? Think of a JSON blob as a document, and you have multiple JSON blobs put together into a collection. Not every document in a collection necessarily has to have the same shape. You can have differently shaped documents in the same collection.

Because the schemas are flexible, and because you can have different document shapes in the same collection, that's why people assume that we're schemaless. But what it does is give us the ability to be malleable in a way that a traditional SQL schema is less malleable. I won't say it's not malleable at all, because it depends on how you're laying out the data, but anybody who's ever had to change a SQL schema that's already in production knows the pain I'm talking about—the cascading effect that has on multiple tables.

If you had some of that data denormalized, it's far easier to add attributes to a document that's already there and do so selectively, in a way that isn't possible nearly to the same extent in the SQL world. This is where the history of how we've implemented vector search, and the impact that has on application architectures for agents, ends up mattering. The details matter here. If you'll allow me, I'd like to talk a little bit about that history. Does that sound okay?

Yeah, please.

Okay. For us, it really started in an unusual place, and that is with lexical search. In 2020, we noticed that a common use case for MongoDB was for people to stand up their own Apache Lucene servers, colocated with wherever their MongoDB clusters might be. The reason they were doing that is they wanted to be able to point that Lucene cluster to different text fields in a document and be able to do keyword retrieval off of them. Perfectly reasonable thing.

So we thought, as you might know, there are 3 different versions of MongoDB. There's Community, where you're responsible for the support and the operations. There's Enterprise Advanced, which most customers are using on-prem, where you're responsible for the operations but we're responsible for the support. And then there's Atlas, which is our managed-service version of it. You could deploy your instances on any cloud hyperscaler data center you'd like, among Amazon, Google, and Azure, and in that form factor, we will do the support and the operations.

Those are the different choices you have when you deploy MongoDB. Regardless of which one you choose, we noticed people standing up Lucene servers so that they could get keyword retrieval on what they had. In 2020, we introduced what's now known as Atlas Search. On the managed version of MongoDB, you automatically get it as part of the instance. There's a lower-priced tier where you just point it to some text attributes that you already have in your data, and we'll automatically index them. You can do keyword retrieval searches on those.

6. Outro

Then the next logical thing was, a couple of years later, if you're going to have lexical search, you might as well also have vector search. Think about this: What's a vector? At the end of the day, a vector is an array of floats, right? You take some piece of data, and whether that piece of data is text, an image, audio, or video, you pass it to an embedding model of your choosing, and what you get back is an array of floats.

To us, an array of floats is just an additional attribute to a document you already have. For us to implement vector search was just to add an additional attribute to the flexible schemas that we already have and then build a vector index on top of that array of floats. That's your vector search.

What it created was this notion of being able to do these powerful hybrid searches as well. The trivial example that most people learn MongoDB from is, suppose you have a book. A book might have a text field for the title, and it might have a text field that is a URL pointing to the cover of that book. You might have an integer that's the number of pages, an integer that's the year of publication, and a text field that's the synopsis.

If that's a standard document for a book in MongoDB and it's put in a collection, suppose now I want to create a vector index off of the synopsis. I could take that synopsis text, pass it through an embedding model of my choice, and then store the array of floats that comes back from that embedding model.

If I wanted to, suppose I had 10,000 records—10,000 documents in my collection. Maybe I only want to do a vector search on the top 1,000. Maybe I don't want to do it on all of them. Because of the flexibility of the schemas, because you can have different shapes, MongoDB not only allows that, but thrives on it really well.

We had lexical search, we had vector search, and then that enabled us to do this notion of hybrid search. Suppose I wanted to combine a lexical search of the title of the book with this vector search that I now have on the synopsis. What if I also wanted to prefilter because I've got some integer fields in here?

Suppose I wanted to do a search where I do a lexical search on the subject and a vector search on the synopsis, but I want to eliminate any books that weren't published after the year 2000. Now I have these 3 levers of query power that together give me lots of interesting ways to query my data. I can combine prefiltering based on the metadata with lexical search and vector search.

Once we had that in play, by 2023 we thought, “This works with any embedding model you want, but could we make this easier to develop if we had an embedding model that was part of it?” That's why we purchased Voyage AI in 2025: to create this better-together story. We can get into all kinds of things with the better-together story, but the way that we go to market with Voyage is, you can use Voyage on whatever vector database you want. You can use any embedding model and use MongoDB as your vector database, or you can use them together, and there's a better-together story that's a part of that.

That's our history. As I said, it's unusual that it started with lexical search, but it went lexical search, vector search, hybrid search with prefiltering, and now this better-together story with the Voyage embedding models. That's how that built over time for us.

What is it like to query that today? Has this been relatively recently advanced—that I can now issue a single query and put, in SQL terms, I guess, a WHERE clause on all 3 of those different kinds of data, and the engine under the hood chooses which filter to apply first? I don't have to worry about all that stuff anymore. Is that right?

That is. One of the advantages of the way that we implemented vector search is that it gets to stand on the shoulders of the base product that we already had. We've been running Atlas in production for a decade now, so we already know how to replicate data across multiple data centers, even across multiple clouds. We already know how to do sharding, whether you want to keep data close to specific users for business reasons or for legal reasons.

We already know how to do security—not only encrypted at rest and encrypted in transit, but also during the query. We get to stand on the shoulders of all of that for vector search. One of the things that we get to do on top of that is, MongoDB has always had this notion of aggregation pipelines.

The point of aggregation pipelines is, instead of forcing you to do a query, get some JSON blob back from your result set, and then have to massage that before you use it, with aggregation pipelines you give extra instructions to the back end so that the data gets sorted, filtered, and massaged in different ways. What you get back from that API call, you can now use immediately, and you don't have to do any further massaging.

Because we already had that mechanic in the core product, what you're referring to is that we just announced a pair of features. One is called rank fusion, and one is called score fusion. What that allows you to do is, in the absence of these new aggregation pipeline stages, you would have to make the vector search and then independently make the lexical search, and then you would have to combine them yourself.

Now, with those 2 aggregation pipeline stages, you can do it in 1 API call. You only have 1 round-trip call to our servers, and then on the back end we'll do both of those calls for you. We'll combine the results either based on their rank, with rank fusion, or based on their score, with score fusion, so that what you get back is an already sorted list based on whichever of those functions in the aggregation pipeline you chose. You can then use that JSON blob, that result set, immediately.

I'd love to learn a little bit more about how that works, because this is something that I've run into, and I've come up with pretty simple solutions for myself, right? You sort of have the filter, and then I'll just be like, “Okay, I guess I'll sort by the vector match score subject to the filter,” right? Or we'll kind of rank them based on different filter values.

It's always struck me that there should be smarter ways to do that than the ones I've come up with, and you guys have some. What are the kind of galaxy-brain approaches for getting the best final sort order from these fundamentally different things?

For now, what most people are doing—and this is the reason why we have the pipeline stages that we do—is usually based on a ranker by score. If you also throw in pre-filtering, that lets you reduce the dataset before you do the queries. Then you get those query results back, and you can interleave them based on either score or rank. For now, that's what most people are trying to do.

But my joke for this, Nathan, is that there are 2 kinds of developers: those who love MongoDB and those who haven't tried us. We're always in a pretty tight loop of feedback. The whole reason we came up with rank fusion and score fusion is because the community told us they wanted it.

Very much the same way: Why did we start doing Atlas Search? Why didn't we make lexical search part of the platform? Because we saw people were using it, and we found a way to make their lives easier so that you don't have to spend the operational cycles managing your own Lucene servers. What could you do with the cycles that we give back to you?

It's the same thing with rank fusion and score fusion, so that you don't have to manage that codebase yourself. You can just throw it in as a verb in the query that you already have. Okay, now what are you going to do with the time that we're giving back to you? The community is going to tell us what other kinds of things they want with that.

7. Contextualized chunking tradeoffs (Part 1)

Reading more novels is one candidate answer for what I'll do with my time savings.

And going back to your book example—

Yeah.

Another thing I've struggled with at times is, let's say I have the book, but let's say I actually have all the contents of the book, too. Right now, I've got hundreds of pages of text associated with this one entity.

I just read a novel that had acts. It had 4 different acts, and then, of course, there were chapters within the acts, and then there were sections, perhaps, and paragraphs, and obviously you're down to sentences at some point. How do you think about—and I think there's some new work on this, too, although I confess I don't grok it fully—how that raw text should be chunked or otherwise divided up to be represented in vector space?

8. Contextualized chunking tradeoffs (Part 2)

Am I looking for a single answer to that, or do you think of it more like a trunk-and-branch-and-leaf kind of thing? I've experimented with that kind of stuff a little bit as well, but I don't really know what the state of the art is in that realm today.

Fair. More broadly speaking—and I promise I'll answer your question—the use case for this level of search, for this kind of semantic or vector searching, is typically RAG pipelines for agents or for more sophisticated agentic memory for agents. That's when you typically see vector search start to enter the conversation, when it enters an agentic architecture in some way.

Specifically, what you're talking about here is chunking, and chunk size tends to matter more in that RAG pipeline use case. I've got some external data. I've got some proprietary data. I want to inject that proprietary data into my LLM of choice without having to go through an expensive fine-tuning or training process, because the LLMs are trained on public data. They're not trained on my proprietary data.

How do I inject that in a safe way that still gives me some data fidelity, so that I'm not giving away my proprietary data, but I can still get it to focus on my business problems instead of asking about things every LLM knows, like who the last 30 Oscar winners were? That's not super helpful when I'm trying to get an agent to help me figure out what my NOC should do next or what my IT ticketing should do next. So that's the use case.

If you've got a bunch of documentation that someone who is a human professional in that world would use, you now need to figure out how big the chunks should be that you place in the individual documents, and what the fidelity of that should be. When you're the application developer trying to figure this out, there's a trade-off that you're looking at.

If I make my chunks too small, let's say to the fidelity of a sentence, I potentially lose the context in which that sentence appears. If you read 1 sentence from a novel, it doesn't tell you a whole lot. But if you then also read the paragraph or the page, it tells you a lot more about the context of that sentence. So that's an argument for, well, maybe I should make my chunks bigger.

There comes a point, though, where if my chunks are too big, my storage costs start to go up and my retrieval quality starts to go down. If I've got 3 pages, let's say, and I'm trying to get to the fidelity of a sentence, I now have too much information and I lose the fidelity of that sentence. So what's the right answer?

I've been doing this a long time, Nathan. The answer is always, "It depends," right? As a developer, you have to go through this iterative cycle: I chunk to a certain size, I run some tests, and I look at my retrieval quality. Then I try it again with a different chunk size, do some tests, and see what my retrieval quality is. I have to do that 3 or 4 times for my use case to try to find the right balance between chunk size, cost, and retrieval quality.

One of the reasons we bought Voyage is because those guys' side hustle is teaching people at Stanford how to build LLMs. Those guys are all geniuses. They came up with this new concept last summer called contextualized chunking. We've got a blog article on this that we can potentially link through here.

The idea here is that if you're left to your own devices to figure out your own iterations of chunk sizes, there comes a point on a graph where, if you've got retrieval quality on your y-axis and chunk size on your x-axis, with a traditional embedding model, at lower chunk sizes you have zero context. The retrieval quality is low, and it builds, but then at some point it flattens, and then it starts to degrade if your chunk sizes become too big. That's why you have to go through these iterations to find the right combination.

But what if you didn't? What if, instead of sending it all as 1 big text blob, you sent it as 2? What if you sent the fidelity of the sentence you actually want and then, as a second string, you sent the other contextual information? That's where the name contextualized chunking comes from.

We will figure out for you what the right chunk size is for that combination, and we will give you a vector array back that balances those things for you. When you flip that script, it turns out you can get better retrieval quality with a smaller chunk size, which otherwise is not possible if you're doing it the traditional way. The way to get better retrieval quality was with a higher chunk size.

If you use this contextualized chunking, we released version 3 of that last summer. We just released version 4 of that in the last 6 weeks. You can flip that script.

There still are use cases where you need to control the chunk size for different things, but if that's something that you wanted to not worry about or have to learn about, the way I think about this is that more developers will build AI agents in the next 3 years than did in the last 3 years. In order to make that possible, we have to lower the learning curve. We have to make it easier for the developer ecosystem to learn how to do this.

So if you don't want to have to learn how to go through the iterations of figuring out the right balance of chunk size and retrieval quality, instead, if you could use contextualized chunking, we'll figure it out for you, and you still get good retrieval quality out of it. That's one of the benefits that Voyage offers that no other embedding model on the market offers: an ease-of-use feature that gets you better retrieval quality.

I definitely appreciate not having to worry about it, but I do want to learn a little more about it. It sounds like this happens in sort of a test-free way at the level of the developer, so I don't have to bring a bunch of evals.

So, at the level of principles, how is it working in the background? You said also that I'm getting 1 vector back, right? I pass in the chunk that I think I would really want to be able to zero in on and the context, and that gets converted into a single vector that represents both of those things in, I guess, some sort of superposition.

Yes, that's exactly how it works. You get back 1 array of floats, exactly as you did before. You just don't have to go through the iterations of figuring out the size of the chunks you need.

Similarly, there's another Voyage feature that all the Voyage embedding models have called Matryoshka Representation Learning, because the other place you have to make a decision about storage cost versus retrieval quality is with the number of dimensions. What do I mean by that? Everybody knows what 2 dimensions are if you've taken high-school-level algebra, right? X, Y, right?

But in an embedding space, you tend to have at least 256 dimensions and sometimes as high as 2,048. The more dimensions you have—each dimension is represented by one of those floats in that array of floats—the richer your embedding space is and the better retrieval quality you get. But at higher dimensions, that doesn't come for free. Storing 256 floats takes up less space on disk, in the index, and in memory than storing 2,048, so you again have to go through this iteration of determining the right number of dimensions for your use case, given what your storage costs might be.

All the Voyage models have a feature in them called Matryoshka Representation Learning. It comes from Russian nesting dolls. If you think about how Russian nesting dolls work, you've got 1 doll, and you open it up and there's another one exactly the same but smaller—a smaller-fidelity version inside—and then you keep doing that over and over.

Suppose you wanted 1,024 dimensions. You run some tests, and now you want to try 512. With a traditional model, you have to run your entire corpus of data through a second time at 512. But with Voyage models, you don't have to do that. When you've run it through at 1,024, those floats are ordered. If you want to try 512, you just lop off the last 512, and you can immediately begin testing with the remaining 512.

Again, it doesn't completely solve the problem of figuring out the right combination of retrieval quality and storage space, but it helps you get to the answer faster. When you take some of these things and sum them together, we've got 3 or 4 of these features that make it easier to use and help you get to your final answer more quickly. The idea there is to give you time back in your day that you can work on your business logic instead of figuring out the plumbing.

9. Retrieval quality thresholds

Yeah, that's cool. I'm a huge fan of Matryoshka anything. When does this stuff become necessary?

For me, I'm basically a business of 1, and I try to be an early adopter of everything that I can. I do have a pretty well-working system—I call it Deep Context—but it's basically a retrieval system that allows my agent to go into all of my history from the last 5 years: emails and Slack messages, everything I publish online, and DMs across all kinds of channels.

The transcript of the podcast, diarized so it knows what I've said and what the guest has said, adds up to about 1 gigabyte in my case. I haven't optimized it much at all. I just let the agent throw it into a database of its choosing and put whatever optimizations on it felt like it needed. At one point, it was like, “Well, yeah, we could probably do better than keyword,” so we've got an embedding layer on there as well. Full disclosure, I believe I used the Gemini embedding model for that.

But it's not very well optimized. How would I know if I'm really missing out on something? I don't have a huge eval; I'm just kind of vibing it. It doesn't seem to be working well. Is it a matter of data scale or scale of users? Is it about cost? I want to optimize my inference cost, and that's where I really need to get serious about how much data is being returned.

What are the thresholds that people—or obviously larger organizations—cross where they're like, “Okay, we can't really do it the let-the-agent-choose-its-own-adventure way anymore. We really need to get serious about some of these optimizations”?

I'd return to the 3 things I mentioned in our first 20 minutes or so. It's speed, scale, and retrieval quality—the main 3 things. What most people do, and you're not going to offend me if this is what you did, is start with Postgres and pgvector, and then choose their embedding model based on whatever cloud they're using.

Gemini is prominent if you're going to use Google, just like OpenAI's embedding model is pretty popular over on Azure because of the historic relationship those 2 companies have. But when you're doing a demo or a proof of concept, it doesn't always show itself. There comes a point where milliseconds matter to your use case and where scale matters to your use case.

Depending on chunk size, that typically comes at about 100,000 vectors. That's what I mean by scale. When does retrieval quality matter? If you look at the Voyage AI models, Hugging Face has a benchmark out there called MTEB that Voyage AI models are typically at the top of, and we can get as much as a 14% improvement compared to some of those other embedding models that we just mentioned.

Are there use cases for which a 14% difference in embedding-model quality is the difference between a hallucination and a correct answer? That's before you even start putting rerankers on it, which is another way that you can boost retrieval quality without having to do anything special to your data. Like I said, it's speed, scale—in this case, typically in the neighborhood of 100,000 vectors—and retrieval quality out of your embedding model.

Most people think embedding models are commoditized, and that is not true. There is a very big difference that you can get in retrieval quality based on which embedding model you choose. Anthropic does not have an embedding model on the market. They recommend us. It's a great recommendation.

You mentioned rerankers, and there was also this earlier concept of sorting results out of the database. This brings to mind the concept of bitter-lesson engineering, which I think is growing in prominence. From my simple point of view, it's just that every so often you should probably go through your stack and look at all the kludgy extra things that you did to make things work and ask, “Which of these do I no longer need because the model got smarter or the embedding model got better?”

Things are just naturally working now, or could naturally work now, whereas in the past I had to do all these artisanal craft sort of things to make sure that they worked. Are you seeing examples of that in the retrieval space broadly, where things are in some ways getting easier? Or have you not really seen the bitter lesson apply to these pipelines and production environments?

I think there are 2 places I've seen that recently, and one of them is with the reranking that we were just talking about. In the spring, we released $rerank, which is a companion to the score fusion and rank fusion that we already talked about. Those 2 relate to doing a hybrid search.

Historically, you would have to do your vector search once, send your results to a reranker to get them reordered in a way that is most optimal for a RAG use case, and then put them into the context window. Just like we did with score fusion and rank fusion, we've now got a stage where, if you do $rerank, you call the API once. We'll do both of them for you on the back end, so you only have to make 1 round trip to the server. That's one place that we've seen some additional ease of use.

The other one is a feature that we released recently called auto embeddings, which is a better-together story. You tell us which collection, which attribute on documents in that collection, which Voyage model, and how many dimensions you want, and we'll take care of the rest.

Anytime an existing document with that attribute changes, we will automatically take that new—let's say it's text—put it through the embedding model, update the vector in the document, and update the index in memory. It will do all that for you. If a new document shows up in that collection that has that attribute, we'll go through the same cycle for you.

Again, we're trying to remove some of the plumbing so that you get some time cycles back as a developer. You don't have to craft and maintain your own embedding pipeline over time.

You just pass us one JSON blob, and we'll do it for you.

10. Agent memory systems

Zooming out a little bit from the database to the broader systems that wrap around them, you said some stuff about memory for AI systems. This is another thing where I've seen some great innovation and then some simplification. Probably the simplification has been enabled by things that enterprises are maybe a little reluctant to pay for at scale. When I get a 1-million-token context window, I'm like, “Great, now I don't have to worry about all this stuff. I can let the model handle a lot more of it.” But I do take your point that if you've got thousands of users, that can add up.

How would you describe—and of course, it depends, but trying to abstract away from some of the details and give me a center-of-the-distribution description—what would you say is the state of the art in what a good memory system looks like today?

Sure. History matters here. When ChatGPT came out at the end of 2022, it had a very simple application architecture: you took the query, put it in a context window, the LLM would process it and give you a result. End of story. That's how it worked.

By the next spring, you would see headlines like “ChatGPT passes the bar exam,” and it would have these very cool things it could do. We've already talked about why you need RAG, because those LLMs, even today, are only trained on public data. If you want to inject proprietary data into it, you need to specifically do that with a RAG pipeline.

What we saw in 2025, though, was the second problem that we see with the core LLMs, and that gave rise to the need for memory. In spring of 2023, if you had asked ChatGPT, “What's MongoDB's stock price today?” it couldn't tell you. The reason it couldn't tell you was that LLMs have a knowledge cutoff date. There's a date after which they don't know anything about the world, because the model vendors at some point have to stop training and put them into inferencing mode.

The way that we overcame that in 2025 or so was with tools and with MCP, and by being able to grant the LLM access to an API or a tool we could call to get additional information. That's why, whether you're a Claude person, a Gemini person, or a ChatGPT person, today, if you ask, “What's MongoDB's stock price?” it can tell you. It can find a tool in its arsenal, make a web search, get that information, and report it back to you.

The other thing we saw in 2025 was this notion of looping, where the result of one loop of that agent then became the input of the next one. The context window is still very dumb, right? You have a fresh context window every time you pass something to the LLM, and that's when we needed agentic memory.

The early versions of agentic memory we saw had short-term memory that was typically, “Okay, take every response that we got within this session and cram it into the context window so that we can see what happened earlier in this conversation.” Long-term memory was, “Okay, now do the same thing for every session we've had for the last 3 days and cram that in there as well.” That had 2 negative side effects that I now see people starting to push against.

The first negative side effect, which we already talked about, is token maxing. If every agentic loop puts 1 million tokens in the context window, even if you don't necessarily need all that context, your cost starts to add up. But there's also a functional cost to that. There are a couple of academic studies that show that the first 7K and the last 7K tokens are the most important, and the stuff that's in between can end up muddying and confusing the LLM as it's trying to come up with an answer.

Instead of thinking, “How could I maximize this? How could I cram 1 million tokens into the context window every time?” what if I could choose just the right 200,000 for this agentic loop? We're starting to see more sophisticated short-term memory that doesn't take everything in the session, but just the things in the session that are relevant for this pass. The same thing is happening with long-term memory.

We're starting to see some new memory types. Especially in Fortune 500s, there's a new memory type called taxonomic memory. Think about either a vertical, like automotive, which we were talking about before, or a specific company. There's some terminology that's specific to a vertical or a particular company, where a layperson who isn't in that vertical might think those words mean different things.

You might have a list of, let's say, 100 of those terms, but for this agentic loop, what are the 5 that are relevant for this loop of the agent? Then do that again for the next loop: what are the 5 that are relevant for that loop of the agent? Instead of taking all 100 terms and putting them in the context window every time, when not all of them are going to be relevant, what if you could instead have a more sophisticated memory system that, instead of just taking everything, used vector search or semantic search, or some combination of vector and lexical search with some pre-filtering, and got just the right context?

There's some perfect context window for this pass—you never get there—but there's some ideal context window that uses just the stuff it needs. Those are the kinds of things that we're starting to see in enterprises, both to combat the cost of the tokens and to combat the relevance of the tokens, so you can get the best answer out of this call to the LLM.

Do you have any tips for maintaining these memory systems? This goes back to some of the challenges with them, and maybe there are good solutions within MongoDB for some of this. If so, definitely highlight them for me.

I struggle with the lack of normalization, or my failure to observe the DRY rule in my own memory system. Sometimes I'll have these raw exports that combine my email, DMs, and everything else into monthly log files. These are typically a couple hundred thousand tokens for a month. Then I'll summarize those into a monthly summary, and then I'll take the monthly summaries and put those into a yearly summary.

I've also got a wiki-type, Karpathy-inspired structure that sits on top of all that and is more entity-based, with the entities linking to each other. Some of this lives in a database, and some of it lives in a file system. Now I've got a challenge where I'm like, “Some new stuff has happened. What do I do? What do I change? How do I make sure that it's changed everywhere it needs to be changed?”

I sometimes also have instances where I've had really funny problems. I think the models are getting better with this, so maybe it's less of a problem these days. But when I was setting this up in the first place, I had problems where the models would see a project that I experimented with a little bit, or that I was maybe going to pursue and then didn't, and they would keep it as an open thread for months and months. I'm like, “Dude, I never actually did that. You can just forget about it.” Forgetting is also sometimes a real virtue in a memory system.

What have you learned? What tips would you offer in terms of how to maintain these things so they're accurate, not just when you first create them, but on an ongoing basis?

This is the hardest problem with agents right now, I think. The way that I put this to people is: we've been building databases for 60 years, and we've been building agents for about 18 months. Nobody knows all the answers yet. We're all collectively figuring it out.

What I do see with these more sophisticated memory types is that, as the application author, you have 2 responsibilities with these memory systems, whereas with the prior version, you really only had 1. Not only do you call the memory system—“Here's my query. Give me the best”—and maybe you give it a token budget, which is how some of these work, so that you don't have to figure out how many memory types there are or how to query them. You're just saying, “Give me the best 50K tokens,” or, “Give me the best 100K tokens.”

You give it a token budget, and then it gets those tokens back from the mix of different memory types it might have. You put that in the context window, get your answer, and then your second responsibility is to send that answer back to the memory system so it can curate it and write it into the memory system.

When it writes it into the memory system, the more sophisticated ones also have this notion of RBAC, so that if you and I are in the same job type, we get to share memories. If you come up with a really good memory and I get to reuse it later, that ends up being beneficial for both of us. That's the second responsibility you have.

But the hardest part is what you're talking about here. One coworker wrote this to me yesterday, and I want to quote him: “Write, change, recall, forget.” These things have a half-life to them, right? Things that are more recent are more important than things that took place weeks, if not months, ago.

Can you tell me about any specific tricks or advantages for these kinds of graph structures that I seem to keep making? I have people and the organizations they work for, and the ideas that I associate them with. These things all point to each other, but they do it in a pretty loose way.

Right now, I'm trusting the agent to hopefully notice those pointers and, to the degree that I'm running maintenance, hopefully follow those pointers and do the necessary maintenance. I don't have a lot of guarantees, and I suspect there are better technologies that I could be building on that would give me a lot more robustness.

There are a couple of different ways to tackle this. Like I said, the “forget” part is the hard part of it. What we see our customers doing is using the retrieval quality of those memory types. That’s where a non-commoditized embedding model can make a difference, and where a reranker can make a difference.

Depending on the use case, you can get a 5% to 10% boost in retrieval quality just by using a reranker on top of whatever embedding model of choice you have. That’s true architecturally as well. That’s why we made it so easy to implement the reranker on top of the Voyage embedding models when you’re doing that vector search.

But there are use cases where you have so much data that you might have to take a hybrid approach. Maybe you use a graph structure for 2 to 6 levels of data, then you get down to a leaf and do a vector retrieval inside that leaf. We see people doing that as well.

There’s all kinds of information you can find on our website about how, because we’re JSON-based, you can use MongoDB to build graph structures into your data so that you only have to go to one place for a graph database, a core database, a vector database, embeddings, and reranking. You don’t have to try to stitch together multiple tools yourself and maintain that over time.

But we do see people doing that with graph structures. It’s typically not as deep as you would traditionally think of a graph database needing to be, but, like I said, it’s pretty common to go half a dozen or maybe a dozen layers for bigger corpuses of data that are more heavily categorized. Some of our retail customers do that with product databases. If you think about how a hierarchy of products might appear on a website or on a mobile app, they might segment that first by product category, using more of a graph style, and then, once you get to a particular product category, do some vector searching within that individual category node.

Are there any applications that you would point to as just being great examples of memory well implemented?

11. Enterprise AI deployment

Our biggest customer right now hasn’t been very public about how they did it. There’s a company called ElevenLabs. They had multiple agents per customer—a sort of micro-agent approach where you get multiple smaller agents at the disposal of individual customers, given the number of customers they have.

ElevenLabs started life as a model provider doing highly sophisticated speech-to-text and text-to-speech. They built a platform on top of that that’s more like an audio-editing suite. As part of that, they have a bunch of agents doing all kinds of editing and transformation for their customers. If you think about the kind of contextual memory they have there, that’s an important way to do it as well.

I would worry about any memory architecture that, instead of relying on lower-cost embedders and rerankers, relies on multiple passes of the LLM to help you categorize and shrink the corpus of data that you might then want to put into the context window for the larger, more functional LLM call. That’s just adding up tokens as well. That’s why things like embedders and rerankers have a lower token cost: it’s the right tool for the right problem.

Yeah, that adds a lot of latency too at this point. Even the small models can reason for quite some time before you actually get your answer from them.

They can, and all those things add up over time. It’s not just tokens, but you’re right: the overall latency for the decision loop that you’re in makes a big difference.

I think you also have some interesting takes on build-versus-buy analysis. I won’t even try to summarize it. Just give me your hot takes on how people should be thinking about building versus buying. What is mature enough in the AI realm to buy? And if you buy part of it, what do you still have to expect that you’re going to end up building or customizing enough that it feels like building?

I have the good fortune in my job of having traveled to 7 countries this year to talk to probably 100 different customers about where they are in their AI journey. They tend to fall into 3 camps.

Camp 1 is, “I bought a license for this one tool and I’m done. My AI strategy is done. I bought one thing.” While that can be a good starting point, it typically isn’t specific enough to help solve the problems of your overall enterprise.

Then you have a group of people who have done some POCs and maybe a couple of production deployments, with varying degrees of success and, in some cases, struggles with ROI. I always argue that they probably picked the wrong problem. Picking the right problem is really important in this space.

The way that I encourage customers to think about this is: What are the top 10 to 15 problems that you have going on in your business right now? Of those, what do you have good data for? You made a comment earlier in this conversation that data quality is a big deal. Things like bad data quality and a bad security posture don’t get solved by AI; they get amplified by AI.

What are your biggest problems? What do you have good data for? And what do you already have metrics for around the problem? That’s the biggest difference that people tend to skip over when it comes to problem selection. If you don’t already have metrics for how something is performing, you won’t know if it got better.

Call-center use cases are popular low-hanging fruit in enterprises because I already know what cost per call is. I already know what call volume is, based on how I’m already bonusing people in those jobs. If I introduce AI into their workflow and see those numbers change, I can attribute that change to the AI and do a back-of-the-envelope ROI calculation.

We see the same thing with the software development life cycle. Earlier in the year, we saw all kinds of bragging: “Now, because I’ve got Claude Code or Codex, I can produce 5 times as much code as I did before.” Anybody who’s been doing it for any length of time knows that lines of code is a terrible metric to judge the productivity of a set of developers by. Instead, how fast are you getting from idea to production deployment? That’s the metric that matters there, not necessarily lines of code.

The metrics matter, and that’s the difference between the folks who are in that middle state—either stuck in POC purgatory or who haven’t quite gotten to production deployments. The biggest difference isn’t in how they’re applying the technology; it’s what problems they chose to try to solve.

Then you’ve got people who are more advanced and are looking at some of these more sophisticated memory types and things where they’re trying to optimize the systems they have. In some cases, they’re making purchases of larger platforms to help them do that. Other times, they’re doing it in-house.

Like I said, we’re 18 to 24 months into this. There’s no one way to do this yet. There’s no LAMP stack for agents in the way that we have with web development. We will get there. Having lived through that life cycle, we’ll eventually get there, but there’s no React and Angular, and there’s no LAMP stack for agents right now.

You mentioned call centers, and this is the second time today that this has come to mind. I just ordered a pizza last Friday night from the local pizza place in my neighborhood. Shout-out once again to Greg’s Pizza in Detroit. I think it’s just a 1-location business. Who answers the phone?

Detroit-style pizza is underrated, by the way.

It is. This is actually a traditional, circular, round pizza. But I agree: after autos, Detroit’s biggest export to the world is pizza.

Even with this 1-location business, I call, and who answers but an AI agent? It was a pretty impressive experience, I have to say. It was a very natural conversation—not flawless. There were a couple of little things, especially as I started to get a little adversarial in my testing of it. I asked it what company was powering this AI-agent experience I was having, and it took that as if I somehow thought I was ordering pizza for my company. There are still some kinks, but overall, I was very impressed. I thought the happy path worked really well.

This has me thinking that there must be a ton of transformation happening at call-center businesses. There are always these waves of change. The first wave is that we give our agents a tool so they can get help faster and be more accurate. Then there’s a next wave—or there might be several waves—but certainly one that seems to be coming is that you just call and talk to AIs.

How far along that journey are the customers you’re talking to? How much actual disruption have you seen in that part of people’s businesses so far?

Most of the Fortune 500 companies that I talk to are doing employee-facing use cases with a human in the loop, for exactly the reasons that you just laid out and for some of the ROI reasons I mentioned before.

If you think about the employee-facing use case, you already know what you’re bonusing your different employees on and what KPIs—key performance indicators—you’re using to judge whether they’re doing a good job. I used the example of call centers before, but you can think of any job, whether you’re an insurance adjuster, a line worker in a manufacturing plant, or whatever your job might be. Everybody’s got some key performance indicators.

And if you introduce AI into whatever that workflow is and you see those jump, that means you've figured out some ROI. But there's also a data-security issue. If you and I are employees for the same company, is it great if my salary accidentally leaks to you? No. But it's way better to have that than if we are 2 customers of the same company and I get to see your data. That is a scenario where a VP has to take the blame.

So the risk-reward is higher for customer-facing use cases than it is for employee-facing use cases. At least where we are now in the ecosystem, where I mostly see the Fortune 500, with exceptions, of course, I see a lot more work going into those employee-facing use cases with a human in the loop than I see going fully autonomous AI with customer-facing use cases.

For you, in what you're doing at and for MongoDB, you've of course got traditional documentation that human developers can go and read. But I'm sure you're also thinking a lot about how to make your documentation AI-friendly, how to have an AI proxy into that documentation, and then potentially how you're packaging up and distributing skills, trying to think about how to become the database that is recommended by the agents when somebody's doing something for the first time. How has your role in bringing this technology to the world evolved in light of all the different ways that people are discovering and starting their implementation process?

12. Voyage acquisition strategy

All the things you just mentioned are certainly things that not just us, but every software company, is involved in one way or another. The 2 that I would shine a spotlight on are the MCP tools to make it easier for agents to talk to your data in your MongoDB instances. We had an MCP server for a while, and we're now self-hosting some of those as part of Atlas, as part of the ecosystem.

The other one is agent skills. Think of that as curated system prompts for doing things like data modeling and optimizing operations—things that we have well-organized playbooks for that previously we would have as documentation, but now we have them as a series of Markdown files that you can feed to an agent of your choice to give it the lowdown on different ways that it should approach different tasks.

I think Agent Skills Week just dropped a couple of months ago, with the top 8. It's 6 to 8 different agent skills that we have for things like operations and data modeling to help you do those sorts of things. That's become pretty commonplace these days, and we're certainly part of that ecosystem.

You mentioned this acquisition that MongoDB did of Voyage AI a couple of times, and I had a couple of theoretical questions about that. One is, it's striking that MongoDB built its own vector database, right? There's a bunch of vector database startups out there, so one could have imagined an alternative scenario where there was an acquisition of a vector database startup, but there wasn't. There was an acquisition of the model startup.

And then just look at the relative value. You said these guys are geniuses, and I don't doubt that, but the price, even at $220 million—which I'm old enough to remember when that was serious money—is less than 1%, I should say, of MongoDB's overall market cap. I'm wondering what we should infer from these observations about value and defensibility in the software business over whatever passes for the long term in your mind.

You could tell a story about infrastructure being the big winner, models getting commoditized, and incumbents being able to defend themselves against startups. What do you think are the right macro lessons to draw from this experience?

Fundamentally, what we've always been about has been how we can make the day in the life of a developer easier, so that we can make it easier for them to build their business logic and spend less time worrying about the plumbing lower in the stack.

I went through a description earlier in this conversation about how we implemented vector search. For us, because we already had the JSON-based document model, it was relatively straightforward for us to say, “Okay, you add an additional attribute. That attribute is your array of floats. You generate an index based on that array of floats, and you're off and running.”

That was pretty straightforward for us to add to the existing product and take advantage of things like sharding, security, and data replication that we already had in the base product, which some of the net-new vector database companies out there have to catch up with and struggle with a little bit. That's why we chose to do vector search the way that we did: because of the flexibility built into the document model from the very beginning. It was pretty straightforward for us to do that.

But where it was not as straightforward, and why we made the Voyage AI acquisition, was that today you can still use whatever embedding model you want, as long as it generates that array of floats. You put that array of floats in your document, you create your index, and you're off and running. But we saw an opportunity because the market was seeing embeddings and rerankers as a commodity, whereas we saw Voyage AI really standing out. Like I said before, Anthropic agrees with us, and we could create these better-together stories, like the auto-embeddings that I mentioned before.

Another one I didn't mention is being able, in Atlas, to manage all your API keys in one place, so that you don't have to go to one console for your core data, another console for your vector data, a third console for your embedding models, and a fourth console for your rerankers. You can get all that in one place. The management of it is easier over time.

If you look at the history of MongoDB features and really what our focus has been, we're all developers at heart, and it's about making it easier for the developer ecosystem to learn and operate these new techniques that we see in application architectures around agents, whether it's the RAG pipeline or agentic memory. How do you make vector search more approachable? How do you lower that learning curve so that more people can learn it more quickly and start to participate in this ecosystem?

Another story that I've heard, and I want to get your reaction to it and see if you think it's true in your experience, is that I was speaking to a founder of a vector database startup one time. I put it to him that it seemed to me like incumbents would be able to add a vector aspect to what they're doing before the startup could replace everything that they're doing, so it seemed like the startup would have a hard time really displacing them.

His answer was, “Well, that may be true, but most of the data that's coming into our vector database has never been in a database before at all.” It's just been sitting out in some data lake or data warehouse, or in unstructured piles of documents. Now it's coming into a higher level of infrastructure and being made more valuable in a way that just wasn't happening before.

Sure.

Are you seeing something like that? What does that look like? I also noticed that there's a multimodal embedding model that supports video, so video would be a great candidate for the kind of thing that has never been in a database before. Are you seeing this phase shift of a much greater universe of data coming in than in previous eras?

We are seeing this broader ecosystem of data that wasn't indexed before because it didn't lend itself to traditional lexical search. The cool thing about vector search is that, at its core, it's taking some piece of data and mapping it into N-space, into some geometric space. Really, all a vector search is is similarity: where are the closest vectors to this new thing that I'm searching on?

Video is a great example, audio is a great example, and unstructured data is a great example. You just take a bunch of PDFs that you have sitting around in a SharePoint. Those are good examples as well.

So, yeah, I think there's some truth to that. It's not just, “How do I take the data and put it into a database?” but now, “How do I find it, and how do I find it in a way that is fast, scalable, and good quality?”

That's why the way that we implemented vector search—and being able to, within the same platform, have the combination of pre-filtering, vector search, and lexical search—we feel like it gives us an advantage and gives our developer community more levers to pull from than some of the alternatives.

Like I said before, because it stands on the shoulders of the core product, with the Atlas version, you can already deploy that in any hyperscaler data center you want, with good data resiliency and good security. If you need to shard that data so that it doesn't leave particular geographies, we've got all that essentially for free because of how we implemented vector search on top of the core product. We're seeing all kinds of different data get put into those documents in a way that we didn't before.

You mentioned traveling to 7 countries so far this year. I'm so myopically focused on what's going on in San Francisco and Silicon Valley that I'm mindful that I may be missing important stories or differences in perspective that are going on around the world. I try to fill that gap, at least when it comes to China, but it's a big world out there.

What has stood out to you in your travels this year in terms of differences in perspectives on AI usage patterns, values—you name it. It could be anything, but what do you think the US audience, in our inward-looking way, is missing about what the rest of the world is doing?

I think the biggest thing—if I turn the question on its head just a little bit—is that there’s a presumption in other countries that the US is ahead and doing things that other people are not. I’ve found the opposite to be true.

I live and work in Cincinnati, so the US is one of those countries. I’ve spent some time in both Amsterdam and London earlier in the year, but I just did a tour that included stops in Toronto, Bengaluru, Mexico City, and São Paulo. The 2 most sophisticated customers I talked to this year were in Mexico City and São Paulo. They assumed when we started our conversation that they had US competitors who were doing things they weren’t, and, like I said, the opposite was true.

I think we’ve reached a point with some of these technologies where geographic barriers don’t matter nearly as much as they did during the web app era or even during the cloud era. During the cloud era, if one of the hyperscalers didn’t have a data center in your country yet, you were kind of out of luck. That’s not true anymore. Pretty much every country has at least 1 hyperscaler data center in it, and by extension, access to models, vector databases, embeddings, and rerankers is far better than what I’ve seen with previous technology revolutions.

I understand why there would be an assumption that US companies would be ahead, since so many of the bigger AI companies are US-based. But, like I said, the 2 coolest things I’ve seen this year were in Mexico City and São Paulo. I think those geographic barriers to being ahead in the market are starting to disappear.

What do you think are the barriers? Why is that? Is it that American companies are culturally too conservative to run as fast as some of these international companies, or is it a leapfrog story where the international companies had less recent technology investment that they would have to get comfortable replacing? What’s driving that surprising observation?

I think it has more to do with the lack of barriers outside the US than it does with any of the behavior of companies within the US. Access is democratized now in a way that it wasn’t for the cloud and mobile waves. If you didn’t have the radio towers yet, an iPhone wasn’t going to do you much good.

Now we have all this infrastructure laid worldwide in a way that we didn’t have 15 years ago, which makes access to these things far easier than it was before. There’s a wider set of people in a wider set of countries that have access now that they didn’t before.

I don’t think it’s an indictment of the way US companies are thinking about it. I just think that greater access erodes the geographic barriers that we’ve seen with previous technology waves.

Any closing thoughts? Is there anything you’d want to leave people with, or anything I didn’t get to that you’d want to make sure we touch on?

There’s 1 technology thing that we didn’t get a chance to talk about, and that’s shared embedding spaces. There’s also this notion of where we are on this journey together.

Shared embedding spaces, real quick, are 1 of the other ease-of-use things that the Voyage models provide that nobody else does. In January, we released 4 versions of Voyage 4, the text model. Everybody typically releases small, medium, and large, and each one has a different price point and a different retrieval quality that comes along with that. But we also introduced something called the nano, which is open-weight and free for anybody to download from Hugging Face.

Each 1 of those 4 models shares an embedding space, meaning that embeddings generated with 1 of those models are compatible with the other 3. What that lets you set up is that you could take your corpus of data and embed it using, say, the large model. Every other embedding model is going to force you to pay tokens during your development cycle when you query against their embedding model.

With us, you could use the nano for your queries. You can run that on your laptop if you wanted to. If you wanted to have zero token cost aside from embedding the corpus of data, you could eliminate your token costs during development in a way that wasn’t possible before January.

That’s not for everybody. You do take a little bit of a retrieval quality hit when you use a different model, but for some customers that want to lower their token costs during development, this is 1 way they can potentially do that. That’s shared embedding spaces, which we introduced in January.

More broadly, I want to come back to the idea that we’ve been building databases for a really long time. We have not been building agents for a very long time. We’re going to continue to see iterative improvement, and it’s going to happen fast.

Anthropic published MCP on the Monday before Thanksgiving 2 years ago, and by March, all of its competitors had embraced it as a protocol. Token maxing first got mentioned in early March, and by April, it was over as a conversation piece. The quickness—the speed at which we have these conversations and go through these cycles of these different features—it’s faster than it ever has been before.

The fun part is that there’s still a lot for all of us collectively to learn. We’re all going to collectively figure out how to make this easier for everybody, and you’ll see more and more agents in everyday life as a result.

13. SQL versus NoSQL

Well, as field CTO of AI at MongoDB, I know you’re going to be racing as hard as you can to keep up with all these cycles, and we’ll continue to look for new updates and more great progress from you. Pete Johnson, thank you for being part of The Cognitive Revolution.