Agents in the Enterprise with MongoDB | Interrupt 26

Thank you very much. Thanks for having me. Did you pay him to say those nice things about Mongo? I was really surprised. And you guys can hear me OK? All right. I was really surprised, and it felt really nice. I'm like, my job is done. I don't need to do this fireside chat.

Yeah, so MongoDB started, of course, as an open-source database company. And that's why we love partnering with LangChain — we have a similar ethos and philosophy on how we build products, what we put in our open-source version versus our enterprise version. The company was created in 2007, and the founding principles were very, very simple. You need a modern database that is not constraining you by rows and columns, and you can move fast as you build applications. So agility was a very important design principle with the document model. Second is commodity hardware and scale-out architecture — AWS was just coming online, so build in the cloud rather than a scale-up architecture. And I'd say the third thing is being probably the best database for unstructured data. Most people looked at it and said, OK — document model, unstructured data, JSON, things like that. And coming to your AI question — AI is all about unstructured data. Even if you use a popular GPT version or whatever it is, you are creating an image. I send lots of silly memes to my kids by generating something. And you want to store all that. So we are the best database for unstructured data in AI. And it is almost a coincidence. That wasn't what the founders set out to build — but they did a great job. And then the last thing I'd say on your question is what we added: native search and vector search — hybrid search. And that's where we've partnered, so you can easily retrieve something. And we added embeddings last year — a great team here, right out of Stanford. So that's what we did for AI workloads. That's the summary, Harrison.

Yeah, so one thing — I'm obsessed with speaking to at least 10 customers a week. And I've done that for pretty much my entire career. So if you think about how many enterprise customers I speak to and learn from about what's going on — that's something I genuinely love doing so you understand what's working, how things are changing, whether it's cloud, AI, the landscape, and so on. So for MongoDB specifically, we found that frontier labs use us for different use cases. That's one very unique class of customers. Successful frontier labs — you can count them on one hand. Some of them are using us for research. Think about research: training data, lots of unstructured data. PDFs, voice, et cetera. So they use MongoDB for research before they ship their next model — whatever version they ship. Some frontier lab companies are using us for the inference layer, chat conversations, long-term memory — what kind of searches were done and all the data that gets stored. And then we have AI-native companies — just last week, with their permission, we announced ElevenLabs. They are built on a particular hyperscaler. They made this mistake — and I'm just going to say it — they made the mistake of using the first-party database from that hyperscaler. It didn't scale. And these guys have built their superpower in text to speech. They were created post-ChatGPT era. They do small language models for text to speech and speech to text. And once they moved to MongoDB, they now have 40 million production agents built on MongoDB. An AI-native company — and they hit $500 million ARR. I mean, it is insane how fast they are growing because they focused on voice as the modality. For customer support, sales — those kinds of use cases. And the last is enterprises, where we have worked together. Enterprises will say, 'Hey CJ, we are using LangChain for orchestration.' 'By the way, my team wanted me to tell you — we use LangGraph and have built some agents, and we are very, very happy. So thank you for that.' Yes, and we are building lots of agents internally for various use cases. So in the classic enterprise space, we have most of the banks that run mission-critical workloads, payment systems, tech companies built on MongoDB, Adobe for many of their products — which involve a lot of unstructured data. Those products are built on MongoDB. So we go all the way from labs to AI-natives to enterprises.

Yeah. So the first time I met Harrison — what the teams told me is that engineers, developers, builders — when they work together, given the very similar design principles we have about how we build products, open source and all of that — this was not a top-down integration between LangChain and MongoDB. Engineers were asking for it — whether it's vector search, hybrid search, long-term memory store, graph RAG, lots of things. Those integrations were built even before this partnership was formal. So it was bottom-up. And we are, like LangChain, extremely developer-friendly. So if you want something, we want to do it. An example is Atlas hybrid search that we did specifically for the integration with LangChain. It just made sense that in the harness layer, if you're doing a retrieval, we should make it easy for developers to do that so they can use our data store. I'm a firm believer in the open ecosystem — because even the labs will ask you to build the harness layer on top of them, as we've seen with some announcements. Hyperscalers will also try to lock you in all the way from the harness layer to the data layer — which is what I was talking about with ElevenLabs. And I think that if we want a fully open ecosystem for all of you to be able to say, the harness layer should work across any models, across any hyperscalers. And as you saw even last week — the announcement about Anthropic using on-prem facilities from xAI — that also tells you multicloud is very, very real because of capacity constraints. So the data layer is there to stay, LLMs are there to stay, and when you want to create agents, you want a great harness layer from LangChain. And I think this trio of things fits really nicely together. We've done a bunch in the open source, the community's done a bunch in the open source, which now we're trying to make more prominent — build into LangSmith, build into LangSmith deployments. A number of customers are already using it together.

Right. So Adobe had — and has — a lot of unstructured data. A lot of unstructured data. They've built many products using MongoDB — Adobe Experience Manager, and I could go through a long list because they provide what they call their digital experience or Experience Cloud. And as they were building agents, they said, 'OK — if we're using LangChain, multiple technologies from LangChain, can we make sure the retrieval is super fast?' And by using LangChain products with us, now they're saying the senior software engineer who built this agentic layer — the comment from that engineer was, 'Now the LLM is the bottleneck, not the harness or the data layer.' And for me, that's the thing — that we want to make agents really work. Because if agents are slow and don't give you accurate answers, what's the point of doing all this?

This is one area. When I meet all these customers on a regular basis, I ask them a very simple question. Because if you think from a customer's perspective, they're trying to deploy agents in three buckets. OK — bear with me. Bucket number one: employee-facing. All these copilots — I'm doing some productivity, I'm trying to re-engineer my process. And I'm building an agent that will go and access multiple data sources, do search, whatever. So that's employee-facing. I'll tell you as a CEO — when people say, 'Hey, I built an agent that's employee-facing and it gives me 5 or 10% productivity' — it's very much a 'meh.' I'm like, 'OK, great.' Thank you for building it, but that didn't get me excited. Then you have partner-facing — 'We created this partner-facing agent, and we have multiple partners, we are this type of company.' And then last — and super important — is customer-facing. And the question I ask is: have you created a customer-facing agent at scale? And when you talk to — I was recently with a very large insurance company that uses MongoDB. And they have not. Simple answer. They've built lots of agents that are employee-facing. And I said, 'Why not?' And it comes down to — 'Hey, we currently work with this hyperscaler, and they have a very opinionated framework they want us to use. Then we have all the policies — insurance policies — and all that data in MongoDB. And we're trying to figure out which models to use. And CJ — if we are going to approve somebody's insurance claim or process a claim, we do want a human in the loop. So the agent can do multiple things right away. If it's truly customer-facing, we're talking 50 million plus customers. And when we roll out functionality in production, we want to make sure our evaluation before we even do that is rock solid.' That's where the biggest bang for the buck is. And I asked them — I was trying to be funny, but it didn't land — I said, 'How annoying must it be for you that you have insurance agents — which are humans — and then everybody comes and tells you about building agents?' Do you not get confused? And it's like, 'OK CJ, I've heard this before many times.' But if they can create those agents that can process an insurance claim, add a dependent, or a driver, or whatever the case might be, change the claim — that's the high bar for them. And they can even create new products that are truly customer-facing. That changes entirely how the CEO thinks about agentic evolution for their 50 million plus customers.

The first thing I'd tell you — and I'm sure all of you face this every day — is what agentic stack to build on. There's so much change happening. They use one particular hyperscaler. They're in multiple regions on that hyperscaler for MongoDB. And the hyperscaler comes with this opinionated approach, and they're like, 'Should we be locked in? Or should we look at something like LangChain?' 'Should we commit to a particular frontier model? Or for sub-agents, should I use different models?' They're experimenting, but things are moving so fast they don't know what to pick. So that's number one. Number two — because they're an extremely regulated industry, whether insurance or banking — how do you actually audit? Can you replay what happened if the agent gave an insurance rate? Did the agent discriminate? Did the agent not discriminate? All the governance, security — and while I was going back and forth asking questions to get my policy, if the agent crashed, what does that mean? How does a human take over from there? Should they do an AI call, a voice call, an agent call? These are real problems when you have 50 million plus customers.

Yeah. The thing is — these customers, the large enterprise customers — that's who we serve. MongoDB is in 75-plus percent of the Fortune 100. So we get to talk to these customers all the time. And the biggest challenge I'm seeing, Harrison, on that point — is that they thought 2025 was the year to create agents at scale for their customers — and that agents at scale didn't pan out to be true for these large enterprises. Now in 2026, they're feeling that some technologies around observability are maturing. Some technologies around the harness are maturing. Yes, everybody wants to play in that space — but they feel those technologies are maturing. And what they're telling their engineering teams from an AI lifecycle development perspective is, 'Let's just go with X, do rapid iteration, figure out if this works, and then roll it out in production.' So 2026 is a little better than 2025. In 2025 — and this customer told me, I'm sure you've heard this before — the number of agent rebuilds, or 'agent washing' as they called it, was crazy at this large account. And they're like, 'Hey CJ, I swap out my agents more than I do laundry.' I said, 'OK, that's TMI.' But the point was that disruption was happening very fast. I feel that in 2026, it's a lot more stable.

So I have my board meeting next week and they're going to ask me the same question. So let's see if this works. I'm helping you practice. Yes, yes, yes. Let's see if this works. So we rolled out one of the coding agents to the entire engineering team. I'll share some rough benchmark numbers. One of the things we're really trying to understand first is: in an engineer's week, what percent of their time do they actually spend coding? And is that now accelerated because of the coding agent? The answer is yes. But for us as a database company — with an extremely technical engineering team — for distributed systems engineers, actual coding time is only 20 to 25% of a week. There's a lot of other things they do — code review, team meetings to make sure design and subsystems work well, and so on. That window has shrunk. So if you look at the numerator — the amount of code being produced is now more, because we're using coding assistants 100%. And when you look at the denominator on productivity — out of the eight hours an engineer used to spend coding out of 40 hours a week — maybe we are saving five to six hours, or maybe three or four hours. So that's the math right now. But then I'm seeing token costs going up significantly. So what I'm trying to figure out is — here is an engineer producing more code. Great. But now my cost for that engineer has increased on the tools she's using. So when you put that together — which we are presenting to the board next week — the cost has gone up. But what is the output? The output is a lot more features or new products, which hopefully we can sell more of. So we are innovating faster, but at a higher cost right now. And that economics has to improve — otherwise it's not sustainable.

Here's my thing — I asked the team just last week. If you look at last week for our engineers — and this is over a large sample size — we have close to 2,000 engineers at MongoDB. Last week, 70% of the code that was checked in was written by a coding assistant. Seventy percent. OK, that's great. It also kind of scares me a little bit — because then I'm like, 'OK, what is the token bill?' And it's pretty high. Is that because they're not writing prompts properly and doing the engineering around that? We'll figure that out. But if they're producing 35% more code so that we can build additional features or products — like some of the products announced yesterday — I'm OK with that. But then I have to figure out: if next year I was going to hire 30% more engineers, do I really need to do that? Because now my engineers are 30% more productive. So that's how I'm looking at it — human cost versus token cost, and what does that really mean?

So this idea — Andreessen Horowitz published a piece today. System of intelligence, right? There was always a system of record, system of action — this, that — but system of intelligence. With agents, agents are a system of intelligence. Now, anytime you want to create a true agent that is customer-facing, your data layer and harness become super critical — beyond just the LLM, or multiple LLMs you may use, or SLMs you may use. So from my standpoint, Harrison — I think of that system of intelligence. And when you look at that memory and context layer — that layer could be a lot bigger than we think it is today. It needs to have the right context and memory so that the agent can make real-time decisions. And it needs to be fed in real time. I absolutely do not believe these are the kinds of things you can build on top of a data warehouse. Because data warehouses were always designed with a 15-minute or 30-minute lag, for asking business questions. Versus — if your agent is customer-facing at airlines, banks — you need to make decisions fast. So this context-plus-memory layer will continue to grow, become super relevant, and will become the high ground by which agents deliver their outcomes — whatever you designed them for.

I think it's definitely a technical thing — because people are asking, 'How much data do I need in that context and memory?' So the agent can produce an outcome — a mortgage rate, in real time, a bank fraud transaction, or something like that in agent commerce. You need really high-speed answers or actions to be taken. And that requires a lot of data. And you have that data in whatever you want to call it — short-term memory, memory, and context. Every enterprise we speak to, when they're trying to create agents — every single one — that data comes from so many different sources. And how do you really build that? The old way of doing software via UI — right? That era is ending. Eventually you'll have the agent, you'll have the context layer, and you're done.

Yeah, so I'll say the first thing we are doing right now is — a lot of these companies sell to us. Our CIO — she's fantastic, very technical — we are only signing one-year contracts. Because this old seat-based model — I mean, you see what's going on right now. Investors ask me, 'Hey CJ, are you going to do layoffs at MongoDB?' I mean, it's an offensive question on multiple fronts. But the thing is — how many more people do we need to hire? We just don't know — with AI productivity gains as we build out agents and so on. So one: we're signing one year at a time. Two: the seat-based model just doesn't work, because I just don't know how and where I'm going to hire in year two or three — so long-term contracts are gone. And then the other thing is I've asked my CIO — I want to cut. We have X number of SaaS vendors we're using for finance, CRM, whatever the case might be — I want to cut that in half. And I want to build things internally — because if I have the right context layer, the right orchestration, and we know the data layer will be MongoDB — why do I need to pay all these SaaS companies X, Y, and Z?

I'm not going to answer that question. [laughter] But — from my standpoint, if you are a vertical SaaS with a lot of domain expertise that has been built in for life sciences, insurance, and so on — I think that is a defensible moat for a vertical SaaS. Or if you have vertical functional SaaS — built for the legal department, things like that — that is definitely a moat. On the horizontal SaaS side, my view is — if you're at the UI layer, and that's your main value-add — a really cool UI — you are at higher disruption risk, versus if you own proprietary data in a system of record that is very specific to you.

Here's my thing. We use a number of vertical AI-native startups. And every time I meet one of those firms, I ask them this question: 'What is your real moat on top of the foundation model?' 'What's your real moat?' And it's interesting. Sometimes they'll say, 'Hey, we have all this knowledge of this particular industry built into how we've built our product on top of the LLM via RAG.' 'And then we have this forward-deployed engineering team that will get you to value not in months, but in days or weeks — and that's our moat.' And that's an OK answer, but not a great answer. Because in the back of my mind I'm worried that if those frontier model companies decide to move up the stack for that particular use case — what does that really mean? And that's why I'm like, 'OK — I understand what you're saying, and I respect it, you're obviously working super hard — but I'm going to only sign with you for a year, because I want that moat to be clear. Otherwise it doesn't work for us.'

I actually have a clear view on this. You should have multiple use cases — and those multiple use cases need to work with each other really well. What's an example? You should have a platform mindset. Say you're doing a use case for finance and a use case for HR. You're doing both — and there's a pattern that works really well for the industry you sell to — say, high-tech verticals like MongoDB or LangChain or so on. The things you provide should work together. If I buy one product from you — great, it works well. Gives me 20% productivity, whatever it is. I buy another agentic product from you. That gives me 20% productivity. But if I combine the two — one plus one is more than two. And you've become a platform that works really well across my needs as a customer. That's the high ground.

I have not seen it yet. I have not seen it. And I think that is the opportunity you have. Because everybody — our IT team, our tech team — they're all evaluating from first principles. The question I've asked them to ask every vendor who sells to us is: 'If we were starting today, would I buy this — and why?' 'And do you have anything else I can retire?' Right now, a lot of offerings are very single-use-case. But even coming back to ElevenLabs last week — when you speak to Mati and the team, they say, 'OK — voice, meaning text to speech — the killer use case was customer support.' But it could be sales. It could be other things. And now you become a platform where you know how to build an agent, and you build the next one at a fractional cost — say, for MongoDB. And it just works. For ElevenLabs, that common thread is the voice model. That's the voice. That becomes the moat. And they are very, very good. 74 languages. And they told me the story of how they got started — the founders are Polish, and they saw a really badly dubbed Hollywood movie that was in Polish, and they're like, 'Hey, this has to be solved.'

It was great being with you. Thank you very much. All right. See ya. Thanks.