AI Agents Are Spawning Unpredictable Traffic | Ben Cefalo

Ben Cefalo (0:00)

Agents can, of course, spawn other agents because at the end of the day, the agent wants to succeed on its task. And depending on the confines of that agent, it could start spawning other agents for the sole purpose of it needs to finish its goal. And so that could be unpredictable, depending on what guardrails that person set up. One thing that I have a bunch of agents do is I have it every morning go out and pull like 80 different news sources, look for certain keywords, and disseminate it all to me in a one-page doc. But I'm just one person spawning about 80 agents. Now, if everyone else is doing that, that's just a lot more traffic. So the traffic pattern while familiar, it's just exponentially more frequent, which is what adds to the intensity of the workload.

Sophia (0:44)

Hello, everyone. I'm Sophia and we're back with MTS. Today, I am joined by Ben Cefalo, who is the CPO at MongoDB. You're working on core products here, and you just got off the stage, catching him fresh, live off the stage, where you shared some cool product announcements that are coming out. Can you tell me a little bit more about what was shared?

Ben Cefalo (1:03)

Yeah, sure. And thanks for having me. This is exciting. Yeah, so this week, we announced the new version of the database, so MongoDB 9.0, best version of the database we've ever released. We've also announced Atlas Infinite, which is the new version of the core DBaaS offering, so new deployment option inside of Atlas. So it's not a new database offering, there's no code changes required to start using it, but we separated out the compute and storage.

It gives customers more levers over how they scale, whether they just want to scale the compute or they just need the extra storage. This gives them a lot more flexibility. And then we also announced Atlas Agent Engine as well, which is our new Argentic runtime platform and memory solution.

Sophia (1:45)

So one thing I want to understand about you, you're a CPO, meaning that you're constantly talking to customers, you're trying to understand what they need, what are the insights, what are the products that they're going to want to use. What does that look like? And because you're a CPO, my assumption is that a big part of your job is identifying where MongoDB needs to go, where should the resources go, what should you guys build? How do you actually make those decisions?

Ben Cefalo (2:10)

Yeah, it's a process. I guess first of all, to give you some origin story history, I've been here nine years. So I was the start out individual contributor on backup of all things. We just launched Atlas. We were in like three regions inside of AWS, just launched Azure.

And then we've grown from very little customer on Atlas to now we have over 70,000 customers across the company. So in those nine years, the fortunate side of being in one of my positions is the fact that I get to talk to a lot of customers, everyone from the two person startup to the Fortune 100 enterprises. And while a lot of people think those requirements are different, and they are when you get to like security and governance and different compliances that they might have to deal with or regulatory reasons. But at the end of the day, when it gets to the actual core database requirements, a lot of those requirements actually are the same. They want it to never go down. They want it to be resilient. They want it to have great consistency. They want it to be of course performant.

And then you get a little different permutations of all of those different requirements. But at the end of the day, it's really coming down to the security, durability, availability and the performance of the database.

Now, enterprises might want different SLA's and different SLO's and the startup might not necessarily care about having 100% uptime all the time.

But the real crux of your question is like, how do we disseminate all of that information? And unlike other product organizations and I've worked at other companies, where sometimes you're actually scrambling to actually find customer pain or find customer problems. And as a product person, you always want to start with what is the pain that you're trying to solve for your customers? So how are you going to benefit their development process or their products or their customers? And you want to put that into the product. Here, there's not a shortage of feedback that we get. And that's simply based on the plot. We have 70,000 plus customers. But two, customers really love our products. And the third thing is we're also open source. So we have a community MongoDB that we've had for years. We have 150 million plus downloads every quarter of our community. And so we get feedback from them too, whether it's Reddit threads or Stack Overflow. So we have a lot of information, a lot of feedback coming at us. And so part of the job of the product management, and I have about 47 product managers on my team, is really piecing apart all of that information, disseminating it, grouping it, thematically figuring out, does this all make sense? And then we go into this product planning process that we have every year and assess priorities. Those priorities are typically stacked rank based on a number-tude of things. It's not just about potential revenue. It's also about delighting our customers. We're very customer obsessed at MongoDB. It has been since the very, very beginning. So we really do look at this one thing might be slightly higher revenue generating potential, but this thing might have thousands of pieces of feedback saying, if we could just solve this one problem, adoption is going to increase or the customer could add another workload. So we really look at all of that and then make decisions based on that.