An AI Application Is Still an Application

Sonya Huang and Pat Grady welcome Sahir Azam, who leads product and growth at MongoDB. He was one of the architects of the company's move from on-prem software to the cloud, and he is now steering its AI evolution. Huang starts with the big picture: is AI going to change the database market? Azam moves the question up a layer. The more interesting issue, he says, is whether AI changes software development itself. He thinks it does. Generative applications are going after use cases that traditional deterministic software never reached — the trend Sequoia has written about as services-as-software. That changes how people interact with programs, how business logic evolves with agents, and, underneath all of that, how the database layer has to transform.

From MongoDB's seat, two shifts are already visible. It is much easier and more efficient to create software than it used to be, so there will be more software in the world, and more software means more data to persist and process. The other shift is interaction. Beyond classic web and mobile apps, Azam sees the blending of physical and virtual worlds, a large trend in robotics, and what a recent LangChain post called ambient agents: programs that react to signals without intentional human action. He thinks we are at the very early stages of a top-layer change in human-computer interaction, one that can improve personal and professional productivity in ways traditional software never did.

The most sophisticated examples tend to show up first in risk-tolerant startups. For that reason he picks two enterprise cases. A large European automaker has huge global fleets and a network of first- and third-party mechanics. When a car makes a funny sound, a skilled technician used to tinker for hours, then hunt through a manual for parts and repair steps. MongoDB helped them find an audio embedding model that records the noise on a phone and semantically matches it against a corpus of known failure sounds. Diagnosis that could take hours now takes seconds — almost Shazam for car diagnostics — and a natural-language interface replaces PDFs and paper manuals for the next step. Across thousands of dealerships and hundreds of models, Azam says, that is millions of dollars of potential savings, plus a better customer experience and stronger brand sentiment.

The second case is Novo Nordisk, one of the largest pharmaceutical companies, in a heavily regulated industry. A clinical study report, required for drug approval, typically takes a great deal of manual writing, structuring, and review. The company trained a large language model on its approved drugs and internal process. An initial CSR draft now arrives in a few minutes, and Azam says the quality of that first draft is higher than what they typically saw from manual work. The point of both stories is not bleeding-edge technique. It is AI dropped into a setting with real scale and a line you can draw to dollar ROI.

What does a multimodal, agentic, sometimes ambient application mean for the database? Azam is excited, for two reasons. If generative AI makes more kinds of software experiences easier to build, that is a macro tailwind for data-persistence infrastructure. It does not automatically accrue to MongoDB or any other vendor; a lot of execution on technology, partnerships, and ecosystem still has to happen. Early chat-with-an-LLM apps did not need advanced persistence. Enterprises that want to ground answers in proprietary information, and to control retrieval quality, need a lot of interaction between foundation models and how the business actually runs. Much of that information is not publicly trainable on the internet. As models get lower latency, they will interact more with real-time operational data. The most advanced companies are already building sophisticated ways to control LLM output and merge it with the data that drives the application.

The opportunity he cares about most is high-quality retrieval of unstructured data. Embedding models and probabilistic software take the value sitting in 70% of the world's data — documents, recordings, images that applications could barely use — and make it applicable. Grady plays devil's advocate with Jensen Huang's line from Sequoia's first AI Ascent: every pixel will be generated, not rendered, and rendering sounds like retrieval from a database. Azam hears a different objection. The question is less whether a database exists behind the scenes than where the abstraction sits: a choice the application developer makes, something hidden behind an API, or a choice an LLM makes as it auto-generates software. Internally they joke that an AI application is still an application. You still persist transactions safely so people's bank balances are accurate. You still need keyword search, not only semantic match. Generative needs at the data layer are additive, not substitutive.

Huang fast-forwards the clock: hundreds of millions of human developers, and trillions of agentic developers. Why would an agent choose your database? As applications move from simple generative features to agent-driven business logic, Azam says, state becomes more necessary. You are coordinating a complicated workflow, tracking pieces of a transaction, storing and updating results over time. Generative applications are becoming more stateful, which is a drag on database consumption. On abstraction, early AI-generated software already shows a preference for great developer experience and higher levels of abstraction — Vercel v0, Replit, and similar platforms. It is too early to be definitive. The signs are promising. Grady offers the line that English is the ultimate layer of abstraction: at the limit you describe product requirements in plain language and a foundation model spits out the code. Azam is confident that is a tailwind for databases in general. MongoDB's specific bet is a data model already tuned for structured, semi-structured, and, with embeddings, unstructured data, whether the software above it is written by a human or a machine.

They are not resting on that. MongoDB is integrating with AI frameworks, inference players, and model providers the way JavaScript, Web 2.0, and cloud were tailwinds before. They are also working on what Azam calls SEO for LLMs. Scraped internet code is not necessarily MongoDB best practice, and there is no standard way for a vendor to submit canonical training data for high-quality Mongo code. They are working with labs on methodologies, and building datasets on their own, because the last thing they want is a developer asking a model for MongoDB code and getting something that performs poorly. Huang asks whether, with public data hitting a wall, MongoDB becomes a training-data provider. Azam draws a hard line: customer data is owned by the customer. MongoDB is not training models on it outside what that customer wants, for RAG or otherwise. What he sees instead is a mix: simple RAG on operational data and metadata; vector adoption that merges metadata, transactions, and semantic search into one system, which is where he thinks the market is going; and some customers fine-tuning or training smaller, use-case-specific models. There will not be one modality. Customers will optimize for latency and performance on their own terms.

Sequoia regularly polls its portfolio on AI stacks, and Huang says MongoDB is consistently the number-one vendor people check for vector databases. Azam adds that vectors are MongoDB's fastest-growing new product area. Huang's question is whether people are using an old semantic-search technology, born in e-commerce, and shoehorning it into information retrieval for LLMs, or whether vectors are the ideal knowledge infrastructure. MongoDB had a vector capability before ChatGPT, but not as a standalone category. A few years ago customers were running MongoDB as an operational store beside an inverted-index engine for full-text lexical search, and copying data between them. The developer-experience answer was to put both indexing modalities in one database. Advanced e-commerce customers then asked to blend lexical search with semantic similarity. That is what pulled MongoDB into building vectors into the engine. After ChatGPT, they poured gas on it and expanded integrations. RAG is a different use case than pure semantic search. By 2025, Azam says, the most advanced customers want all the modalities together: metadata filters on unstructured data, keyword relevance ranking, and semantic meaning from embeddings. Only then does the application get the quality and predictability a large enterprise, especially in a regulated industry, will trust in front of customers.

Having those modalities in a single system is the advantage. Otherwise you end up doing what Azam calls RAG gymnastics: tying the pieces together in application code. It is possible. It puts a huge burden on the development cycle, and you need a pretty sophisticated team to figure it out on your own. MongoDB's goal is to democratize that for the average application developer. Huang asks whether vectors and graphs are substitutes or complements. Every week, Azam says, there is some new approach to higher-quality retrieval. He sees them as complementary. Graph relationships encode understanding you may not be able to infer from embeddings alone, the same way pre-filtering on metadata is additive. The product philosophy is to make it simple to combine graph representations, metadata, transactions, and vector search so a developer does not keep those objects in four different databases and then try to rationalize them.

Is it fair, Huang asks, to think of the LLM as the brain and the database as the memory? Azam says that is one right way to think about it, especially as agents run more complex workflows across multiple endpoints instead of a one-shot call to a single model. You have to persist memory and state. He treats them as two pieces of an emerging architecture. Compute, storage, and networking remain the under-primitives. Foundation models go after probabilistic work that used to belong to knowledge workers. That work still has to store state, stay grounded, and interact with the transactions and structured information the application is driving. Those pieces together create the end-user experience. It is not either/or. As LLMs get lower latency, the database is not only memory. It is a reflection of world state, and the model has to interact with what is happening in the business in something closer to real time.

Grady takes the architecture one step further. For anything deterministic, you want the traditional database world. For anything probabilistic, you want something that looks like an LLM. Are the API businesses of OpenAI and Anthropic occupying a similar layer to MongoDB — on top of the public clouds, beneath the application? Azam finds it an interesting proxy and rejects a neighboring slogan. “The LLM is the new operating system” never felt logical to him. What he sees is side-by-side complementary components serving the business logic and interaction layer above. Language models can now reason and provide human interaction that was not possible before. In any architecture he has seen, that does not supplant deterministic outputs from structured data, transactions, and search. It is still early. The next generation of business models is not obvious yet, which is part of what makes the seat interesting.

Will AI leapfrog from vectors to some new data structure, or is this the architecture? Azam thinks vectors, as far as he can see, are strong primitives that hold. He is open-minded if something else comes along. He does not treat a vector database as a segment that will replace core databases. It is a primitive: if you want to manage unstructured data, the ability to index vector embeddings, combined with high-quality embedding models that represent meaning, is a new foundational element, like text indexes or B-tree indexes. He does not see that going away. What is still violently evolving is how you create high-quality results from that data, how good the embeddings are, and how you augment them with other information. That is not settled. There is plenty of room to make storage more efficient, performant, and cost-effective. The more interesting problem, for him, sits above the bytes.

A line from Ben Thompson at Stratechery is what got him thinking. In a world of probabilistic software, the measure of quality is the last mile: how you get to 99.99% quality, and whether the quality engineering we associate with manufacturing starts to apply to software. You will not get a deterministic result the way a traditional application talking to a traditional database does. Quality therefore depends on the embedding models, how you construct RAG architectures, and how you merge them with a real-time view of the transactions in the business. That is what produces high-quality retrieval. Unless it is high quality, in a probabilistic world, Azam does not see it going after mission-critical use cases in a conservative enterprise. That is the problem space MongoDB is focused on right now.

Reasoning models, in his view, are another tailwind for databases. Whenever there is reasoning, memory comes into play, along with long-running logic and more advanced agentic workflows. All of that needs state. Databases matter more there than they do for a one-shot answer engine. As an end user he is fascinated by the current wave, and not only as a novelty. Google’s Gemini Deep Research, and the product experience around it, is one he finds amazing. He thinks there is a lot still to do in the user experiences and use cases that applications can build on top of reasoning, beyond what the first wave of LLMs was able to drive.

Grady turns to Azam’s other job of record. Azam architected MongoDB’s move from a traditional on-prem enterprise software business to a cloud-native, consumption-based one — now most of the company, at billions of dollars of revenue. Few companies of that scale got the on-prem-to-cloud shift right. Grady wants the playbook because a lot of enterprises and startups now face a similar non-AI-to-AI transformation. Azam keys off Grady’s language. Business transformation is the important phrase. Many companies treat this kind of move as a new SKU, a new product to worry about. He took it as a transformation of the whole business, which meant every functional leader had to understand they had an important part, and be accountable for how customer success, the financial model, and every other function would work in a consumption-based, cloud-first world.

How do you get buy-in when the thing generating all the revenue is not the new thing? Strong top-down support, first. It was very clear that launching Atlas and making the transition was a super-critical business priority. That included empowering Azam to knock on peers’ doors and ask for headcount on the cloud side — shuttle diplomacy rather than direct authority. Just as important, they did not treat Atlas as a separate mini business unit isolated from the core. They wanted every functional leader to feel part of the transition, not as if they were going to lose a piece of the function they ran. That is how you avoid a starved new initiative in a corner, which is how he has seen these efforts die.

On the sales side they rolled up their sleeves and became sellers. The product team sat in the early deals, learned the objections, and sorted which ones were roadmap gaps, enablement problems, positioning, or pricing. Azam used to make the rounds every evening in the smaller New York office: what is happening with this deal, what help do you need, what are you hearing. The point was that sales was not being asked by a stranger to do something because it was important. He was in it with them. They also put SPIFF incentives, heavy enablement, inspection, and accountability behind the new motion until momentum could neutralize the inertia of a growth business that already knew how to drive revenue the old way. They did not want to artificially push an on-prem customer to the cloud if the customer was not ready. In the beginning, they did need the sales team’s attention on something that did not yet feel like a needle-mover.

Grady’s recap is the advice list: a lot of top-down support, which requires conviction; fully integrated, not a starved project in a corner; a wholesale reinvention rather than a SKU. Azam adds that some of the most important work was not a technology decision. It was the business-model shift and sales enablement to a different buyer in the organization. Almost every function had to change in fundamental ways. An outsized amount of time went to things people would not have guessed needed to change that much. Everyone gravitates to the hard-looking part — how do you deliver a highly reliable cloud database, which is by no means easy. The rest of the functions have to line up in a coherent way, and that is where a lot of the attention actually went.

Grady draws one more analogy. Through the cloud transition Azam was obsessed with developer experience, because developers were going to choose the database. For companies going through an AI transition now, it is still developer, developer, developer. Eventually, if trillions of agents are running around, the thing to prioritize might be agent experience. Azam can see that, especially if agents start driving business logic without custom development by the organization. From the outside he often gets asked how MongoDB went from enterprise to PLG, and he always winces. Those motions are complementary. They have more to do with where a customer is in the adoption journey, and what kind of organization it is. A technical-founder-led, fast-moving startup does not want to engage sales at the beginning. A large enterprise is never going to show up through a self-service channel. MongoDB spent a lot of time on the whole system, mapped to how users and buyers actually want to engage. The cloud transition did not succeed by being philosophical about credit-card customers versus enterprise sales. Both have to be cohesively integrated to reach global scale.

Rapid-fire, his favorite new AI apps start with Gemini Deep Research. Perplexity is not new by any definition, but it runs counter to the idea that thin AI wrappers are unsustainable. He sees a lot of product craft in the user experience and design. Models are not suddenly going to make software go away; adoption, understanding the user, and design sense will still matter, including in non-visual modalities. Someone turned him on the previous week to Snipd, a podcast app that auto-summarizes episodes, surfaces key insights in readable form, and lets you take notes. Huang and Grady have been looking for exactly that. Who does he admire most in AI? He will not name names. He listens to researchers who seem to see the future, and he finds it fun to watch large-company CEOs mudsling about systems of record and the agent race — the battle of titans over which incumbents survive the transition.

Agree or disagree: every developer will become an AI engineer? Agree. Traditional machine learning lived in a specialized, centralized ML or data-science team, applied to a subset of the use cases where it could add value. Generative AI, whether in greenfield apps or existing ones, is being owned by average full-stack and application developers. Democratizing that capability across the organization is something MongoDB is trying to do. He thanks them, then adds the caveat that sits under the whole hour. Things are moving so fast that they will see whether any of these thoughts actually hold water. At least the mechanic no longer has to guess from a paper manual.