All right, so at the beginning of April I went to New York for
the MCP Dev Summit, and while I was there I got the chance to
record a few podcasts with attendees that were at the
event. This is one of those
conversations. Hope you enjoy.
I think we have to look at these agents as untrusted, maybe even
adversarial. How many people are reading this
code or like think about, I think events of the last month
with like Anthropic in the DoD, Think about what we're doing.
We're asking citizen developers to deploy untrusted agents
behind the firewall. And we're frantically wiring
those things up to every single system we can find.
And, and every CEO is basically standing up and saying we must
do this. We must do it now.
We have to take more risk. We have to act like a startup.
I can't think of any part of our business that isn't rapidly
changing where we look at it first and foremost as what do
these tools let us do? But they're only useful, They're
only useful if they have the context of all of the, the
systems and the services and the APIs.
And that's, that's what APIs are at the end of the day.
They're the, they're the front door to all of that stuff.
Hi, I'm Alex Alkever with the Linux Foundation and the Agentic
AI Foundation. We're here at MCP Dev Summit in
New York City and I'm chatting today with Matt Deburgolis.
If I said it the right way, who is the CEO of Apollo Graph QL?
And forgive me if I get anything wrong, correct me, I have no
ego. Thank you for joining us.
Before we get started on this conversation, which is going to
be about API lessons for MCPI, believe is what we were
discussing and tell us a little bit about what a polygraph QL
does. And then how we can chat a
little more about how you're leaning into MCP, particularly
since you're essentially a graph QL as a service provider and you
know, we're generating everything around the API space.
So MCP is a very interesting translational layer for you.
Yeah, sounds good. Thanks for thanks for doing
this. It's a great conference.
Thanks for coming. Energy is awesome.
It it you can't make this stuff up, right?
It it shows there. It's crazy, literally like
things are so I mean like I'm following all.
So each week I do a scrape of all the protocol repos and
you're just seeing things move so quickly, like, oh wait,
somebody signed ACLA or oh wait, you know, they just shipped the
new securities back. It's it's, it's crazy.
I think what's cool about MCP is it, it reminds me of the the
mash up era, right? It's it's, it's for builders,
it's for making stuff. And you know, we could talk
about agents are useful because they can connect to stuff.
So we need an answer to that. And MCP is a big part of it.
And what we've been doing it Apollo for the AP is of large
companies, especially is, is we're, we're basically solving
this problem of how do you, how do you take a whole bunch of
different systems? And AP is that you've got, you
might have thousands of them in a typical enterprise.
And how do you glue those together to make a great user
experience? And this got its start back when
we're talking about building a mobile app or a really great
JavaScript app in the browser. But it's always been about
builders. It's always been about, I want
to make a cool thing. I want to make something my
customers are going to love. And I want to do that on top of
real stuff. And and so now we can have that
whole conversation again, but at an even bigger scale because
we're talking about with AI being able to build so much more
and not just the sort of user facing, you know, first class
mobile app, but think about all the things that are happening
inside the business now that we've got agents on people's
desks, now that we can build software large and small really
quickly. And the part that I'm just so
excited about is we know how much amazing stuff is out there
inside micro services or inside little pieces of SAS or inside
these systems that people have built over the years.
And the more of those we can connect together, the more of
those we can connect to an agent.
I think it's going to change so much.
It's going to make businesses faster.
It's going to be better customer experiences.
It's real exciting. And so from your viewpoint too,
because you've spent a lot of time in the API world and now
you're essentially living in 2 worlds, what is the transition
or? I wouldn't say transition
because that implies one goes away.
Ape guys don't go at all. No, they certainly don't.
No. And like even with like graph
QL, it was still like kind of ascending, you know.
And rest is still, there's a lot more people use rest than graph,
even though graph is arguably much better for AI.
So if you could maybe take a stab at like, what is this
translational layer look like if it works really well for what
we're trying to to to build that world you're describing?
Yeah, I think all these things are complimentary.
With Graphical, for example, it's not about getting rid of
REST AP is or whatever you had before and replacing it with
Graph QL. That's not what Graph QL is.
Graphical is a query language, so it's, it's something that you
can layer on top of your REST AP is and it makes them better.
Like graph QL introduced the idea of strong typing in AP is
it's got this idea of introspection.
So you can ask the graph, what, what do you have for me?
What are the types? What are the fields?
How do they relate? How are they used?
There's all this metadata that comes along with that.
And I think MCP very similarly, right?
Nobody's saying you're going to throw away your underlying AP is
we're talking about a new way to use them.
We're talking about adapting them for the needs of an agent.
But I think really the, the magic thing about MCP is the
flexibility in the free form part of it.
You know, we're, we used to think about AP is as these rigid
things that got designed very carefully a long time ago and
they never change, right? Like, but that's not the world
we're in anymore. Systems can change every day,
and MCP gives us a way to to talk about that and to expose
those ideas to a system. Dive a little deeper on that, if
you can tell, I mean, if you will, on what is
architecturally, what does that start to look like if you're
trying to build out something that takes advantage of the
goodness of graph QL and melds it to the goodness of MCP?
Yeah. So a company has been using
graph QL has, you know, we call it a super graph at Apollo.
They've, they've got this semantic catalog of not just the
low level details of what's in the AP is, but the higher level
meaning of that stuff. And that's magical for AI
because the agent needs that information to make good
decisions. If if I sit down one day and I
say, hey, now I've got clawed code so I can, I can build a
business dashboard with that dashboards using the wrong
stuff. If it misinterprets the meaning
of what's in your AP is that's really bad.
That's, that's worse than not building it at all, right?
So what we're excited about is MCP gives us a way to connect
that graph and connect all those business objects that that
people have now defined to this new world of interactive LLM
harnesses to a world of software that's built by LO Ms. like
Cloud code or, or Codex or whatnot.
And think about what this means. Like now we can sit down and we
can ask questions about our business.
We can say, hey, I've got, I've got a bunch of amazing data
inside this piece of SAS, the screen and the SAS product
doesn't do what I need, but I, I don't need that anymore.
I can just. Right, the users.
Don't talk and the. Users don't want that anymore
either. They're changing, yeah.
Or, you know, a big problem the enterprise has is, is
essentially you've got a silo problem.
Big companies spent the last 20 years building a whole bunch of
silos. That's what a micro service is,
right? It's it's, it goes back to the
Jeff Bezos memo like you're, you're.
Going to do an API for everything. 1 little silo and
you can only talk to it this way.
And that made a lot of sense architecturally.
But now we face this problem, which is I've got all this stuff
and it's it's separated. And what what makes it valuable
is when I can bring it back together.
Most of the questions I want to ask about my business aren't
going to be answered out of one thing.
They're going to be answered out of a whole bunch of them.
And it's the draft, and it's the.
Relationship between? Yeah, exactly.
And, and so give me a couple examples of how you're seeing
people do this in the real world in interesting ways or
surprising ways. Or because like to your point,
having a, a query language that can supply context when you
start to think of things like, you know, additional tuning on
top of open source models, it, it can probably be semi magical
or just have astounding impact. So versus like just working off
of straight, you know, API calls.
Yeah, I think a big part of it is, is this idea that we can
look forward to a world where there are lots more builders and
they don't all have a formal background in software
engineering. Like if you sit down with Claude
code and you ask it to build on top of a bunch of rest AP is
it'll, it'll get there, it'll muddle its way through.
But I think what a lot of us have found is it needs some
guidance. And that guidance means the
person doing the work should have some understanding of how
these AP is work. Like what's a rest AP?
Oh, it's doing this thing. OK, I need to steer it in this
other direction. And so that really blocks the
the thing I want, which is I, I want, you know, somebody in
sales to be able to use Claude to ask sales questions, Right,
Right. Essentially like few shots,
single shot, no shot. And what we get when we've got
this semantics, when we've got a clearer explanation, when we've
got MCP and Graph QL working together so that Claude's not
caught up in the nuance of like, oh, I went to the SAS, I found
it's open API spec, but guess what, that's not actually
accurate. So I had to iterate 345 times
and it it tries to use one API, but it turns out that thing
returns the wrong pagination key because this is just a use of
the API that the the product never really.
Or it's old they didn't Rev it or something.
Like that exactly. If we can cut.
Through that and it's, it's just the crank turning roll up the
sleeve stuff, right. But if we can cut through that
and give the AIA more semantic structured entry point to all of
those systems, then it gets magical.
Because then, then you can actually sit down and say, hey,
go over all the conversations that we've had, the transcripts
of all the conversations that I've got in a, in a, in a, you
know, SAS database and search for mentions of this particular
thing. Then go off and read the annual
reports from that company and go figure out how that matches up
to like what the CE OS talking about in terms of their
priorities. And then I want you to go hunt
down, you know, maybe the competitors of, of that company
and, and what they're talking about.
And suddenly a salesperson is in 5 minutes with no special
technical skill, making use of data that we've always had, but
never had a way to really take advantage of the same way.
And they can do it right before their sales call.
So there's not some complicated, you know, process where I've,
I've got to anticipate that I'm going to have this call, maybe
the call just got scheduled. They almost set it up with an
automated process. They said create a skill.
They run it before every ticks their calendar.
Yeah. And I can give you 20 examples
like this, like where certainly every part of our business is
changing. Yeah, like the way we think
about interviewing, how do we coach people on how they're
doing their interviews? How can we make those better?
There's a feedback cycle that we can start doing in real time
that might have happened once a quarter before, right?
Or how do we do market research? Or I mean, obviously there's a
whole world of how we build software in a different way and,
and how we think about Rd. maps and, and all the things that
come with that. I can't think of any part of our
business that isn't rapidly changing where we look at it
first and foremost as what are these tools?
Let us do? But they're only useful.
They're only useful if they have the context of all of the, the
systems and the services and the AP is, and that's, that's what
AP is are at the end of the day, they're the, they're the front
door to all of that stuff. So in your view then, do we need
to modify the way the AP is work at all if we want to lean into
MCP? Yeah, and agentic better.
The big problem is the AP is were never designed for any of
what I just talked to no. So I I gave you the the
exciting. Version here's the AP is the
rest was not designed. For like here's the cold hard
reality. I mean the the the biggest most
immediate problem is a security problem in my view.
Like these AP is were built for trusted users.
And what I mean by that is like they were meant to be used by
engineers who know how to do engineering, who have some, you
know, they, they review each other's code.
There's a whole bunch of rituals and processes that we've built
over the last couple decades. The rate limited key, etcetera,
etcetera. All that stuff and, and, and,
and underneath all that is human judgement, good human judgement
of people I trust, right. So if you wipe all that away,
you've got a big problem. Because if you think about a
typical API, for example, it's probably going to mix data that
has very different levels of sensitivity.
Like I've got a, I've got an HR system in our company.
That HR system has a list of everybody and their time zone.
That's really useful. I think.
I think that should be at everybody's fingertips, right?
Sure. Who the manager is, it's also
got probably, I'm guessing, I'm not totally sure, but I think it
has like their four O 1K contribution information.
Or their health. Information.
Probably not something right that people should.
Have exactly. And you know, I think just
across the board, whether we're talking about third party SAS
that you bought, we're talking about first party services that
you built. The AP is, are too coarse
grained. They commingle stuff that has a
very different level of, you know, sensitivity or importance.
That was OK in a world where I had control of the other side
and and knew what that code was doing.
But I think we have to look at these agents as untrusted, maybe
even adversarial. But how many people are reading
this code or like think about, I think events of the last month
with like Anthropic and the DoD really tell us how little we
really know about what's happening inside some of the
models in the harnesses. And if you think about the risk
of data leaks and exfiltration, if you think about this as like
a savvy adversary, a competitor, maybe an estate actor, this is
the biggest opportunity to crack through.
I mean, think about what we're doing.
We're asking citizen developers to deploy untrusted agents
behind the firewall. And we're frantically wiring
those things up to every single system we can find.
And, and every CEO is basically standing up and saying we must
do this, we must do it now. We have to take more risk.
We have to act like a startup, you know, like.
Please compromise our AP. Is it's, it's a rock and a hard
place because I think the businesses that do this are
going to go so much faster and they're going to have such a
competitive advantage. But like, at what cost if you
get it wrong? Yeah, no, totally.
I mean, like we were, we were. I was in Amsterdam last week and
chatted with, you know, some of the folks on the kernel, the
Linux kernel and they're seeing now essentially, you know, 0
days come in that are out of not modified frontier models like
consumer frontier models, you know, with very simple prompts
to call them out so totally and like what you're saying.
And if you really want to be targeted, it's even worse.
So what how do you think about solving this?
Or orders like graph QL start because it is so faceted and can
supply exactly so. I'll give you an example.
I, I think, I think there's no question that at a high level,
AI is going to change every part of the stack.
It's going to change how we build software.
So one example of that is I think we have to move to call it
a zero trust model where a a piece of software, an agent has
access to the thinnest slice of what it what it should.
And graph QL is a great architectural starting point for
that because it has field by field semantics.
So a graph QL schema says here are the objects in your
business. Each of those objects has a set
of properties. We call them fields, right?
We can assign rights to those fields.
So we can say a given agent which has, you know, 1
credential, you get this field, this field, this field in this
field and that agent is going to make that request explicit.
When I call a REST endpoint, I just say here's, here's the
arguments, give me back the result and the the API decides
what I'm going to get back. That model doesn't work for an
agent because the API, the micro service, doesn't know what the
agents trying to do. It doesn't know what it is and
it doesn't. It doesn't sound in a position
to enforce. Policy agents composing if the
agents composing the other four or five things or yeah.
And, and this stuff goes pretty deep.
You know, we work with financial companies that I think one
example is support agents only have access to a customer's
billing records if there's an open support ticket.
So those are two totally separate systems that if you
haven't joined together, but like that's a law, that's,
that's not some desired policy. That's actually a legal
requirements placed on a lot of financial companies as part of a
consumer protection stance. So the client has to be able to
specify what it's trying to do. And I think Graph QL gives us a
template for how to go about doing that, right?
Because in Graph QL, you write a query and the query is explicit,
says I want, I want XYZ and W out of the graph and I want them
in this order. And now we're in a position to
say, Yep, that's fine. Or like, if you want that piece
of personal information, we're going to block that request
until we do an approval process that goes through, you know,
somebody who owns the relevant system and can dole out that
access. So essentially almost as a
either as a Shim or if they're just using that as sort of a
native in a primitive construct of their API, it allows them to
assign much more a granularity to access attributes, anything
that they want to share. So a question on top of that,
because this is actually an interesting real world problem
that I saw, I think IBM wrote about it or somebody, but there
was an instance where you essentially had two bots last
agents inside of a company. You know, 1 was tasked with
customer, you know, customer maximizing customer
satisfaction. The other was you may have heard
the story was tasked with, you know, whether to give people
refunds or not. And and like the reward
structure was, you know, customer satisfaction was the
biggest reward. So it actually started handing
out refunds Willy nilly automatically.
So like this is agent to agent. So when we start to have these.
Kinds of dynamics? How do?
How do you think about writing or at the API level starting to
put better strictures or controls around this?
I think the rabbit hole goes pretty deep here, right?
Like you can start at the surface level, which is should
an agent be able to give a refund autonomously?
Maybe not today, right? Maybe tomorrow, maybe maybe
below 50 bucks, right? Like, right.
But you're getting at this much deeper, much more interesting
question, I think, which is like, what's it really going to
look like to have an autonomous agent that's doing the work that
a group of people would have done in the past?
And how do we, you know, not just think about it in terms of
the sort of the basics of security, but like maybe a
quality metric that comes with that?
Are we making a good business decision and how do we measure
that and how do we know? I think the interesting thing
is, have we really had a good way to do that in the in the pre
AI world? Oh, no, absolutely.
This is a new question. A new.
Concept. Yeah.
So I think there's going to be a lot of innovation here.
And I mean, it's interesting, like maybe a faster turn around
time on that decision is worth it if you're offering maybe more
refunds than you really needed to.
Maybe it's not. Maybe that trade off changes
over time. And I think we're going to find
a lot of energy around exploring the space of business decision
making with more and more autonomy, because I, I think at
the end of the day, it's the clock speed of the business that
really determines that company's prospects.
I mean, it's a, it's a very rapidly changing world.
And if you know, fast beats right, I think in a lot of in a
lot of moments today and that's an example of it.
Yeah, I completely agree. Because I think that that's like
an instance where user expectations either in the
enterprise Oregon consumer, they want everything faster all the
time, you know, and they're and, and, and it really tends to
drive process in that direction. And sort of the flip side of
that which I'm actually interested in your thoughts on
which I think builds on top of this on on the one hand, you
have security, on the other hand, you have trust, you know,
in A2 package and trust will enable speed if you do it right.
So what are, how are you seeing people think or how do you think
about, you know, creating trust systems within these complex
autonomous interactions? Yeah, and.
Can I add a third because I think about a stool, There's
also there's experience or friction because because I I
think a great security footprint isn't going to be worth anything
if you have everybody. Works right?
Everybody's mad about it. Yeah, yeah.
And and, and they will. So I think of it as a it's, it's
really a, an experience problem at the end of the day.
Like if we only solve an access control problem, it's putting up
a bunch of stop signs. But if we can look at it as,
hey, there is a wealth of incredibly valuable data that
you now you can have access to and you don't have to ask
because all that is taken care of behind the scenes for you,
right? And a lot of stuff doesn't
require a ton of scrutiny. You probably want to know what's
happening. You probably want an audit log
of all your agents and what they're up to.
But if we can empower people to take that first step, that
builds a lot of momentum, I think for what comes second and
third and 4th, because I think everybody had that experience
with AI, right? Like you kind of read about it,
but it's when you have your first touch with Oh my gosh,
that really went as well as I thought.
Or you see a hackathon where somebody, you know, build
something and you're like, wait, you built that and you did it in
a day, right? Kind of forces you to rethink
your assumptions about. A lot.
I built a custom MD scraper that basically pulls from YouTube
linked. I mean like anything I wanted to
do the half hour vibe coding on on clock code.
They brought it locally, but still, you know, yeah.
So I just keep coming back to I, I think there's a really
positive opportunity here for companies to get really better
at what they do. I mean, I've, I've loved the
technology, I've, I've been into infrastructure for a long time.
But I think what really drives me for a lot of this is I, I
want to, I'm an end user. I want to see better products, I
want to see better customer experiences.
I want that stuff to really be great.
And the AI thing goes way beyond helping companies write that
software faster that I use everyday.
It's going to make the company a more customer centric company
and it's going to show up in all kinds of different places, I
think. And so it's it's, it is a
security and a trust problem. But I think it's also more and
more, the way I think about it at least is you get there by
meeting people where they are and showing them a, an exciting
path. Because I think everybody wants
to be a builder at some level, you know, like it's fun.
So, so related to that, although much deeper down in the weeds,
if you had a wish list of changes to the MCP spec or to
the Graph QL spec to further this vision, what would be the
things that you would you would sort of say you think could
really help things along and if I'm getting you into how?
Much time do we? Have if I'm getting, I mean, if
I'm getting into political trouble, then.
You know, No, no, no. I mean, I've, I've talked about
the graph QL piece in, in a lot of places.
Well, I think the more context you can give the model, the more
capable they get. So a lot of this stuff in, in
both MCP and graph QL I think goes to the idea of providing
more structured context. There's an opportunity to, I
think provide a richer amount of like, if you think about what
this means, how does a human think about what something means
while they think about how's it being used elsewhere, They think
about access patterns. They think about, I mean, all
that human judgement. We don't, it's not always at the
front of our mind, but it's what's driving our our decisions
as developers. So we've got to get all that to
the models and there's a whole bunch of stuff you can do there.
I think another piece is just if we think about adapting the AP
is that we have which aren't going anywhere as you said to
what we're trying to do in practice, an agent in many cases
is going to want to fetch a bunch of data out of a system
and the only way to do that is going to be to repeatedly call
something to paginate across a whole bunch of stuff.
Well that that's really not there's a lot of problems with
that access pattern. Sure.
So I think there are capabilities we can think about.
Sequel's probably a good model for some of this stuff where the
AP is get more sophisticated. We can move beyond sort of a
basic request response model and start talking about things like
aggregation and sorting and filtering and the kinds of
things that an agent can quickly express.
They can be pushed further down the stack because the closer we
can get those actions down to the core systems, the more
efficient all that's going to get.
So like essentially the task or the whatever the you know the
goal, the work becomes expressed in a more complex query
structure that further down it can avoid some of the some of
the pitfalls of traditional API behaviors because.
I mean, as an example of like, the higher we can go up in the
abstraction chain, the more capable it's going to become.
And and you know, I, I think that applies to APIs just as
well. And at a high level, I think the
question is just like, and do agents want a different kind of
set of access patterns like most AP is were built either for
screens or they were built for least common denominator, you
know, service to service communication like a very domain
oriented, you need object 25 here you go, right.
So I just think what we're going to find is that agents want
other things than that. They're going to want to crawl
over that data in a different way.
We can anticipate some of that. I think some of it will still
learn as we go, but I think there's going to be a lot of
value in adding that kind of higher level semantics to these
things. There's a lot more though.
I mean, we could talk about real time and streaming and push.
That was a topic from this morning, right?
Like AII think fundamentally is kind of a real time thing.
It's certainly accelerating the way we interact with our
technology. Yeah.
And and I think both MCP and Graph QL have some, you know,
room for improvement on that front because again, it wasn't
maybe at the heart of what the original workloads most needed.
There's hints of it, but but there's a lot more that we can
build there. I'm very interested sort of as
because you live in at the intersection of two very
interesting worlds. I mean, because in graph QL, I
mean, you don't see a lot of people here that are very active
in the API spec community as well.
I mean some, but it's, you know, not, not you, you sit squarely
in the middle and it's a so you mean you have a very different
and sort of not different, but a nuanced view of this or, you
know, an understanding of both sides.
It's really different. Yeah, it's it's, I feel like
we've made contact with business world now and there's no
surprises there at the technical level.
But there's a lot here, here. I'll leave you with this.
I've learned over the work we've done that AP is, if you think
about it, are a handshake, their contract.
And in a company, especially a mature company, especially one
where you've got thousands of these, this is really a people
problem. At its heart, this is all about
a multi stakeholder alignment and negotiation.
I think AI can offer a lot of benefit to navigating those
conversations and navigating the kinds of changes that you're
going to want to make. But I think it's also important
to remember that like none of that's going to go away.
I think we're, we're always going to have people accountable
for the quality of these systems and the correctness and the
reliability and so on. And I think we're going to have
people accountable for the quality and correctness and
reliability of the agentic workloads that they build.
And if we recognize that upfront and if we approach this not just
from the point of view of like what's the transport look like
and how can we like add these semantics here to this protocol,
but we also look at it from the point of view of how is the
organization at scale going to change?
I know that sounds really abstract, but I've I've just
found over and over and over again, people are are in a
position to help drive these things.
But it's really about because the API is is has two sides or
because you might have 1000 consumers of your API.
It really is about an organizational transformation,
which is exciting. That's a really good point to
end on. I mean essentially change NCP
and plus API equals change management because you've
democratized access to all of these.
Things at the speed of. AI, for better or for worse.
Yeah, exactly. Yeah, it's for better but but
it, but it's not going to come without challenges.
And I'm just, I'm really eager to see that through because I, I
think there's a, an exciting world on the other side of I.
Think somebody said recently Yolo responsibly or something
like that which but. I like that, yeah.
Yeah, well, you're enabling parts of that.
Yeah, yeah. Thank you very much, Matt for
taking the time. I appreciate it.
Likewise, hopefully get to talk to you in another conference.
Sounds good.