IT Tech Pulse Exclusive Interview with Pete Johnson Field CTO, Artificial Intelligence at MongoDB

Pete Johnson, AI Field CTO at MongoDB, explains how unified data platforms, vector search, and agentic AI are reshaping enterprise application development while simplifying AI architectures.

What does the Field CTO of AI role at MongoDB actually look like, and why does a database company need someone in that seat right now?

Traditionally, MongoDB’s route to market is to make a great product that developers love and then find a champion within different accounts that can then justify to an IT decision maker who controls the budget to trust us to be part of their application architecture. And that grassroots approach has worked great for us, reaching around $2.5B in revenue last year.

The Field CTO role, in general, is to complement that from the top down, so that the IT decision maker already knows who we are and what value we provide when that champion comes to them. We have a great Industry Solutions team that has Field CTO’s that are experts in important vertical markets like financial services, health care, retail, and manufacturing who know those businesses well because they all carried director-level titles at those organizations earlier in their careers. Those folks go deep on how those businesses work while I go deep on the current state of AI.

The day to day of that looks different than most people think. Most of my time is spent listening as opposed to presenting. I learn more from all the customers I get to talk to than they learn from me. The trick, then, is to aggregate all the things those customers tell me, and I’ve had the good fortune to talk to a lot of them over 19 cities and 6 countries in the first half of 2026 and turn those stories into feature requests and narratives that others can benefit from.

MongoDB has made a big bet on vector search inside Atlas. How does that decision change what’s possible for teams building RAG-based applications today?

Most RAG systems end up with the same set up: a vector database for embeddings, a document store for operational data, and a pipeline to glue them together. The better ones then add a reranker at the end to improve the overall quality of the result you can get back from the LLM. Every link in that chain is a place where things break in production (latency spikes, stale embeddings, sync failures) that nobody notices until a customer does.

Native vector search in Atlas folds it into one place. Your retrieval runs against the same system as your live customer records and transaction history. Freshness isn’t something you have to engineer around, it’s automatic. Zoom is a good example of what that actually gets you. Before consolidating, Zoom ran Meetings, Phone, Contact Center, and their virtual agent on different, disconnected data systems, the kind of pluglot set up most companies accumulate over time. They moved it all onto MongoDB as one unified platform across dozens of clusters, globally. The result was fewer moving parts to keep in sync, better resilience when something does go wrong, and lower total costs.

That’s how a RAG system can actually work for customers.

You’ve pointed out that teams often fall into ‘costly defaults’; when building RAG architectures. One of the biggest debates right now is using an all-in-one data platform versus stitching together specialized, niche vector databases. What are the most expensive mistakes you see teams making here, and how does MongoDB Atlas help them pivot?

Most people think of embedding models as a commodity. They are not. The quality of your embedding model is directly related to retrieval accuracy and, therefore, the quality of the answers you can generate with your LLMs. And by stitching together the pieces from different vendors, you not only increase your operational costs, but you make troubleshooting more difficult.

Bad retrieval doesn’t blow up. It just fails quietly, and then it gets expensive. When your vector store and operational data are in different systems, retrieval accuracy naturally drops. The problem I’ve seen over and over is that when the first query misses, you don’t get an error message, it just reruns it. Each rerun is a token cost you don’t plan for, multiplied across millions of queries turning into an expensive mistake, which could be avoided altogether.

Treating retrieval accuracy as a quality problem, while ignoring the cost implications, is a mistake teams are making far too often. With Voyage’s embedding and reranking models built natively into Atlas, you get industry-leading retrieval accuracy on the same platform where your operational and vector data already live. Voyage’s models are purpose-built to surface the most relevant context on the first pass, which is what keeps you out of the rerun loop in the first place. Solve it in one query instead of three and that savings compounds fast across millions of requests.

Everyone is talking about Agentic AI. Based on your recent customer conversations what does the ideal data architecture for an autonomous agent look like, and why is MongoDB uniquely suited to be the foundation for it?

The two biggest shifts I’ve seen in agentic architecture in the first half of 2026 have been around the response to token maxing and the desire to inject context from legacy systems of record into modern agents.

Organizations have started to notice their token consumption bills, most famously the Uber story that broke in April where they burned through their agentic coding token budget for the whole year in 13 weeks. The architectural reaction to that has been to not pack 1,000,000 tokens into the context window of the LLM for every loop your agent makes, but to find ways to put the right 100,000 tokens in each pass or to pull a prior answer from a better agentic memory so that you don’t have to make the generative LLM call at all. Both this context window efficiency scenario and generative LLM call avoidance come down to better retrieval quality out of a more sophisticated agentic memory and RAG pipelines. This is where the combination of MongoDB vector search and Voyage AI embedding models can make a big difference.

And those RAG pipelines are no longer about copying data to your vector database of choice. Instead, I’m starting to see techniques where you keep your data in the legacy system of record, generate a vector for it, and store the vector and a reference to the system of record in MongoDB. Because the MongoDB document model is based on JSON, this approach of leaving data where it lives but enabling it semantically to be included in an agentic context window is easy to implement but broadens the context possibilities pretty signficantly.

MongoDB recently leaned into the Model Context Protocol. For engineers who haven’t gone deep on MCP yet, what does it unlock, and why should it matter to someone building on Atlas?

More people will build agents in the next three years than have built them in the last three years. Part of what makes that possible is to slower the friction involvedin learning how to build one. That’s where things like MCP and Agent Skills come into play.

MCP unlocks real-time data access for agents and dev tools, without custom integration code for every connection. On Atlas, that means your agent queries live data, generates context-aware code, and acts on current state instead of whatever the model happened to be trained on. The stale-knowledge problem that makes LLMs unreliable in production mostly disappears.

The bigger reason to pay attention: MCP is now the standard interface layer between AI tooling and the systems holding your data. Get familiar with it now and you’re ahead of that shift. Wait, and you’re catching up to it later, on someone else’s timeline.

Agent Skills help accelerate the learning time a developer has by encapsulating specific, pre-built, reusable instructions for common data tasks needed when building agents. Tasks like designing schemas, optimizing queries, and setting up both secure connections to Atlas and the MCP servers. Together, Agent Skills and MCP reduce that learning curve for a developer.

You’ve spent twenty-plus years in technical evangelism across HP, Cisco, and now MongoDB. What’s the difference in how engineers respond to database conversations compared to infrastructure ones?

Less than people expect, honestly. At the end of the day, you’re talking to people who want to solve  problems . Whether that conversation is about routing protocols, network architecture, or a document model, the infrastructure is just the medium.

Engineers don’t show up to a conversation defending a worldview about how data should be stored. They show up trying to make something that works. My job is the same regardless of what’s under the hood: understand what they’re actually building, and show them concretely what gets easier or harder depending on the choices they make. That’s true whether the answer is a switch, a server, or a database. The technology may change, but what an engineer actually cares about doesn’t.

If you could give one piece of advice to an engineering leader starting an AI initiative with MongoDB in 2026, what would it be and why does it matter more now than ever before?

Right now, the capability of AI agents is moving faster than our ability to trust them, and most teams are building as if that gap doesn’t exist. Our instinct is to hand AI as much of the work as possible and call it progress.

I think of it like this: there’s no SKU for AI.

Meaning, there’s no magic purchase you can make that checks the box of completing an AI strategy that will placate your C-suite. The road to making a measurable difference to your business is in the problems you select, not the solutions you buy. Ask yourself three questions:

1. What are your 15 biggest problems you face as a business?
2. What do you have good data for around those problems today?
3. What metrics are you using to measure those problems today?

Making an AI purchase without a defined problem to apply it to is just a highly visible waste of money. If you feed AI with bad data, it won’t magically produce good results because it’s still a “garbage in, garbage out” proposition. And if you can’t measure the change with metrics, you can’t calculate an ROI.

The most successful AI deployments I’ve seen this year involve an employee-facing use case in a well-defined problem space. You already know the metrics you’re using to measure the effectiveness of that employee. By adding an AI agent into the workflow of that employee, if you see those metrics change for the positive, you can attribute that change to the AI agent and determine an ROI.

That ROI is what you can present back to your C-suite or your board. Rinse/repeat on the next problem.

Thank you, Pete Johnson, for taking the time to share your insights with us.

Write to us [⁠wasim.a@demandmediaagency.com] to learn more about our exclusive editorial packages and programmes.