Beyond the Database: Building the Context Layer for Enterprise AI with MongoDB

Enterprise AI agents are moving out of pilot mode and into core business processes. The constraint now sits beneath the model and depends on whether the data architecture can deliver the context agents need to act reliably in production.

At the Six Five Summit: AI Unleashed 2026, Jason Andersen spoke with Ashish Kumar, SVP and Technical Fellow at MongoDB, for a Data & Observability Spotlight interview. They examine how enterprise data platforms are evolving beyond the traditional database to support the memory, state, and context AI agents need to operate at scale.

Kumar defines “good context” as the combination of real-time operational signals, historical records, and explicit business rules brought together in a form AI systems can trust. Feed a model raw text without that operational grounding, and it is left making educated guesses.

He cites AT&T's deployment as an example. Combining real-time network signals with historical outage data helped the company avoid 3.1 million unnecessary dispatches and save 12 million hours of downtime. Memory carries similar weight. And a top frontier AI lab moved more than 50 billion conversations from Postgres to MongoDB Atlas in four weeks, anchoring hundreds of terabytes of conversational state with sub-millisecond reads and zero downtime, the kind of consistency Kumar says agents need before enterprises will trust them with core operations.

Kumar also points to two priorities among customers seeing the most value from agentic deployments: real-time performance and architectural flexibility. Marqeta, a retail payments platform, chose MongoDB Atlas to avoid cloud lock-in while scaling to millions of transactions across environments.

Key Insights:

🔹 Context, not model choice, decides whether AI agents work in production. Real-time operational signals, historical records, and business rules have to reach the agent in a form it can trust, or it defaults to guessing.

🔹 Fragmented data stacks create measurable risk. Bolting a standalone vector database onto a legacy stack introduces sync lag and latency that becomes a liability once agents touch core operations.

🔹 Memory at scale is now a data infrastructure problem. Moving 50 billion conversations in four weeks to support sub-millisecond reads shows what production-grade agent memory actually requires.

🔹 Deployment flexibility is as important as performance. Enterprises want agents that run unchanged across clouds, on-premises, and air-gapped environments.

🔹 The starting point is consolidation, not another point solution. Building a unified operational data layer ahead of the existing stack gets organizations agent-ready faster than adding more standalone tools.

For organizations still assembling the pieces, Kumar's advises them to stop adding niche vector databases for individual AI pilots. Build a unified operational data layer in front of existing systems, one that generates embeddings and applies consistent metadata and security before connecting to agents through MCP and other standards.

Watch the full video at sixfivemedia.com, and subscribe to our YouTube channel so you never miss an episode.

Catch the rest of the Six Five Summit: AI Unleashed 2026 coverage at sixfivemedia.com/summit.

Disclaimer: Six Five Media is for information and entertainment purposes only. Over the course of this video, we may discuss companies that are publicly traded, and we may reference their equity share prices. Nothing discussed during this webcast should be considered investment advice or a recommendation to buy or sell any security. We are not investment advisors, and you should not rely on this content as financial advice. Six Five Media collaborates with technology companies and industry leaders to produce research-driven interviews and multimedia programming for enterprise technology audiences.

Ashish Kumar:
Hello, and welcome to the 2026 Six Five AI Summit, AI Unleashed. Today we're continuing the data and observability track. I'm Jason Anderson, and today we're exploring how enterprise data infrastructure is evolving to support the next generation of AI applications and agents. I'm really excited to be joined today by Ashish Kumar, SVP and Technical Fellow at MongoDB. And what we're going to be discussing over the next few minutes is why context and not just data is becoming the key to building not only reliable AI agents, but also highly scalable AI agents. So thank you for joining me, Ashish. Welcome to the show. I'm glad to have you here.

Jason Andersen: 

It's great to be here and I'm excited to talk about how enterprise data architecture is needing to change with these rapid advancements we see in AI and how the conversation has shifted from which models we have to use to the trusted context these models need in production.

Ashish Kumar: 

Perfect. And you're the right guy. You've been doing this data stuff for a long, long time. So I'm really excited to dive right in. So what changed in the market that made the evolution necessary? And why is it especially relevant as organizations begin the AI and agentic building?

Jason Andersen: 

Yeah, great question, Jason. If you look back, MongoDB started as a database developers love because it made building apps fast and intuitive. But what really shifted in the market is that software itself is changing. We're moving from this static, deterministic code to these autonomous AI agents that are perceiving, reasoning, and acting on the fly. When generative AI first exploded, a lot of teams reacted by pulling together these standalone vector databases onto their legacy stacks. Pretty quickly, that became an operational nightmare of data sync issues and latency. Organizations realized that in order to run AI in production, You cannot have your vector sitting in one place, your operational data in another place, and your security rules somewhere else. You need a unified platform. And it's not just about running AI. It's about how software is being built. Emergent Labs is a great example of why flexibility matters here. They're one of our customers. They tested Postgres first, but decided on MongoDB Atlas because when agents are building applications, the data model is constantly evolving. See, with Atlas, the schema evolves right alongside your application, rather than forcing you to run migrations every time something changes. That's why we've been able to power around 2 million agentic applications on MongoDB Cloud.

Ashish Kumar: 

You know, it's funny you mentioned about the fluidity of data and how data evolves over time. And it's the attention level we've seen so far on what we'll call the foundation and frontier models has been enormous in this space. But as we're seeing enterprises start to wade into this in a more meaningful way, like Emergent, we're starting to see that it's not just about the models, right? It's about performance and context and really making these things work in a very customized way for those organizations. So when we think about context in general, how do you define what makes for good context? And why is it such a critical ingredient in the mix?

Jason Andersen: 

Yeah, so I think of foundation models as these very brilliant reasoning engines, like the Einsteins of the engineering. world, but without context, they know zero facts about your actual business. And so the way I define good context is pretty simple. bring together real-time operational signals with historical records and explicit business rules into something that can be together consumed by the AI that it can trust. If you feed these models raw text without that operational context, it's just making educated guesses. But when you give it real context, it can actually make smart decisions. Another customer of ours, AT&T, is a great example of this. So they're bringing together real-time network signals with historical outage data, so combine all of that together, so their AI can make better decisions about where repair crews actually need to go. That has physical implications, right? That's real business impact. In their case, 3.1 million unnecessary dispatches awaited, 12 million hours of downtime saved, right? And so when an agent is dispatching physical crews or touching billing systems, you know, bad context isn't just an inconvenience or a minor hallucination, right? It's a massive financial impact.

Ashish Kumar: 

Wow. I mean, so when you start to think about these impacts and you start to think about context as a part of it, one of the things that I was doing when I was preparing to talk to you today was to look at some of the things you've been writing. And Mongo does a nice job of educating the market in terms of the blogs and the research you publish. I know that's a big part of your role. When we get into things like statefulness of AI and memory, which is now becoming a much hotter topic, these things are getting increasingly important, especially as we get towards production-grade applications. When we think about this, how does that drive reliability? And ultimately, how does reliability help organizations adopt or feel more confident and trustworthy of what AI is able to deliver? Maybe it's a better way for me to frame that up.

Jason Andersen: 

Yeah, look, I like to say like an agent, in agentic applications, everybody's building them, but an agent is only as smart as the context it has access to. So an agent without memory is really just an expensive jackpot, right? You're talking about, you know, general knowledge, right? And whatnot. It cannot hold on to a thread. It cannot learn. And agents now need to handle complex multi-step processes. Without memory, it just can't do that. When we talk about state and memory, we're talking about an agent's ability to maintain this continuity, remembering what happened three steps ago, keeping track of what the user was trying to accomplish, and then remembering their user preferences over time. If you want an agent to handle a process that takes three days and requires five different approvals, it has to hold on to that state without dropping the ball. Doing that at scale though, immense data problem, right? That's a core data problem. A great example is one of the top frontier AI labs actually moved more than 50 billion conversations of Postgres and onto MongoDB Atlas in just four weeks to solve this. That's unbelievable scale, right? Hundreds of terabytes of conversational state that has to stay available with sub millisecond reads and zero downtime reported. When you anchor an agent's memory in a database built for that kind of scale, you're taking out the unpredictability. That's how you build agents that enterprise can actually trust with core operations. It has to give you the same answer with the same inputs and something that customers can vouch.

Ashish Kumar: 

Right. I think that's been one of the challenges I think we've seen with customers ourselves in my research is is the consistency gap, right? Is that they're so used to, you know, 60 plus years of deterministic applications, and they're like, well, I want it to be the exact same output every time. Well, you know, that's when you build a deterministic application, but the world isn't as black and white as that, which is where agents have a lot of value, right? So I think it's an interesting kind of expectation reset as well as a technology reset.

Jason Andersen: 

That's right, Jason. This is an exciting time because what we're seeing is… Databases, that's an area that I work in. I enjoy databases. I've loved them for a while. Infrastructure software is my game. What I'm finally seeing is that databases, which used to be these passive entities that people, you write an application, you decide a schema, and then you read and write into the database. They're now getting up-leveled into being part of this application stack. They're directly making orchestration. They're actually determining how your application works. That's the beauty of this. That's why these are exciting times for people like me.

Ashish Kumar: 

Let's take that thread and extend it a little bit. You mentioned a couple of customer scenarios already, which is always super helpful for people who turn into these sessions. When you're talking to customers or when your team is talking to customers, what's exciting them the most in terms of what they're getting? You mentioned cost savings a few times and deferring bad service calls, In terms of where organizations are getting the greatest value from great context, what's getting them excited when they're coming back saying, I love this stuff and here's why?

Jason Andersen: 

Yeah, I think for the longest time, I say longest, all of this has been developing over really the last 18 months, especially with the genetic AI that's coming in. What we're seeing though is that companies are now starting to move past the science project chatbots and building agents that are driving real operational value. I've talked to perhaps 100 odd customers over the last nine months, MongoDB customers that are building these applications. And as I talk to them, I'm realizing that they're bringing these agentic workflows directly into their core mission-critical business processes. And the organizations that are seeing the most success are the ones that are focused on two things. One is real-time performance, and the second is architectural flexibility. On the performance side, it's all about sub-second responses. Essentially, you now have this army of agents that are going to be accessing this data. They're going to be accessing conversational state, conversational history, memory, enterprise context. They need to be able to do semantic searches, full-text searches, and access this on live operational data so they can operate with current. They need to operate instantly, so they cannot deal with historical data at this point. And so being able to support this massive spike in reads and writes in real time is something that an operational data layer can provide, right? And the second piece is this idea of having a flexibility of deployment, right? And that value is equally important, right? So one of our customers, as an example, Macri, is a great case study for why this matters. So they built this retail business payments platform that needs to be always on, and they didn't want to get themselves locked into one specific cloud provider. MongoDB Atlas, as you know, our ethos is around providing that open, flexible environment. So Atlas gave them that portability while they scaled to supporting millions of transactions. At the end of the day, whether you're running payment systems, autonomous agents, the value eventually comes down to resiliency, fast throughput, low latency, and the freedom to run wherever your business needs to be. And especially, I talk to a lot of customers. Many of them, as an example, have pinned themselves, have decided that they're working on one cloud. But when I talk to them, they realize that agents now need to run close to wherever the data is. Their data, they might be working with customers that run in a different Cloud. Now they need to run the agents over there or they might have applications that need to run on-prem, perhaps in an air gap network. They need to run the agents there. You don't want to write the same agent functionality three times. You want to have the same agent run unchanged in all these environments. That's the power of having this complete flexibility and openness.

Ashish Kumar: 

You know, it's an interesting point because there's also, you're starting to see the notion of data sources changing in terms of, you know, you had kind of internal data, that kind of data maybe you shared with a trusted partner, but now people are going and getting data from say, you know, say Google Maps, photographic sources to do things. I just heard of a case where a waste management company was looking at dumpsters just to see the sticker, to see who the competition was, right? So they'd go into a town and they would just scrape data for maps. I mean, that's an absolute hybrid case, right? Because that's just publicly available stuff. So there's a lot going on there for sure, for sure.

Jason Andersen: 

These are exciting times, Jason, for sure.

Ashish Kumar: So let me just ask you a final question. People are starting, to your point, it's exciting times, right? And people are, I think, starting to wake up, right? They're starting to realize, I need to get things into production. I need to, I see the benefits that other customers are having. I want a piece of that, right? And maybe they are realizing that when they look at their data architecture, they're not quite there yet, right? So what's the first practical step a company should take when they're looking at this? Where do they get started? Obviously, they could call you guys up, I'm sure you could help, but just in terms of a practical step and in terms of just starting the readiness process, what do you think?

Jason Andersen: 

Look, I think single biggest piece of advice, stop this problem. I've been saying that for a long time, but I think now it's becoming even more real than ever. Resist the urge to going to buy another niche vector database or a single purpose tool just to get a quick AI pilot off the ground. Every time you add another point solution, you're creating the synchronization lag, security risk, technical debt. I've lost a bunch of my hair dealing with all of that. I can tell you enterprises are struggling with this today. The sooner they realize that, the better it becomes. Instead, what they should do is start by building an operational data layer in front of what they already have. You don't need to keep, you don't need to sort of tear out your legacy databases or mainframes, they can stay. But you need like, I think Jason, you've described it as a system of action previously, right? So you need like a flexible platform that pulls that data together, enrich it with the metadata that you need, generate your vector embeddings right where that lives. And now you can provide that context directly to your agents with the proper metadata, with the proper security and guardrails that makes it available. And you can connect that unified data layer to your models and to your enterprise data with MCP and other standards that are available already. It's the cleanest, most practical way to get ready for this future. Perfect, that's great advice.

Ashish Kumar: 

It's great, good cross-industry advice right there. So Ashish, thank you for your time and thanks to everybody else for tuning into this Data and Observability Spotlight at this year's Six Five Summit. Don't forget to subscribe, follow us on the socials and check out all of our summit coverage at sixfivemedia.com slash summit. And we'll see you next time, thanks.

Speaker

Ashish Kumar
Senior Vice President, Technical Fellow
MongoDB

Ashish Kumar is Senior Vice President and Technical Fellow at MongoDB, where he focuses on architectural improvements across the product stack. He joined MongoDB through the acquisition of Grainite, a database startup he co-founded, following a career at Google where he led work across Bigtable, Spanner, Datastore, and Firestore. His expertise is in large-scale distributed systems and enterprise AI infrastructure.

Ashish Kumar
Senior Vice President, Technical Fellow