GraphQL, MCP, and the Future of APIs with Apollo CEO Matt DeBergalis

Welcome to the Platform Engineering Podcast. I'm your host, Cory O'Daniel. Today I'm joined by Matt DeBergalis, CEO of Apollo GraphQL.

Matt and the Apollo team have played a massive role in shaping how developers think about APIs. And honestly, I feel like, you know, you've really brought GraphQL to the masses, in my opinion. Like, Apollo is what brought GraphQL to me originally. Very excited about the work that you're all doing. Your open source tools have crossed billions of downloads.

We're going to dive into GraphQL, platform engineering, the future of declarative architectures, a whole bunch of AI, and I'm going to love to hear the story about Matt's experience as a CEO. Matt, welcome to the show.

Awesome, thanks for having me.

Okay, so I always love to start talking about people's journey, but it sounds like you've had a job title change recently. So I would love to just kind of like start with how you got into engineering in the first place and what brought you to GraphQL and Apollo.

I'm one of those kids that grew up with a Commodore and programmed from as long as I can remember. For me, a big moment was spending a lot of time with the early Free Software Foundation folks up in Boston in the 90s.

And it's really the cradle of a lot of what open source is all about. And I sat with them and really believed early on in the power of it's not just a technology thing, it's a movement, it's a community thing.

And so my whole career, my background's really been about the intersection of those two things. I love building tools for other people. I love platforms. I think they have such leverage and they make the world so much better at scale. And I love building a movement and a tribe around them because I think, at the end of the day, this is all about helping people do great things and about making the world a better place. So it's been a fun, fun place to spend the time.

Yeah, very cool. So you've changed roles recently. You went from CTO to CEO. I did this recently... well, recently, I guess I did it three years ago now. Like, how has that experience been? Do you find that your actual role has changed much? Are you doing more things that you are learning to love, or less things that you used to love?

A lot's the same. I mean, we're a technology company. My co-founder and I have always been close partners. We're both very technical. So CEO doesn't mean I'm not going to be writing code or having my hands on the tech, especially now with these AI tools. I don't have 40 hours a week to write code and I've been really, really digging the current generation of tools that let me stay closer to the leading edge of what's possible.

One of the great things about AI is I can use new products and new technologies that I haven't had the time to really study deeply. And I think that's really fun. And the company is all about helping people write great software.

For us and for Apollo, that's about solving the problem of if you're building an app, how do you connect it to the APIs underneath that app? And there's just a ton of nitty-gritty detail. There's a lot of considerations for how you do that. And we just found that's an interesting place to focus in the stack that lets us accelerate how quickly companies can build apps, improve the quality of those apps.

And, you know, none of that changes. It's the same job, just across a bigger part of the company.

I love that. That's one of the things that I've found like different is like you get... it is a different role, but like I very much still keep my hands on the tech. And I love that you said that you're still working on it. We definitely don't have 40 hours... unless we give up sleep, that is an option. I don't know if you've tried that one yet. You can code all night.

I've tried. It doesn't help.

No, it doesn't. It doesn't help whatsoever. I feel like I move slower when I code all night trying to get something done.

But it's awesome to hear that, you know, even as a CEO that you're still finding time to like get your hands on the technology. I feel like that's one of those things that is so important, especially for companies that are building tools for developers, like to use and dog food the thing that you're building, I think is really awesome.

For folks that don't live and breathe GraphQL every day, what's the simplest way to explain the big differences between GraphQL from REST and other API approaches?

Yeah, GraphQL is a language for querying your APIs. That's the simple way I'd put it.

So if you've got a bunch of REST APIs, or maybe they're older, maybe they're old... you know, there's still SOAP out there and XML-RPC and whatever else... or maybe they're newer, you've got Thrift, gRPC. Apps today are built on lots of those APIs, not just one. And so there's this whole set of things you have to do around how you combine them together, filter what they deliver, how you adjust the shape of the API to the needs of the app at a high level.

GraphQL is a language for doing that. It's declarative - so we're part of the platform movement. It's about describing what you want. We call that a GraphQL query. And then there's infrastructure that understands how to actually call those underlying APIs in a particular order. And maybe you feed the output of one into the input of the next. And a bunch of stuff you would have done manually in code, we can do as part of this middle layer between the two.

It's a lot like SQL, right? Once SQL came out, people don't generally write imperative code to crawl over tables and handwrite their own indexes and so on. There's just a "select this from that", "join with that", you know, "group by this", and the system does it for you.

So that's what we do for your APIs.

I've been a user of GraphQL and Apollo's tooling for quite a while. I want to say seven years now, maybe. First time I started playing with Apollo, I've been using it for quite a while.

And like, one of the things that, honestly, I love about it is actually very much treating it... like you said, it's an API for the consumer, like the client, the front end. And the way that we use it internally and we used it in the past was we had a plethora of APIs that existed that were either ours, external APIs that might be owned by somebody else, and a smattering of... you said SOAP earlier and I laughed because I've definitely put GraphQL in front of a SOAP API in the past seven years of my life. Like that does happen.

And the thing that I always found like beautiful and interesting about it is it really provides a nice decoupling point between what backend engineers are doing and what frontend engineers need. And we've kind of taken the approach at MassDriver, like we use it internally, that the graph is owned by the front end team. They're the ones that are making the clients that interact with our software. And it's like the backend team very much owns like the outside their domains and sometimes it'll be an RPC API or gRPC, sometimes it'll be REST, and sometimes it'll be other GraphQL APIs. But like they're all getting unified in this one layer that makes the most sense for the clients. And you know, that's super beneficial to us.

It feels like it makes the team move much faster because we're not always shipping... like we ship our business features, we ship like the outside of our domain, and then we don't have to think as much through like what's it going to look like to the client because the team that's building that goes, "You know what, we're going to make up what this looks like for the client." I feel like it's a really freeing technology.

You've used the term, and you mentioned just earlier, declarative architecture. So you know, you've compared this to Kubernetes in the past, like this declarative architecture. Can you kind of expand on what you mean by that in like the world of querying and interacting with APIs?

Yeah, I think across the stack there's this movement toward a component based or declarative approach to things that were previously done with code, with bespoke code. So Kubernetes, for example, we used to write code to deploy software to package it and install it and run it on machines.

And the benefit of Kubernetes is there's a standard approach now and it's not just that I can quickly spin up a bunch of my containers and I don't have to worry if the underlying host moves. There's all kinds of benefits to these architectures.

Now that everybody agrees on Kubernetes as a common standard, it lets other companies build products that are based on that architecture. So we've got all of these cloud native networking products, we've got all of these observability products that take advantage of the commonality you get when you're on Kubernetes.

So you might think like Kubernetes is for companies that have a million containers running on like tens of thousands of machines. It's a Google thing and most companies wouldn't need anything quite so powerful. But it turns out it's great for architectures and teams of all sizes because you get all of these network effects as more and more of the ecosystem starts to align around that.

And that's the story with APIs. If you think about the way that software gets connected to APIs today, we're still in that older world of everything done by hand. So there's the backend for frontend pattern. Every time I want to build a new application, especially in a larger organization, I'm probably going to have to adapt the APIs that I've already got to this new use case. The way you do that, more often than not, is you write some service, it's handwritten, it's never the code that people are most excited about investing in. It's just this thing you have to do.

Instead of that, we can do it in a platform based way where you say, "Okay, here's my queries." If I'm writing a React app, I just staple the query to the React component - that's what you were getting at a minute ago - and there's nothing more to do. The system understands how to feed the data from the cloud to the client. And again, there's all these other benefits.

Like now we have an observability story. One of the really great things about GraphQL is that a GraphQL scheme is fine-grained. We have this idea of individual types and fields in GraphQL. So you can ask questions if you're using GraphQL like, "Which of the actual fields coming back from my REST service are being used and by which clients?"

Yeah.

And a REST API just doesn't let you do that. There's no way to know of this giant payload that's coming back, what part is the app actually interested in? What part did it throw on the floor?

Yeah.

There's so many of these sort of benefits, when you just agree on a common language and a set of rules of physics for how this is going to work, that start to pop out and that's what we find works so well with this approach for APIs.

Yeah, I feel like the language itself has so many good primitives too. So like just the idea that there is a way to show that there's some deprecated fields. So like internally... we're an early stage company, we move pretty quick on like API changes, but like we don't want to break stuff at the same time. Right?

And so what you're saying there about telemetry... we built something internally where it's like as soon as a field is marked as deprecated and a request comes in on it, it automatically tracks which client it came from. So we actually see like, "Okay, 10% of our requests are still using this deprecated field." A month later, 5% are still using this deprecated field. Like we can actually see it like wind down over time.

You can call them up.

Yeah, yeah, yeah. Definitely call them up. Slacking them.

Yeah.

But it's one of those things, it is hard or harder, I feel like, to move quickly with a REST API. Like to make changes to it that may be breaking... to find breaking changes. You don't know what people are using, right? They're getting the entire bag of what you send down.

And that's one of the things I've felt really freeing about the language is it does allow us to move much quicker. Which I think is important for platform teams. I mean, especially like when you're building out an internal product.

It's important for every company.

Yeah. Oh yeah, it is important for... yeah, valid. Valid. Yeah.

Play that out in a larger company - where maybe you've got a large company that's done a bunch of acquisitions, they've purchased products, and the idea is to bring those products together. We have a lot of GraphQL use in the hospitality industry.

Oh yeah.

So you're a hotel chain, but maybe you also have restaurants, and you want the guests at your hotel to also book a reservation at the restaurant. I mean, that's a pretty reasonable customer experience, if I'm checking in. By the way, maybe that guest wants to check in in the lobby on a kiosk instead of having to go to the front desk. Maybe they want to unlock their room with their phone. Maybe there's a late checkout option that you can upsell them on.

So you've got all these APIs that were built over the course of decades, and you didn't even write all of them. So there's no common language - the idea that we have everything perfectly documented or aligned around a single technology is never going to be the case. And yet somehow you have to ship faster and faster and faster.

And if you can do that quickly, you're in such a great place because customers love that. They want to be able to book a hotel room and know that they can get late checkout. That's important. That's the puzzle. That's why GraphQL spread so quickly.

If you're an engineering team trying to ship, you're really caught between a rock and a hard place where you've got to ship today, you've got to. But if you do it without the right architecture, you're just digging a deeper hole for tomorrow, and it's going to be that much harder to ship tomorrow on top of all of what you've built so far.

And I think things like Kubernetes and GraphQL... React on the frontend is another example... they're all about how do you move fast at scale, how do you move fast today where tomorrow's going to be even faster instead of being more and more weighed down by the work that you've done.

One of the things I think that's pretty brilliant about the language is the type interface to it - whether or not fields are nullable. I feel like in a lot of REST APIs... and even leaning into things like open API specs and whatnot... you can say that this field is of this type, but it's documentation - somebody could be curling that on the other side of the world.

But like our tooling, where it's like the API and the clients make agreements on stuff, it's like if you send a null field out on a non-null field, you get errors saying like, "Hey, you can't send a null out here." And that's the kind of catches that I feel like does make it much easier for teams to move quicker.

But I think the other thing that's really interesting about types... like we've seen this progression over the past, I don't know, 10 years, where there was like this big love of no types, right? You had like a big push into Ruby, and then you saw like Sorbet and Ruby 3 and everybody's like, "Oh, no types was so great." And then as software becomes mature you're like, "Types make everything a lot easier."

We saw this with JavaScript too, right? Like the move from JavaScript to TypeScript. And like to actually have an API where you're starting to have some enforcement around these types, I feel like is (a) great for us, but (b) when we start talking about agentic coding...

Yeah, exactly.

And all this other stuff. Like to have machines be able to understand what they're actually going to get back, and then also like deal with the nuance of a prompt someplace, right? Like this is my mom somewhere asking for something, she doesn't need the entire payload for like the thing that she's asking ChatGPT. And so to be able to have these... I guess neo developers - our digital twins, right?

Like being able to select just what they need and actually understand - not like, "Ah, this is money", but like saying it's going to be an actual type of integer or... hopefully not float. I think that is going to be really important to building resilient agentic coding and MCP systems.

I think we should pause here and, you know, if I were king for a day, right? Store your currency values as integer cents, not float, and your life will be so much better. Everybody should take that lesson to heart. I built a big piece of software earlier in my life where I didn't know that at first. It cost me more time than I care to admit before I addressed that.

It's more than just the static types, so GraphQL came out of actually a mobile development pain point at Facebook originally.

One way to think about GraphQL is it's the first API that was really designed around the needs of the application developer and not the service developer. I think if you really digest what that means, it has a lot of interesting implications and explains a lot about how and why it spread.

It's not just a static typing, GraphQL is designed to have its own documentation embedded in the schema. So that's documentation that's written in English, or whatever, but like natural language. And there's another kind of form of documentation with comments that you can put into GraphQL. And what we have found... you're spot on with this point about agentic systems... is it makes GraphQL semantic.

Like when we think about all the APIs that you've got, if we define them in the form of a GraphQL schema - which is just a way to... it's configuration, it's just explaining what the endpoints are and what they mean. There's an actual like semantic description of, "These are the objects, this is how those objects relate to each other."

I've got a customer object. I've got a user object. There's a way to talk about all of the customers that a particular user has. I guess that's a silly example, but you get the idea.

It's a visual graph. Like we can draw it on the screen - there's an Apollo tool for that. And we have found that when you hand that to an agent, it is very interesting how much more the agent can do. Partly, the agent understands it better.

Oh yeah.

And partly the strong typing means the agent is constrained. So we've been playing around with, you know, just type the query you want and have the LLM write your query instead of having to navigate, especially if you've got a big graph with thousands of different objects in it. I think that's a lot better than having to search through the graph to write your query.

And the way it works is that the agent tries to write a query and then it builds it. There's a validation step and sometimes that query is invalid because maybe there's a nullable field and you didn't handle that correctly. Or there's an interface type that you didn't use the proper fragment. Whatever it may be.

Those errors are semantic. The agent can refine the query and you end up with something that's built on solid bedrock instead of code that you're never really going to know if it's correct or not until you run it and it's like a...

The big pitch for declarative platforms in an agentic world, is that they're the bedrock, they're the solid ground that, if you have that, you can let the non-deterministic transformer stuff run wild on top of it because you're always grounded with what it's actually doing, at the end of the day.

One of my base rules that I added to Cursor maybe about a month ago... and it really, really sucks because it was right around the time that like ChatGPT5 came out. And so everybody has like, I guess, very small stats that they have on like how that went for them. Mine got skewed a lot. But I feel like I didn't feel it as much as everybody else - like, "Oh, ChatGPT 5 is not generated as well"... One of the things I added was our GraphQL schema, like the actual schema file that pops out, as one of my base rules in Cursor. So that's just kind of always there. And so like it understands like the outside of our business. And what's in there is exactly what you said - the documentation describes fields, you can actually see the relations between stuff.

What I'd previously done was I'd feed it like our database structure. What's interesting about the difference - I switched from our database structure to our GraphQL - is, yes there's a lot of the same terms in these two schemas, there's a lot of the same words, but there's the data relationships that you find in SQL, and then there's the usage, and more of the domain, and more of an understanding of the business.

That's right.

And that's what I think is really important for these things. It's not understanding how you store data, but understanding like what our business needs are. Because that's what we're talking them through building features with.

I wish there was a really good way to kind of go back through like my past six months of vibe coding with these things. But since adding my GraphQL schema, just as one of my base rules, I feel like the code output just understands our business more. And that is one of those things. It's like, man, these agentic coders - it's not all about just like producing some code. They have got to grasp the business. And I feel like it's a real hack to giving them a lot of insight.

And we know this, we know the LLMs do better and better when you constrain them and prompt them the right way. That's what this is.

One of the things we've been working on is we have an MCP server. There's two ideas here. One is the world needs a bunch of MCP tools now. How are you going to write all those tools?

There's a school of thought that, "Yeah, write an MCP server, it's not that hard and Claude will do it for you. So what's the big deal, right?" But I don't think at scale that's the right architecture for everybody. We've all read about all the security problems around MCP. There's just a lot of danger in suddenly having a bunch of net new endpoints that aren't built in a structured way, where there's no clear way to do governance or control around it. So one thing you can do with Apollo is you can just write a query and say, "I want that query to be exposed as an MCP tool." So it gives you a really easy way to take the APIs that you've got today and literally, in five minutes, here's your MCP equivalent. And it's not a one to one map, right? Because we've learned you want to narrow the context to just the part of the API that you actually want the LLM to see. A lot of APIs return a ton of potentially useful data that is just going to take the LLM in a funny direction.

Far out on the left.

You want to narrow that down, you want to do joins because you want to have a deterministic combination of data across APIs.

But the other use case for MCP is what you were getting at. We have an MCP server that lets your agent understand your graph. What does it mean? What are the objects? How are those objects used? What clients are using those objects? In what combination? How's that changed over time?

Imagine what that does for the quality of what your tools are building, if it understands your business like that. That's pretty exciting for us.

Yeah. And the subtleness in it too. Going back to talking about declarative architectures and declarative queries, I was just hacking with one of my buddies the other day and I was watching him build something with AI... so it was a series of REST APIs. And so he has to make a call, then he has to make another call, and he has to make another call. But like the field names are changing. So he's like, "By the way, when you get this back, this field name is going to be... that field name is the input to...". And so he's like just doing this imperative code in English. And I'm like, "Oh my God.That's torture."

And as soon as you have another MCP server that's got to do the same couple of queries, you're going to have to do that same thing or share the prompt between them. And I'm just like, that hurts to watch it. I'm just like, "Oh man, we never even think about that." Like whoever makes the field and the query, they think about that and then nobody else ever thinks about it again. And it is really interesting.

So, you have one MCP server that you guys have released so far? Or is there a set of tools? What do you have there?

Yeah, there's an open source MCP server and anybody can use that alongside the other GraphQL components that we have. And that lets you define MCP tools in this declarative way that's sort of the foundation of all of this.

And then it's a meta thing, right? We run such a server and you can use MCP specifically to talk to the Apollo platform. There's a schema server in the Apollo platform. There's a set of metrics around how that schema is used. And this is where all the typing and the metadata we were talking about comes in. So you can ask, "Hey, tell me about the graph. Tell me what objects I have available. Can you write me a query that does xyz?"

That free form agentic DevOps stuff, I think, has a lot of legs. And it's not just Apollo, right? There's all these great things in the platform engineering world that, once you can use them that way, once your agent can go off and talk to different systems, depending on what you're trying to do, it really changes the whole practice, I think, around development and how much faster we can go.

Yeah, and it's really interesting too, like thinking about the kind of things that people are bringing into their internal platforms, right?

I feel like, a year ago, having this conversation it would be very much around like containers and somebody needs this database or that database. But like now you're seeing people need data. Like that's what I need out of my internal platform - I need this data, I need this action, I need this aggregation, I need some generation.

And starting to see teams incorporate... not AI like, "Hey, we have some AI running behind the scenes for how your container is scheduled", but like actually exposing AI as a primitive in their internal platforms I think is something we're going to see a lot more of in the next couple of years. Because, you know, having every teammate have a million tools kind of scattered on their machine to do things versus like being able to kind of talk to our business platform that understands our data, understands there's 10 data sources behind the scenes where we can do these aggregates or pull this aggregate information from, I think is just going to help us build faster.

And in a world of effectively brokering data between these things, like being able to reach for that as a part of the core platform, I think, is something that many teams are probably... I mean, missing today but I think will be becoming shortly.

It sounds like this MCP server, if you're running GraphQL already... and can you use this alongside any GraphQL or does it have to be an Apollo GraphQL server? Like, if you feed it the schema?

It's standard GraphQL. You feed it the schema. But there's a lot of integration with Apollo specific stuff. So when you start wanting to ask about how the graph is used, for example. Or just the way that it can... you know, a lot of these examples are very small schemas but we've got schemas that are... gosh, I don't even know... megabytes, if you write them out as SDL, they're very large.

And so there's a lot that you need to do just in terms of making that perform well and behave consistently that you get when you're using it with the rest of the Apollo stack.

Kind of in the AI space, you guys are working on this MCP server, I hear that you're also seeing just a ton of MCP events right now in San Francisco. You said during the pre interview that you're seeing like five a night.

Oh, it's nuts.

So you know, as far as GraphQL and Apollo, like what are some of the things that you're excited to see or maybe some of your customers are doing with MCP and GraphQL today? Just to put some ideation in people's heads of like how they can start using this internally with their own products.

Yeah, I mentioned agentic DevOps. So there's a lot of excitement. And that's a safe place to start, I think, for a lot of companies, because it's internal, it's developers that you trust and that are probably forward-thinking with AI.

The big exciting thing is... we're an application development company, at the end of the day, we're here to help people write great software... What's great software going to look like in the future?

I think what's going to happen is you're going to see a pretty blurry line between a traditional application and something based around an LLM. Some kind of intelligent app. It's going to be hyper personalized. It's going to have context, not just state, but context from the LLM half of the picture. But that context is going to affect what you see on the screen and vice versa.

We're really excited about what that means because in a lot of the current, traditional applications, you're constrained. You're constrained by how many screens you have or... you probably can't ship an update to the mobile app every day that changes the way the app works. Your customers would get frustrated.

But AI actually lets us personalize the whole app experience top to bottom for each user. Think about a bank. A bank has an interesting problem because they have to somehow serve the needs of an older retiree and a twenty something person who has very different ideas of what their bank is and what they want to do with their bank. To do all that with one app is just so hard. But I think there's a world where AI lets us have different experiences depending on what we want, what our preferences are, and it can learn from that.

So there's a lot to do. If we just think about the future of the frontend stack. How all these pieces fit together. What that means for how they talk to systems and services and APIs. I think a lot's going to change and MCP is part of the story because that gives us a protocol.

But if I told you about HTTP, if I handed you the HTTP spec back in the early 90s, and said go predict the web of two thousand and eight, I think it would have been a big leap. A lot of things I think are going to emerge from these patterns as we see how it all plays out.

Yeah, the personalization one's pretty interesting too because I feel like... my background before Massdriver was travel and retail, or travel and E-commerce. And like both of those industries are hell-bent on personalization. Like the more you personalize, the more you sell. And, at the same time, I'm one of those people that like... oh man, I complain about every user interface I get.

I'm like, "Oh, they should move this button here, they should move this button here, they should move this button here." But it's interesting, whether or not like our interfaces will necessarily be shaped to us in the future. Which I hope they do, kind of, because I would love it to work the way I want it to work.

It becomes even more interesting to start looking at the API technology behind the scenes. Because, again, if we're hitting these fat APIs that are returning a thousand records of fields that you don't need from a REST API, you're just constantly sending these servers just off into the wilderness trying to figure things out. It seems like in a world where we do need more hyper personalization, it is one of those technologies I think that's going to keep these things focused.

Yeah. And you know, you talk about retail. So Wayfair is an example in retail. They adopted GraphQL very early on, it's a huge part of their architecture strategy. They're doing really interesting stuff around personalization, where the graph lets them run experiments very quickly, and different flavors of the shopping experience for different people.

Customers are going to go to the brands that have the best online shopping experience. Best means it has to perform really well - we all know the latency issues in commerce and the lost revenue if your screens take too long to paint. Best means seeing the products you actually want to buy when you go there, instead of products you don't. There's so much upside.

There's so much upside if you can build a really engaging and delightful personalized shopping experience. And every retailer is going to be fighting for that.

This combination of a semantic object layer and a set of agentic technologies that are coming, I think, is going to have a pretty big impact on all of these different touchpoints that we have as customers or users of this stuff. And you know, a lot of this for us is about I just want there to be better software. I want the stuff to work better for me and my life.

And it feels like we're starting to see how some of that can all come together in the next year or two.

I really think those are going to be extremely important.

I mean I think that just the different experiences that we demand in our apps... like from service to service but then from like just the different customer bases... but seeing just the different ways that people interact with these things.

You're kind of calling out like where GraphQL came from... around this like, you can't push these changes to devices constantly and seeing like... I know a lot of them are still like pretty far-fetched but like we're starting to see other ways of communicating with services besides just our phones. We have the Alexas and you know... if you remember re:Invent from three or four years ago, I think the claim was going to be that we weren't going to use our phones anymore, we were just going to talk to Alexa about everything. And like that was pre the big AI surge.

But we're starting to see the different devices that come out. And it's like they are all just talk based, and trying to move away from necessarily having a phone to different wearables. What are those experiences like? Those fast experiences when you don't have a screen? When the results behind them are powered by massive, slow APIs?

That's the pitch for platforms, I think, because if you're thinking about a future that you can't really predict, the thing you have got to do today is have a starting point that lets you reach that quickly. Like we don't know what's coming. We could make some guesses, but we really don't know. I think the one safe prediction is that there's more yet to uncover. And the companies, the teams that can jump on it fastest and meet customers where they want to be met, the way they want to be met, are the ones that are going to do really well.

So for me, in the infrastructure trenches, I think about it in terms of what's the right set of building blocks that we can be confident gives us some flexibility. A lot of the agent stuff today is experimentation. And you see articles saying like, "Yeah, 90% of these products are going to fail. These projects aren't going to actually succeed." That's not a surprise and that's not a problem.

What most people are doing today... I think the smart teams are purposely putting a lot of irons in the fire. And if you think about what that strategy means, it means you've got to be able to move really, really quickly. And there's a new MCP product every week out there.

There's a lot of interesting stuff happening around, "How do you render UI components in an agentic experience?" So we've got these very interesting, "Let's put the components inside the chat experience" or "Maybe we put the chat inside the component"... there's a bunch of different ways to play it. You want to be able to move quickly and play around with that stuff and, when you find something you like, you want to be able to ship it. You don't want to have to say, "Okay, now let's go take it back to the factory and build it for real." Nobody has six months for that.

That's going to drive more and more platformization, I think, across the stack. Because it's the only way that you can possibly get there quickly enough if you've got an install base already.

Yeah, I'm not sure if I'm going to use the right term when I say this, but those like reactive ad hoc experiences you're starting to see in chat, where it's like you're seeing components get rendered back and they have data in them, like that is... the first time I saw one of those recently, I was like, I feel like this is the part that's missing from a lot of products where it's like, "Oh, there's a text box and you can just type whatever you want in there." And it's just like, "Man, what I wouldn't give to click on a button."

Exactly right.

And like just start to see these newer experiences coming back. I think that is one of the things that is really, really going to take the... you know, I think the chat box was a huge shift for a lot of people. Just like having open-ended box you can type into. And like seeing the original conversation that Sam had, you know, on Twitter or whatever, about like what this new experience should look like. And somebody's like, "It should just be a box." It was like... that is funny, like to see it was such a simple like yet dumb idea that was so profound.

And now to be able to start bringing in components that can kind of augment that experience, that are tuned to like what is currently in the context window, I think is the thing that's going to make a lot of the AI products that are still like a bit out of the layman's hand... it's still a little hard to get the right prompt in... but to be able to have these component and augmented experiences coming back with the prompt responses that people can engage with, I think is one of those things that is going to narrow that gap between the layman and the expert in using them.

And I think it's one of the things that's really important because I think the biggest thing - besides like people saying it's a tech bubble and there's some financial problems, which that's for the Motley Fool podcast to talk about - but I think the other big risk and worrisome part for me in AI is that gap between like, "Hey, a layman can just use this thing." It's like, well, a layman can if they can figure out the right words to put in, which can be hard, and then can evaluate the response for accuracy, which is also difficult for a layman. And to be able to present them with some sort of graphical interface that they're maybe more familiar with in the middle of a prompt, I think can go a long way to closing that gap. And I think it's pretty exciting.

Is Apollo building anything in that space particularly, or is that just something that you're kind of excited about?

Yeah, we are. We see this layer as being an end to end layer. And the very first code we wrote for Apollo was Apollo Client. It's the React binding to GraphQL. And we did that because we thought that it was the application developer that was really going to push that technology forward. And we wanted to make it easy for anybody using React to try this GraphQL thing and just make it a, you know, an easy switch - see if you like it and go from there.

So I have a soft spot for the client side of the stack because I think a lot of the interesting problems really start from trying to understand what's going on when you build one of these things. And what are all the things you have to connect together? What's the whole story?

There's so much interesting stuff happening at the component layer in terms of, you know, whether it's UI components or how you route the prompt to different models or... I mean, so much stuff is happening together and what we're trying to understand is - what's the stack?

What's the integration story for all that, that allows you to quickly and safely ship an agentic experience. And for us that's always just been a good window into where's the place to focus. A big part of GraphQL's value is that there's code on the client and the server, right? You can solve problems differently when you've got that end to end approach to the app Dev stack.

Is there anywhere people can check out like some of that new work today? Or is that stuff that's still a work in progress?

Some is out, some is in progress. I mean, go to Apollo.dev and, you know, there's a ton of stuff. We have a big user conference in October, and we'll be publicizing a bunch more then.

But you know, we're an open source company so we're shipping every week. Especially in the AI era, I think, it's just so important to try things and be open about it. We work closely with open source users and big companies, and for us it's always been the way you learn.

Yeah, well I'll say like Apollo is, honestly, probably one of the first or second libraries I install when starting to work on frontends now. The work you guys have done on it is fantastic. I absolutely love it.

I appreciate you coming on the show today. I'm really excited for the stuff you guys are working on. I'm definitely going to be checking out that MCP server tomorrow during my play day. Matt, thanks so much for coming on the show today. I really appreciate it.

Where else can people find you online and learn more about Apollo?

Yeah, appreciate it. Go to Apollo.dev and we'd love to get your feedback and come visit us in San Francisco in October for Summit.

Awesome. Thanks so much.