Agents in the Enterprise – Chirantan Desai (MongoDB) & Harrison Chase

Speaker(s): Chirantan "CJ" Desai (President & CEO, MongoDB); Harrison Chase (Co-Founder & CEO, LangChain)
Session: Interrupt 2026 · Day 2 (May 14) · ~1:30 PM PT
Source: in-person audio recording, transcribed locally with Whisper large-v3.

Summary

In a Day 2 fireside chat, MongoDB President & CEO Chirantan 'CJ' Desai joins Harrison Chase to discuss how data fits into the agentic era. CJ frames MongoDB as the best database for unstructured data, which 'is almost a coincidence' relative to its 2007 founding principles, and describes serving frontier labs (research, long-term memory), AI-native companies (he cites 11 Labs running 14 million production agents on MongoDB after migrating off a hyperscaler's first-party database), and enterprises (75%+ of the Fortune 100). He argues for an open ecosystem across the 'three legs of the stool' (LLM, data, hardware) and warns against hyperscaler lock-in. He breaks enterprise agents into employee-facing, partner-facing, and the high-value customer-facing category, noting most enterprises have not yet deployed customer-facing agents at scale. He also covers coding-agent economics (70% of MongoDB's checked-in code came from agents last week), the rising importance of an open memory/context layer, and the disruption risk to seat-based and horizontal SaaS as software moves beyond UI.

Key Points

• MongoDB founded in 2007 on three principles: a modern document model for agility (not bound to rows/columns), commodity hardware/scale-up architecture for the cloud, and best-in-class handling of unstructured data; CJ notes being the best database for unstructured data and AI was 'almost a coincidence'
• Customer segments: frontier labs use MongoDB for research/training data and for chat conversations and long-term memory; AI-native companies; and enterprises, including 'most of the banks' and Adobe products
• 11 Labs migrated off their hyperscaler's first-party database (which 'didn't scale') to MongoDB and now run 14 million production agents; CJ cites their voice modality, ~$500M ARR, and 74 languages
• CJ buckets enterprise agents into employee-facing, partner-facing, and customer-facing; he is most excited by customer-facing agents at scale, and a large insurance company with 50M+ customers had only employee-facing agents, blocked by stack uncertainty, regulation/governance, and the need for rock-solid evaluation before production
• Coding-agent economics: last week ~70% of code checked in across MongoDB's ~2,000 engineers came from coding agents, producing ~35% more code; engineers spend only ~20-25% of time actually coding, so cost (human + token) is up but output is more features — economics must improve to be sustainable
• Argues the harness layer should be open and not locked from harness layer to data layer by labs or hyperscalers; supports an open standard for memory tied to MongoDB's launch context around Context Hub and open memory
• Frames memory/context as a growing 'system of intelligence' layer that must deliver high-speed, real-time data for customer-facing agents in airlines/banks/commerce
• On SaaS disruption: signing only one-year deals, seat-based model 'does not work,' wants to cut SaaS vendors and build internally; vertical and vertical-functional SaaS are more defensible than horizontal/UI-layer SaaS; advises startups to adopt a platform mindset where multiple use cases compound

Notable Quotes

So we are like the best database for unstructured data and AI. And it's almost a coincidence.

now LLM is the bottleneck, not the harness of the data layer

if you just look at last week, for the engineers, and this is what a large sample size, like, you know, closer to 2,000 engineers at MongoDB. If you look at last week, 70% of the code that we're checking, was given by the

Full Transcript

Show the full timestamped transcript (auto-generated; lightly cleaned)

[00:00] What's not working and I'm looking forward to digging into that and much more with them. So let's
give a warm welcome to CJ. Thank you. Absolutely, absolutely. Thank you. I was really surprised.

[00:30] And you guys can hear me okay? 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 virus like that. We'll keep you around for a little bit.
That's great to hear. So I think, I'm assuming most people in the room are pretty familiar with
Mongo. I used to have a lot of my old job at Robust Intelligence. Our entire staff is built there.
It's obviously been around for a number of years. AI has, and this means a lot of people, has a lot
of experience with AI. And you think it's popped up for,

[01:00] and the new type of AI has popped up in the past two, three years. How has Mongo thought about
what's worked in this AI era for biggest Mongo? And has Mongo had to add more things to make it
better for this eugenic era, better for AI? Yeah, so MongoDB, you know, I would say started, of
course, as an open source database company. And that's why we love partnering with 99% of the AI. So
we didn't change because we have similar

[01:30] equals philosophy on how we build products. What we put in our open source version versus our
enterprise version. But the company was created in 2007. And the founding principles were very, very
simple. The founding principles were you need a modern database that is not bounding to by rows and
columns and we can go fast as you applications. So agility was a very important design principle
with document model.

[02:04] Second is commodity hardware and scale-up architecture, because AWS was just coming online. So to
build in the cloud rather than a scale-up architecture. And I would say the third thing is probably
the best database for unstructured data, right? And most people look at it as a document model,
based on things like that. And coming to your AI question, AI is all about unstructured data. I
mean, even if you use your popular GPD version or whatever it is, you're creating an image,

[02:40] I send DocsUp saving links to my kids by creating something, and you wouldn't store all this. So we
are like the best database for unstructured data and AI. And it's almost a coincidence. That is not
what was created by the founders of the organization. So it's a big job. And then the last thing I
would say, or your question is, what we added is native search and record search, so hybrid search.
And that's where we both have partnered, so that you can easily retrieve something.

[03:11] And we added embeddings, not to get, you know, OAJIT right here in, you know, Stanford. So that's
what we did for AI workloads. So that's it. One of the things that I found really fascinating, which
I think is really interesting, is that you have a lot of different types of data. And I'm going to
spend a minute with you, is the different types of companies that are using different types of
things all under this umbrella of AI. There's, you know, there's startups, there's enterprises,
there's the labs, and they're all using each other for slightly different things. Did you talk about
that and share the trends that you're seeing in terms of this?

[03:44] Yeah, so just one thing is I'm obsessed about speaking to at least 10,000 people. And I've done that
for pretty much my entire career. So if you think about how many customers, interest customers I
speak to, and learn from them on what's going on, that is truly something I like to do, so that you
understand what's going on, what's really working, how things are changing, whether it's cloud, AI
landscape, and so on.

[04:14] So for MongoDB specifically, we found out that frontier labs use us for different uses. So that's
one class of very unique class of customers. And success from frontier labs, you can count them on
fingers. Some of them are using us for research. Just think about research, training data, lots of
unstructured data. You put PDFs in, voice, et cetera. So they use MongoDB for research before they
ship their 4.x, 5.x, whatever model they ship.

[04:52] There are some. Some of the frontier labs, we are using us for interesting, chat conversations,
long-term memory, you know, what kind of searches I did, and all that kind of stuff. And then we
have AI-native companies. Last week, with their permission, we announced that 11 labs, so they are
building a particular type of data. They made this mistake, and I'm just going to say it. They made
this mistake of using the first-party database

[05:23] from their hyperscaler. It didn't scale. And these guys are creating, you know, their superpowers
text-to-speech. They were created post-PET-QPT era, and they do small language models for text-to-
speech and speech-to-text. And once they moved to MongoDB, they have now 14 million production
agents built on MongoDB. So AI-native companies, they take 500 million ARR. I mean, it is insane how
fast they are growing, and they focus on voice as the modality,

[05:55] and for customer support, those kind of use cases or sales. And the last is enterprises, where we
have worked together. Enterprises will say, hey, CJ, we are using for this orchestration. By the
way, my team wanted me to tell you, we use and we have agents, and we are very, very happy. So thank
you. And we are building lots of agents, lots of agents internally for use cases. So enterprises and
the classic enterprises,

[06:27] we have most of the banks that are mission-critical, workflows, payment types, tech companies are
built on MongoDB. Adobe, for many of their products, is not constructed data. Those products are
built on MongoDB. So we go all the way from maps to AI-native to management. Let's maybe talk about
our integration together. So you have a really nice way of putting it. You talk about the three legs
of the school, the LLM, the data, and the hardware.

[06:58] Can you walk through that and talk about how all those relate, and then maybe talk about some of the
stuff that we are doing together to make that more seamless? Yeah, so first time I met Harrison,
because the teams told me, engineers, you know, or developers, builders, when they work together,
even the very similar design principles we have, what we build products, open source and all of
that, is this was not a top-down integration between Langstain and MongoDB.

[07:29] It's that engineers were asking for it, whether it's vector search, hybrid search, you have long-
term memory store, graph rack, lots of things. So those integrations were built even before this
partnership was formed. So it was bottoms up, and we are similar to Langstain, extremely developer-
friendly. So if you want something, we want to do it. An example of AtlasDB hybrid search that we
did specifically for integration with Langstain,

[08:02] it is something that just makes sense that in the harness layer, if you are doing a retrieval of
vector search, you should make it easy for the developers to do that, so they can use our data
store. So I am a firm believer, that the harness layer is one in the open ecosystem, because given
the labs, we'll ask you to build a harness layer on top of them, and I've seen some announcements,
right? Hyperscalers will also try to lock QA

[08:34] all the way from harness layer to the data layer that I was talking about with 11 labs. And I think
that if you want a full open ecosystem for all of you, to be able to say, you want to work across
any models, across any hyperscalers, as you see, even last week, the announcement with and probably
using facilities, on-prem facilities from SAI, which also tells you that multi-cloud is very, very,

[09:04] because of capacity constraint. So the data layer is there to stay, elements are there to stay, and
when you want to create agents, you want a great harness layer from it. And I think this, yeah, this
trio of things fits really nicely together. We've done a bunch in the open source. If you'd be so
much in the open source, which now we're trying to make more common and build into Langsmith, build
into Langsmith deployments. A number of customers are already using it together. I think you already
mentioned Adobe.

[09:34] At one point, did you really talk about the things that they're doing and how they're using some of
those things? Right. So Adobe had a lot of unstructured data, has a lot of unstructured data. They
have been many products using MockerDB. So, Adobe Experience Manager, and I can go through many of
these because they have, they provide what they call digital experience, or Experience Cloud. And as
they were building agents, they're saying, okay, if we are using LanChain, I'm not going to get on
this from LanChain,

[10:04] can we make sure that the retrieval is super fast? And by using LanChain products with us, now they
are saying, the senior software engineer who has built this agent, the player, the comment from that
engineer was, now LLM is the bottleneck, not the harness of the data layer. And for me, that's the
thing, that we want to make agents really work. You see, agents are slow. And they don't give you
accurate answers.

[10:34] What's the point of doing all this? You talked about kind of like the model labs and how they're
using you to start up enterprises. I'm curious, in your view, in the long run, will, will they use
pieces to start to look more similar or more different from each other? This is one area. So when I
meet all these customers on a regular basis, I ask a very simple question. I say, because if you
think from a customer's perspective,

[11:05] they are trying to have agents in three buckets, I think that would be. Bucket number one, employee
facing. All these co-pilots, 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, I'll research, whatever. So
this employee facing. I'll tell you as a CEO, when people say that, hey, I built an agent that's
employee facing and maybe giving me 500% productivity,

[11:36] it's very like, eh, that's over. Great. Thank you for building it. But that thing gets me excited.
Then you have maybe partner facing. Oh, we created this agent partner facing, and we have multiple
partners, we have this type of a company. And then last, super important, is customer facing. And
the question I ask is, have you created customer facing agents at scale? And now when you talk to,

[12:07] I was with a very large insurance company that uses CallerDB, and they do not. It's a simple answer.
They have a lot 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 that they want
us to use. Okay. Then we have all the policies, different policies, and all that data in CallerDB.
And then we are trying to figure out which models to use.

[12:40] And CJ, if we are going to approve somebody's insurance, or somebody's claim, we do want to run in
the loop. So the agent can do multiple things right away. If it's fully customer facing, they have
50 million plus customers. And then, when we roll out the product 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.

[13:10] And I asked them, I was trying to be funny, but I didn't laugh. I didn't laugh. Is that, I said, how
annoying must it be for you, that you have insurance agents who are humans, and then everybody comes
and tells you about building agents. Do you not get confused? I've heard this before many times. But
if they can create those agents, that can provide an insurance claim, have a dependent, or a driver,

[13:40] or whatever the case might be, change the claim, that's the high part of it. And they can even
create new products that are truly customer facing, that changes entirely how the CEO thinks about
agent evolution for that 50 million plus customers. And just to make sure I understand, is the
blocker for that the LLM capabilities, or just the confidence that they have in the system, or the
regulations they encounter? So the first I was telling you,

[14:10] and I'm sure all of you face this every day, is what agentic stack they should build up. There's so
much changes happening. Hyperscalar, they use one particular hyperscalar, they're economical people,
they're hyperscalar for mobile people, and they are coming up with this opinion, and they're like,
should we be locked in, or should we look at something like a line chain, should we try to have a
particular frontier model, or for some agents, I should use different models.

[14:40] They are experimenting, but things are moving so fast, that they don't know what to think, so that's
number one. Number two, because they are an extremely regulated industry, that is them or me, how do
you do the actual, can you replay, do this insurance thing, do you discriminate with the agent, so
all the governance, security, or, while I was going back and forth asking questions, to get my
policy, with the agent,

[15:10] what does that mean, and how do a human answer, do they do a AI call, and voice call agent call,
these are real problems, that we're dealing with, and then plus, You mentioned the agent staff, and
all the choice that can come with it, and it's, Yeah, and so I'm curious if you think about this,
because you talked about this, this voting staffing, you can see the people system, but when you do
that, there are so many different choices,

[15:40] and I think, and it's all changing, and so I think that presents a little bit, almost like paralysis
of what to do, and what to choose, so how do you think about getting people, kind of like, a happy
path, yeah, production, while maintaining that optionality, and that other thing? Yeah, the thing
is, you know, these customers, the large enterprise customers, that's what we serve, so for example,
it's in 75 plus percent of Fortune 100, so we get these customers all the time,

[16:11] and the biggest challenge that I'm seeing, in medicine, on that point is, they thought 2025 was the
year to create agents at scale, for them, to create the agents at scale, that didn't happen, for
these large enterprises. Now in 2026, they are feeling that some of the technologies that are
observed, that we use to be storing, some of the technologies that are applied, some of the
technologies that our partners are using, yes, everybody wants to play in that,

[16:42] but they feel those technologies are enduring, and where they are coming, they're a healing team,
from AI, life cycle development perspective, let's just move it next, do rapid integration, and
figure out if this works, and then we can be moving out in production, so 2026 is a little better
than 2025, 2025, I mean, this customer only, I'm sure you guys have heard this before, the number of
agents, or agent washing, as they call it, was crazy in this large account,

[17:12] and they are like, hey, you know, CJ, I wash my agents more than I do laundry, that's TMI, but the
point was that it was just, disrupting very fast, so I think that in 2026, it's not going to stay
that way. One of the things that I think comes with more agents is more token spend and more cost,
and I think we've seen a bunch in the news recently about, in particular for coding agents, about
cost of those companies to drive in, how are you seeing, whether it's inside Mongo,

[17:42] or inside the companies that you partner with, what are you seeing around there, how are people
thinking about that? So I had my board meeting that week, and Devon asked me the same question, so
let's see if this works. So we rolled out one of the coding agents, and we had an engineering team,
you know, Alshed just knocked Ben Schwartz, so one of the things that we are really trying to
understand first, in an engineer's,

[18:13] what percent of their time, they actually do coding, and is that now accelerated, because of coding
agents? The answer is yes, right? For us as a database company, and you know, it should be technical
engineering team as well, for us as a database company, distributed system engineers, the coding
time is actually 20 to 25% of it. There's a lot of other things they do, code review, I can go all
of that team meetings,

[18:45] to make sure the design and some systems work well, and so on. That we don't have to drop. So if you
look at the numerator, the amount of code that is getting produced, is now more, because we are
using coding as a system, 100%. And then when you look at the denominator, on the productivity, you
are saying, okay, out of eight hours that the engineer actually used to code, out of 40, maybe now
we are saving five to six hours, okay,

[19:15] on maybe three or four hours. So that's the math right now, but then I'm seeing the token cost,
going down significantly. So, what I'm trying to figure out is, okay, here's an engineer that is
producing more code, so that's great, but now my cost of that engineer, that engineer has increased
on the tools she's using. So, to put that together, to present it to the board next week, is, the
cost has gone up,

[19:45] but what is the output? The output is a lot more features, more products, which hopefully we can
sell. So we are innovating faster, but it's at a higher cost factor, okay? And that economics has to
improve, otherwise it's not sustainable. Have you thought of like a, token budget per engineer, or
is it getting to that, or are you switching to that? Here's one thing, that if they are, so right
now, I asked the team, last week,

[20:15] so if you just look at last week, for the engineers, and this is what a large sample size, like, you
know, closer to 2,000 engineers at MongoDB. If you look at last week, 70% of the code that we're
checking, was given by the . That was it, okay? Okay, that's great. So, it kind of scares me a
little bit, because then I'm like, okay, once that token build in, it's pretty high. So, and it's
then because they are not writing prompts properly, and then whole engineering around it,

[20:47] but we'll figure that out. But that cost, but if they're producing 35% more code, so that we can get
additional features of products, like some of the products you announced yesterday, I'm okay with
that. But then I have to really figure out, if next year I was going to have 30% more engineers, do
I really need to do that, right? Because now my engineers are pretty good at their own thing. So,
that's why I'm looking at the cost, human cost, the token cost, and what does that really mean.

[21:18] One of the things we announced yesterday was Context Hub, and along with it, the open memory kind of
like partnership to figure out what a standard for memory might look like. What, what do you think
memory for agents will look like? And I'm assuming the answer is yes, but like why do you think that
standard needs to be open? So, this idea, I think, I understand how it's kind of blocked today.

[21:49] System of intelligence, right? There was always a system of records, system of action, this, that,
or system of intelligence. And with agents, agents are a system of intelligence. Now, the question
is, anytime you want to create a true agent that is customer-facing, your data layer, artists become
super critical besides the LLM, or LLM, or SLM. So, from my standpoint, Harrison is that,

[22:19] I think of the system of intelligence, and when you look at the memory of the content, that layer
could be a lot bigger than we think it is today. So, I think that the data layer needs to have right
context and memory, so that the agent can make real-time decisions, and spend real time. I
absolutely do not believe that these are the kind of things that you can build on top of a data
layer, because data layer always created as a 15 minutes later,

[22:49] 30 minutes later, where you can ask these questions. What is the situation? Is customer-facing,
airlines, banks, will make decision fast? So, this context, plus memory, is going to continue to
become bigger, become super relevant, and will become some high ground, by which agents will provide
the outcome for everything. You say this context and this memory will grow bigger. What will help it
grow bigger? Like, how can enterprises start to grow this context layer,

[23:19] start to grow this memory? What are the blockers there? Is it a technical thing? Is it an
organizational thing? I think that it's definitely a technical thing, because people are, how much
data, what do I need in that context slash memory, so agent can make an outcome, mortgage rate, real
time bank, or transaction, or something like that, in agent in commerce, or something like that. You
need like really high speed answers or actions that you take. And for that requires always lots of
data.

[23:50] And you have that data in particular public short for memory, memory and context. And every
enterprise that we speak to, that they are trying to create agents, every single enterprise, that
comes from so many data sources. Then how do you really build that? And this whole way of doing
software via UI, right, the neuronal is over time, you're the agent, you're the context layer, and
you're done.

[24:20] Okay, so on that note, yeah, software via UI, I feel like one of the things that has been talked
about a lot recently is, is it's had us big guys, basically, you see Salesforce doing this, it's a
great example. Where do you think that trend goes? And how are you as Mongo as a company leading
into that? Yeah, so I would say first thing that we are doing right now is, in all of these
companies that sell to us,

[24:51] right, we are only signing up, CI is fantastic, very technical. We are only signing one year ago.
Because this whole way of doing seed-based model, right, I mean, you see what's going on right now.
And investors ask me, hey CJ, are you going to check your CMO for ED? It's a question on multiple
fronts. But, the thing is,

[25:21] how many people do we need to hire more? From the day I got up here, and so on, so on. So one is we
are signing one year ago. Second is the seed-based model, this does not work. Because I just don't
know how and when I'm going to hire the two or the other three, so long term contracts are gone. And
then the second thing is, I've asked my CIO that I want to cut. We have, say, X number of SaaS
vendors we are using, or financial,

[25:51] CI, whatever the case might be. I'll look at that again. And I want to build things internally.
Because if I have the right context there, the right orchestration, you know the data layer, what's
the good, what's the bad, why do I need to pay all this SaaS? What SaaS companies do you think are
in a good position to survive people thinking like you are right now? And which might be a good fit?
I'm not going to answer that question.

[26:22] But from my standpoint, I think if you have vertical SaaS, then you have a lot of domain expertise
that can be built in for life sciences, insurance, and all that. I think that is a defensible move.
Then you have a vertical SaaS. Or then you have a vertical functional SaaS, with what we call in the
background, companies like that. That is definitely a move you have.

[26:54] On the horizontal SaaS, my standpoint is, if you are at that UI layer, or another layer, where
there's still grab you add, you know, you're in UI, you are at a higher disruption risk, versus loss
of data in system of record, that is very problematic. Is that also where you, the vertical nature
thing, is that also where you see, a lot of the advantage for startups coming? For all the startups
folks in the room,

[27:24] who are thinking of building in the space, would you advise them to find a vertical and build into
it? Or what other advice would you have for that? Yeah. You know, here's my thing. So, we use a
vertical AI native startup. And every time I meet that firm, I ask them this question, what is your
real goal, on top of the foundational model? What's your real goal? And it's interesting. Sometimes
they will say,

[27:54] hey, we have all this knowledge, of this particular industry, that has been built into our product,
on top of the element, if you see. And then we have this forward engineering team, that will come
and get you to value, not in months, but in days or weeks. And that's our goal. That's an okay
answer, not a great answer, right? To be able to say, because then I worry in the background,

[28:26] 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, okay, I understand what you're saying, and I
respect it, obviously, you guys are working super hard, but I'm going to only sign with you for a
year, because I want that vote to be clear. Otherwise, it doesn't work for us. What do you think is
a good move for a JNI? I think you should have multiple use cases,

[29:02] and those multiple use cases need to work with each other. What's the example? So the example is,
you should have a platform mindset. So say you are doing a use case for finance, and you're doing a
use case for HR. You're doing a use case for HR. So you're doing both, and there's a pattern that
works really well for the industry that you sell this item, whether you're like, or like, you know,
so on. The things that you provide should work with each other. If I buy one product from you,

[29:32] okay, it works well, gives me 40% productivity, whatever it is. I buy the other, it didn't take
product from you, it gives me 20% productivity. But if I combine the two, it is one plus one is more
than two. And you become a platform that I use, that works really well with each other, for me as a
customer. That's the high ground. I feel like there is this idea of startups as a big bro will
always become a popular thing, big bro, and live long. Do you think that's happening earlier than
being a young man, or faster, or?

[30:03] I have not seen it yet. I have not seen it. And I think that is the opportunity that you have,
because everybody, our IT team, our tech team, that all the thing that I'm supposed to say, the
question I ask, and to ask the members themselves, is if we were starting today, would I buy this,
and why? And do you have anything else that I can apply? So, right now, a lot of the very simple use
case, but like even coming back to 11 Labs last week,

[30:36] when you speak to my team, they say okay, voice, meaning speech to text, the clear use case was
customer support. But it could be six, it could be other things, and now you become that backbone
that I know how to create, and I build the next page, and then I have a practical cost, say for a
mobile IT team, and then it works. And for them, at 11 Labs, that common thing is voice. Voice
becomes the goal, and they're very, very good. I'm 74 languages,

[31:06] and they told me this story that they were created because the founders are foolish, and they saw
really bad news, and they saw a Hollywood movie, and they all said, well, they should end up like
this, that's what they saw. All right. I guess we need to make a lot more poorly dubbed movies so we
get a lot more 11 Labs. Thank you so much for joining us today. Thank you. Hey, man, how are you?

[31:46] Yes, I am good. What have you got today? Oh! It's the arm. Between? Who? It's the arm. It's another
one. So, yes, it's the best. It has two albums, and the reason why I'm here, I'd like to share two
more bands with you. I'd love to. Have you ever heard about Tigran? Say it again? Tigran. He's from
Armenia. He's a pianist. Thank you so much. So, thank you very much for coming today. Thank you. So,
this is the band, this is the battleground,

[32:17] but he has this jazz trio.