July 9, 2025 • 44 mins
Agentic AI systems have the potential to work together, but not yet at scale. This episode breaks down two emerging standards — Model Context Protocol (MCP) and Agent-to-Agent (A2A) communication. Both promise modular AI integration, safer data flows, and agentic collaboration that actually scales. WWT engineer Sally Jankovic and AI advisor David Geddam explain why these protocols are becoming essential infrastructure for enterprise AI.
Support for this episode provided by: Glean
More about this week's guests:
Sally Jankovic earned her PhD in Applied Math from the University of Minnesota in 2023. Drawn to real-world problem-solving, she began her career as a data scientist at a healthcare startup, working on ML, NLP, and LLMs. Her hands-on experience led her to the platform team before joining WWT, where she was inspired by the MC group's collaborative culture and the chance to work across diverse tech stacks and projects.
Sally's top pick: Agent-2-Agent Protocol (A2A) - A Deep Dive
David Geddam is a Senior AI Advisor and Chief Solution Architect at World Wide Technology, with 25+ years of experience in AI, healthcare tech and enterprise solutions. He’s held key roles at Kaiser Permanente, GE Healthcare, Philips, IBM Watson Imaging and multiple startups. David holds degrees in Biomedical Engineering and Healthcare Technology and specializes in AI, cloud, NLP, computer vision and real-time navigation. On the hobbies front, he is involved in playing competitive tennis at USTA 4.0 level for teams in St. Louis.
David's top pick: Scaling Agentic AI: Impact of Model Context (MCP) and Agentic (A2A) protocols
The AI Proving Ground Podcast leverages the deep AI technical and business expertise from within World Wide Technology's one-of-a-kind AI Proving Ground, which provides unrivaled access to the world's leading AI technologies. This unique lab environment accelerates your ability to learn about, test, train and implement AI solutions.
Learn more about WWT's AI Proving Ground.
The AI Proving Ground is a composable lab environment that features the latest high-performance infrastructure and reference architectures from the world's leading AI companies, such as NVIDIA, Cisco, Dell, F5, AMD, Intel and others.
Developed within our Advanced Technology Center (ATC), this one-of-a-kind lab environment empowers IT teams to evaluate and test AI infrastructure, software and solutions for efficacy, scalability and flexibility — all under one roof. The AI Proving Ground provides visibility into data flows across the entire development pipeline, enabling more informed decision-making while safeguarding production environments.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
From Worldwide Technology.
This is the AI Proving Groundpodcast Today.
Two important breakthroughs youmay be unfamiliar with model
context, protocol andagent-to-agent communication,
and how they are quietlyrewriting the rules of
enterprise AI.
On paper, they're juststandards.
One shapes the data an AI cansee, the other lets teams of AIs
(00:23):
work together and hand thatdata back and forth, but in
practice, they decide whetheryour customer bot can tap into
real-time inventory system orwhether a factory robot can talk
to a quality control camerawithout tripping over compliance
rules.
To understand why this mattersand what happens when hundreds
of these servers and agentslight up inside a single company
(00:43):
, I sat down with SallyJankovich, an MLOps engineer,
and David Gedham, a senior AIadvisor.
Together, Sally and Davidjustify why, as AI systems get
smarter and start makingdecisions by themselves, why we
need new rule books like MCP andagent to agent, and what
problems they actually solve,both today and in the future.
(01:06):
This is the AI Proving Groundpodcast from Worldwide
Technology everything AI all inone place.
Let's get to it.
Hey Sally, hey David, Thanksfor joining us today on the AI
Proving Ground podcast.
How are the two of you?
(01:27):
Good, Excellent, Well, 2025 hasbeen billed the year of agentic
AI, and two methodologiesstarted to emerge.
We've been hearing a lot aboutit on previous episodes of the
AI Proving Ground podcast, andthat is model context protocol,
MCP or agent-to-agent protocolA2A.
(01:48):
Sally real quick.
Start us off, in case some ofour listeners out there aren't
familiar with either of thoseterms.
What is MCP, what is A2A, andwhy is it important to
understand it in today'ssomewhat chaotic AI landscape?
Speaker 3 (02:03):
Right, okay, so they're both different forms of
standardization, basically.
So the high level you can thinkabout is how do we standardize
how agents and by agent we meanan LLM that has access to other
tools, including API, apis andthat type of thing how do they
(02:25):
integrate into you knowenvironments and interact with
objects?
So MCP deals with when youthink about the objects the
agent is interacting with, it'sthose tool calls.
So it's a way of standardizinghow your agent plugs into a
specific tool in a way that ismodular and reusable.
(02:46):
So it was developed byAnthropic and I believe November
2024 it was released.
Since then it's taken off.
But essentially the reason it'staken off is once you write an
MCP server, they're called.
That's an integration of a toolinto your agent.
You can repeat that with otheragents and so it's just a really
(03:09):
nice modular way of plugging intools and also this means that
it's a lot easier to always knowhow your agent is going to take
in a tool if it's always in MCPformat.
Speaker 1 (03:23):
So, oh, go ahead.
A tool if it's always in MCPformat?
So oh, go ahead.
Yeah, and David, tell me abouthow they work together, if at
all, and what it enables the enduser or the end client to do.
Speaker 4 (03:37):
Yeah, so it's interesting.
I was actually looking at thehistory of MCP, right, and
before MCP, what people weredoing was, you know, when they
were chatting with LLMs, likethe chat GPT, they would start
adding context into the thingslike, hey, you know, I had a
conversation two weeks ago ortwo months ago about this.
(03:58):
You know, these are some of theother events that happened.
By the way, can you make abetter sense of this?
And that's where the wholecontext aspect started to get
designed.
And one of the other pre-MCPwas the language server protocol
, where these are the codingassistants that you're hearing
about, right, how do theycomplete a coding sentence?
(04:21):
Oh, because they're reading allthe programming languages and
they know how to construct itand then, therefore, they know
what the user is trying to dowith the code.
And that's kind of where theMCP at least that's a history.
And so, going back to why MCPand where I came in was how does
(04:42):
MCP and A2A start scaling thetransition to agentic AI and
physical AI, right?
How does this work?
Because right now, everythingwas about generative AI.
So that's where the connect is.
So MCP is standardizinginformation, as Sally mentioned.
But the second part of thatequation is how does the agent
(05:05):
take advantage of thatstandardization?
And so that's where the agents,if you design it properly, are
able to rationalize it, reasonand be able to come up with
autonomous decision making.
And that's kind of where theagentic or the A to A uh
protocol starts to take over.
So anyway, that's kind of myfeedback yeah, sally, how does
(05:28):
it?
Speaker 1 (05:28):
how does a to a start to take advantage of of that
standardization and what is thevalue of of that?
Speaker 3 (05:37):
yeah.
So, uh, I mean, david did agreat job of setting it up.
A to a is is very similar in insome ways to MCP.
It's not something that hasn'tbeen done before, it's just
being done in a standardized way.
So someone who has a bunch ofdifferent agents working on
different things say, one agentis helping you know customers
(06:01):
and then another agent is on theback end, sort of like the Atom
AI we have at WWT, and for somereason you want them to talk to
each other, or one has a taskthat it might pass off to the
other.
Then the A2A protocol basicallystandardizes how those two
agents would interact with oneanother.
You might have a third agent,your sort of head agent, that
(06:23):
you could talk to and say, hey,get this data from that agent,
or get this data from that agent, or have those two agents pass
data from one another.
So again, many engineerslistening to this will think, oh
, I had a setup like that before.
This is just the way tostandardize it.
Speaker 1 (06:39):
Yeah, appreciate the mention of Adam AI.
Just for those out there thatmay not be familiar, adam AI is
WWT's AI chatbot that we have onWWTcom.
It's available for all of ourinternal WWT users as well as
our external registered users.
So you could, as you'relistening to this, go out and
even type in at WWTcom what isMCP, what is A2A, and see what
(07:02):
you get.
There is A2A and see what youget there.
David, you know Sally hadmentioned that some of these
methodologies, while being usedfor a while, you know, really
started coming onto the scenejust recently I think you said
November 2024, at least for MCP.
Does that mean that it's justnow getting integrated into an
enterprise setting, or how areenterprises adopting these
technologies?
Speaker 4 (07:25):
or how are enterprises adopting these
technologies?
I think that, because of thekind of the starting you know,
like, generative AI has becomesuch a kind of natural way in
which people are interactingwith it.
Now, this is a naturaladvancement of that.
And how do you take thatnatural advancement and scale it
right?
And with the push of NVIDIA,with the agentic and the
(07:47):
physical, it becomes very, veryinteresting.
I see the MCP becoming thebrain of the agentic aspects.
Right now we're looking at,maybe task you know, automation,
right, like if you had acustomer service, sort of it's a
customer service that's tryingto automate.
(08:08):
Let's say, somebody calling youand trying to schedule a travel
or looking at booking yourtickets or things of that nature
.
Can I automate that?
Well, let's take it a stepfurther.
And now let's start to look atreal-time systems that actually
work in an assembly line orrobots, right when.
(08:31):
How do you think MCP could workin that in a real-time sense?
And so this aspect of how MCPis designed and the scaling I
mean, if you just look at themeta and the open AI releases,
they're talking about thousandsof MCP servers running
synchronously to directinformation into the engine so
(08:55):
that tasks can be automated.
I mean that's significant.
So I think it's a natural stateof scaling and that's what I'm
really interested about.
That's why I started looking atMCP.
Speaker 1 (09:08):
Yeah, Sally, it looked like you wanted to jump
in there for a second.
Speaker 3 (09:10):
Oh, I was just sort of agreeing well with David when
David said it was like sort ofa massive thing.
It's both massive from, like, aresults perspective and then
also like what that scalinglooks like, right, like I think
that's a really importantquestion to ask because, like
you know, from an engineeringperspective, as someone I've,
you know, built, uh, you know,some baby mcp servers and it has
(09:34):
come a long way in the pastlike eight months for sure
things are improving.
Uh, there are still things thatyou know, um, in terms of scale
, right like a server is goingto be limited by the strength of
, like, the LLM you're using,because it might only be able to
call so many servers at once.
So there's a lot of differentinteresting limiting factors
(09:54):
when you're thinking aboutgetting to that point that David
is talking about.
But I think that that's where,now that the main buzz of MCP
has sort of begun to pass,that's where the work has been
going.
Speaker 4 (10:08):
And Sally, I had a question for you.
You know, from an engineeringstandpoint Obviously I'm sitting
at the use case, developmentand ROI how does it benefit a
customer in bringing an MCP typesolution?
A question for you would be,when I started looking at the
design that Meta and Google andAzure how they're looking to
(10:31):
architect it.
Right, some of thearchitectures are a little bit
different than others.
One of the things that I have aquestion is about the memory
management of this context,right, how much of a memory they
want to place, how fast theywant to have that in-memory.
You know, from an accessstandpoint, from an inferencing
(10:52):
standpoint, what do you thinkabout how that would be designed
from a dynamic and staticcontext management?
Speaker 3 (11:01):
Yeah, I mean, I think again it's you know the answer,
is it really right?
It's going to depend sort of onyour use case and on your goals
.
And when I say on your use case, part of it is going to depend
on, like, okay, like, how manyservers are you calling and then
how many tools does each serverhave?
(11:21):
Because you know, the more youhave, like, probably the more
memory you're going to want.
And essentially also right,like again, you are really
limited by your, your LLMs, incertain cases.
So I'd almost argue, you know Ihaven't looked too deeply into
those architectures, but thismight be a place where I would
(11:44):
want to use A to A and insteadof trying to, you know, scale
horizontally, see how many toolsand servers you know I could
pack in, see how much.
I would almost say, well, whycan't we have one agent have
this specific task and thisagent have this specific task,
and sort of link it out morehorizontally?
So you're sort of spreading outthe tasks you're trying to do.
Speaker 4 (12:16):
It's like a distributed kind of approach.
Yeah, yeah.
Speaker 3 (12:20):
Yeah, as an engineer, when you're dealing with, I
have to keep increasing memoryover and over again, whether you
do it the way I suggested oranother way.
The first question is how can Imake what's a vertical scaling
problem become horizontal?
Speaker 4 (12:38):
Yeah, I think that totally makes sense.
Speaker 1 (12:46):
so I'm hearing you both mention servers, um, often.
So how much, how, how much morecompute is necessary here?
How much more cost is thisgoing to add if we're talking
about dozens, hundreds orthousands of of servers need it
to uh to to execute this, thisstrategy?
Speaker 3 (13:12):
So, oh.
So, to sort of uh backtrack andmake sure I clearly defined
what a server is in an MCPcontext, right, that is the sort
of package that contains allthe connections to the tools.
So, um, you might have like a,a server that you know connects
to a Postgres database that'sjust a SQL database and it might
have different tools fordifferent queries, different,
(13:33):
you know, calls you want to run.
It might, you know, it mightjust have a general query tool,
a specific query tool, an addrows tool, whatever it is, and
so those tools would all bepacked into a server.
And so when I'm thinking aboutcompute, you know I guess
(13:54):
there's like the compute that'sthe server is running, and then
there's also the compute at theLLN is running in order to talk
to all of these things.
So it's almost it's a trickything to talk about, right,
because, yes, if you're runninga bunch of different processes
on a bunch of different servers,you're using all of that
compute.
But then also you know the morecomplicated of a network you
have.
If you have a bunch of agentstalking to each other, those are
(14:17):
tons of LLM calls you're sortof generating, and so that is a
downside of like one of thesolutions I proposed.
I don't know if you haveanything to add to that, david.
I mean.
Speaker 4 (14:25):
what I would add in that just giving a perspective
would be is that it would besomething like if you look at
Adam just getting back to Adam,right, so Adam is now connected
into Salesforce.
It's connected into ServiceNow.
It's connected into ServiceNow.
It's connected into all theother information repositories
(14:54):
at Worldwide, our platform, ourweb pages, all of that, right?
So the point that Sally ismaking is those are servers in a
virtual sense, but they reallydon't take the type of compute
that you may be thinking about,the type of compute that you may
be thinking about.
Where the compute really comesin, my viewpoint, would be the
memory allocation to actuallygenerate the context, in this
case, the vector databases whereyou're storing the vector
(15:17):
representations of thisinformation so you can quickly
search a semantic, like theFacebook similarity search, as
an example, and some of theother vector searches, your RAG
applications.
Those are where the compute.
And then when you look at aBlackwell architecture, right,
why does a Blackwellarchitecture start to benefit is
(15:38):
because of all the networkingcapabilities from GPU to GPU,
rack to rack, networkingcapabilities from GPU to GPU,
rack to rack.
You know all of those things.
That's where the compute reallywould speed up the response of
the system, and hopefully I'mmaking sense there, sally.
So that's kind of what I'mthinking.
Speaker 3 (15:55):
I think you said that far more specifically and
eloquently than I did, so reallythat's a really good breakdown,
I think, of where the computeis really coming in.
But, just to hammer in on thatpoint from what David is saying
then the more servers andvarious integrations you're
(16:15):
adding and those types of things, that's where the compute is
scaling up.
So I do think, like I wouldn'tsay it's linear, but, yes, the
more integrations you have,because of all the things that
David mentioned, you're going toneed more of those to support
your application and that'swhere, yeah, the size does
balloon.
Speaker 1 (16:36):
Yeah, so I do want to talk a little bit more about
integration and, david, feelfree to weigh in as well.
Where does MCP and A2A fitalongside existing?
You know how enterprise ITteams support AI Like.
What does this do in terms ofyou know some of the API
gateways that we've been using?
Does it sit alongside, does itreplace?
Are we talking somethingdifferently or is it a
(16:58):
disruption?
Speaker 3 (16:59):
Yeah, I wouldn't say it's a disruption.
I would say that there is goingto always be.
Something I would encourage allenterprises to think about is
there's going to be some initiallift, because likely you
already have agents that knowhow to call tools, and
integrating an MCP server isgoing to rip out some of that.
(17:21):
But that initial that's like aninitial down payment, basically
, because once you sort of haveyour agents running so that they
can talk to other agents or sothat they can call other MCP
servers, then it's much, mucheasier to integrate from then on
.
So like there's a high lift atfirst, but then I think it goes
(17:42):
much better from there and thenalso then I think it goes much
better from there.
And then also I think that thegateway end if your gateway is
calling an agent, right, likethat integration shouldn't be
touched at all.
So yeah, I would say if you'reinterested in integrating it,
you should be prepared for timeto be upfront.
That's the cost and then it'llsave you tons of time on the
(18:03):
backend.
That's the cost and then it'llsave you tons of time on the
back end and up front what needsto be taken into consideration
by some of our clientorganizations or any
organization for that matterlooking to explore these
methodologies.
Yeah, so there's a few.
(18:34):
One, like I said before, likeyou're just going to actually
have code based changes andthat's going to take time and
you want to test anything that'sgoing into production
rigorously.
I think another thing to beconcerned about and thoughtful
about is, you know, security.
These are very new practices,and so I know that MCP and
Anthropic, who again is behindMCP, has just been coming up
with.
You know better ways of runningservers, so, for example, they
don't store your metadata andthings like that.
But there also have beenvulnerabilities in certain
servers, like the Slack one, soyou would want to like sort of
(18:55):
evaluate those things, make surethat the tools that you're
implementing also are actuallyauthenticated properly.
That's going to be a little bitof a bigger lift up front as
well.
So, um, just just for inregards to that like production
level, like we can actually putthis out in the public and it
won't leak our secrets, kind ofthing, there's gonna be a little
(19:16):
bit of a lift there too, butit's already.
From when I uh first startedthinking about mcp to now it's
already gotten a lot better, soI can only see that improving.
Speaker 2 (19:27):
This episode is supported by Glean.
Glean is the work AI platformthat connects and understands
all your enterprise data togenerate trusted answers and
automate work grounded incompany knowledge.
Put AI to work at work.
Speaker 4 (19:41):
I do want to kind of come back to the
interoperability question, right, I mean, the reality of all of
this, right, and Sally can kindof chime into it is that we live
there.
Legacy systems are going to bethere, right?
It's not like just because webrought in MCP, suddenly we lose
all the legacy information.
So the way I see MCP is, it'sactually to the advantage that
(20:02):
it's a great interoperabilitysort of platform, right, so you
can connect legacy informationas well as brand new information
repositories together, and thatreally benefits, if designed
correctly, can benefit theorganization tremendously.
And I'll you know, mybackground is I've been in 30
(20:23):
years in healthcare, designingpicture archival systems,
quality management systems,enterprise document systems, all
of these things.
And so when I look at NCP I'mlike, oh my God, how great would
it be to connect all of thisinformation set, because at the
end of the day they're all anecosystem that has some relation
(20:46):
from one to the other.
And if you just look at aclinical IT example in a
healthcare organization, right,a patient walks in and you know,
for some reason they're havinga problem, right, so you get a
diagnostic.
Right, you get a diagnostic orthe image that then goes into
the picture archive.
Well, then the physician mayask for a blood test, and they
(21:09):
may ask for this.
Then they have an electronichealth record and then they have
a visitation appointment as towhat's happening next.
Then they have a drug that isprovided to them, so that's a
pharmacy.
It to them right?
So that's a pharmacy.
So when you look at all of thisinformation, they're all
disparate information butthey're all connected to the
patient, to the physician, tothe administration, to the
(21:32):
insurance.
All of this, well, if I had anMCP, well, if I structure the
interoperability correctly, Ican query all of that in a
fairly quickly manner withouthaving to take a time Like it's
very siloed today.
So these MCP and agent to agentcan really help not only bring
(21:53):
structure standardization butalso the quickness, the
automation to get the patient,at the end of the day, the right
medicine at the right time.
So that's how I look at it.
Speaker 3 (22:05):
I think, yeah, I think your vision is the correct
one.
Maybe if we even wanted to diginto that a little bit, david,
and like talk through what thatwould even look like as an
example, right, like.
So, like you're talking aboutlike there's tons of different
systems you might need to queryand stuff, so you know you can
think of each database as itsown server with its own
integration and then maybeorganizing, you know, on a
(22:29):
larger level you'll havedifferent, maybe different
agents have access to certaindifferent databases and then
connecting them all with onehost agent that can talk to each
one of them.
Speaker 4 (22:40):
Absolutely Like.
So if you look at theelectronic health record system
like Epic, for example, it'sstill pretty siloed, even though
information is prettystandardized in them Right now.
The way I see Epic, for example, is you can search information,
whether it's an x-ray, whetherit's a blood test, whether it's
a lab, whether it's genetics,all of that right, the true
(23:02):
aspect of NCP.
And then AI starts to come in.
What if the physician, justbefore seeing the patient, runs
a query and a prompt saying, hey, what is going on with the
patient and what's his history?
And immediately it brings abouta very summarized thing saying
hey, you know, 10 years ago theyhad an accident or whatever you
(23:22):
know, they came in, they did ablood test.
These are current stats.
By the way, they have awearable monitor and so far we
don't see any problems.
So here is some of thesuggestion based on the large
image models are already trainedwith that data.
You're giving context to themodel, context and then you get
the answer.
And, by the way, now here's aprescription already.
(23:45):
Here is the next steps, here isthe next steps, here is the
next appointment, you know, twomonths down the line.
Wow, like like.
You're really starting to talkabout efficiency there.
Speaker 3 (23:54):
I kind of sound like what you were thinking, sorry.
Yes, yeah, exactly, exactly.
I was even like, yeah, thinkingmore granularly, for each one
of those tests you might have adifferent database server.
So I was really digging intothe architecture, but I think,
yeah, that's a great, greatexample of, like, what we want
Gen I to take us to.
Speaker 1 (24:14):
Yeah, yeah, I love the real world application there
.
I'm curious is that an actualreal world implementation, david
, that you've been working onwith clients?
Or maybe walk me through alittle bit about what you're
seeing in terms of adoption orwhere it actually sits in
reality in terms of making itsway into enterprise?
Speaker 4 (24:34):
So I am seeing that, but in pieces.
It's not all there yet, becausehealthcare has always been
behind purposely.
They're very risk averse in howthey bring technology, whereas
you know the likes of a Meta ora ChatGPT.
They're much more faster justbecause it's an interaction for
(24:55):
customers, it's a lot more freeflowing, whereas you know, like
if you look at healthcare andsomeone like finance sector,
they're a little bit more riskaverse, like they want to make
sure that the integration andthe technology actually don't
make mistakes.
You know, in making a decisionyou know, especially with the
(25:16):
genetic aspects of it.
So I think that's kind of, butI am seeing that progression, I
would say is just maybe a littlebit more time, and we are
working with a lot of customersthat are looking in that
direction, and so part of ourgroup, the AI advisory group, is
how do you take the generativeand the pre-generative AI to a
(25:40):
genetic and physical?
How do you make those steps?
And a lot of that comes back to.
One of the fundamental things ishow good is your data?
That's where it starts right.
How good are your tokens thatyou are measuring and processing
and how good is your inferencegoing to be?
But if your data quality ispoor and that's why you look at
(26:01):
Atom and Worldwide.
They've done such a great jobbecause the data is really good.
Right, the approach is alreadygood, so you can build things on
top of it, just like afoundation.
So that's kind of my feedback.
Speaker 1 (26:14):
Yeah, I like how you say you're starting to see it
more in the enterprise setting.
I'm curious of those earlyadopters, david.
Where are some of them findingyou know bits and pieces of
momentum and where are theyfaltering a little bit?
You know, what are some of thewarning signs that others should
be looking out for?
Speaker 4 (26:30):
I think, places where they're really looking to use
AR and using as one example wedrug discovery, like J&J AbbVie,
some of these companies, someof these companies.
This is where they're reallyputting especially new chemistry
, biochemistry designs, proteinstructure designs, drug
(26:53):
formulations.
They go to thousands andthousands of formulations and in
the past that would take months, years to develop this, and now
with the AI, especially withhow quickly you can generate new
ideas and designs, that's agreat acceleration.
That's happening right.
Is it in full blown, you knowprocess?
(27:16):
Not, but I think it's startingto get there, at least from a
healthcare standpoint.
Another area I would say islike supply chain you know what
I would call as finance area,like fraud detection, even like
telecommunications, with networkoperation centers Worldwide has
(27:38):
taken a great lead in that area, based on what I'm seeing.
So those are some of the areaswhere I've seen how AI can truly
be beneficial, and maybe Sallycan add what do you think are
some of the other things?
Speaker 3 (27:53):
Oh, I mean I was just going to say I mean, you know,
from my perspective, I work inmanagement consulting at WWT,
right, and I would agree 100%with those and especially, I
think, with, like you know,communications and just anyone
who's dealing with networks,predicting outages, that kind of
thing, summarizing that dataquickly.
That is somewhere where I havecertainly seen an uptick of
(28:17):
interest and potential adoptions.
Speaker 1 (28:21):
So I'm curious from an engineering perspective are
there any warning signs orhiccups or lessons learned that
clients, if they're lookingtowards adopting MCP or A2A,
that they should be aware of orlooking out for as they go along
that journey?
Speaker 3 (28:42):
Yeah.
So I would honestly go searchfor the.
There's like an eight minuteYouTube video about like MCP
Slack vulnerabilities and Iwould go check that out and see
how, like you know, there can bein a server especially if you
(29:03):
don't write it, then there canbe vulnerabilities.
You know, one of the advantagesis you can sort of take a
server anybody's written and nothave to write that code
yourself that integrates intothe tool you want.
The disadvantages if there's avulnerability in that tool then,
like you could be exposingpotential data and it wasn't
even malicious, right.
(29:23):
So I would say the very firstthing people should think about
is security and making sure thatthey have the resources to deal
with that correctly.
Speaker 4 (29:33):
Number one thing I would say Sally, I think that's
a great point and I think that'swhere you know what you know.
I've been in recent discussionswith NVIDIA and using their
kind of enterprise architectureframework right, they provide
the guardrails, they providedthe validation models, they're
(29:54):
providing the scalabilityelements.
You know how to structure thestorage and the models and all
of those things, and so you doneed a safe environment where
you could run this to kind ofprevent what Sally is kind of
mentioning.
Because, again, like I said,you know how do you know that
(30:16):
this model and this architectureand framework is secure?
Right, that's one of thecritical things that you have to
make sure it's right, and sothat means that you need to have
somebody, a third party, thatneeds to validate that or
provide some sort of a registryso that you know that's kind of
safe, you know.
So I think it's a great point,sally, that you're making.
Speaker 1 (30:48):
Yeah, I love the fact that you guys are bringing
security into the conversation.
Here Is it, and we can bringsecurity experts on and talk
about this if we'd like.
But just from your perspective,what security considerations
should we be talking about?
Is it back to the basics, justno access and visibility and
things like that?
Or what types of securitysolutions are needed?
Speaker 4 (31:14):
to make sure, david, to your point, that these are
running in a safe environment.
Well, I think you need to havethe general security of you know
making sure your datatransactions are encrypted in
some cases, because a lot of theinformation could be IP related
that you are trying to getresponses to.
You need to have guardrails sothat information doesn't get,
(31:39):
you know, pushed out into anarea of discussion that you're
not really supposed to talkabout or that the responses can
lead to other hacking.
You know efforts, right, and sothere's several types of
security at the basic level,your Internet security, and then
(32:00):
your you know, your promptsecurity or your LLM security,
other models in a valid state.
How were they trained?
You know what are the responses.
All of those things need to bekind of addressed as a whole,
holistic, but yeah, I thinkthat's what I'm looking at when
(32:23):
I look at a frameworkvulnerability I was talking
about, right, but something youknow.
Speaker 3 (32:30):
just to even add on to that, there's also just the
integration perspective ofsecurity.
So to go back to data'shealthcare database sort of
example, say, you know like adoctor has certain amounts of
(32:53):
access, or different doctorshave access to different you
know different databases basedon what they need, or something
like that.
So at the server level again,right, this is what's connecting
to each database in thisexample, each tool.
You'd want to make sure thatthe correct authentications are
leveraged for each server, andthere are an increasing number
(33:15):
of ways to do this.
But it's just something tothink about when you're building
is right, not just the securityto authenticate to the LLM
itself, but you know how can youmake sure that, like, this
person is authorized to accessthis particular tool, this
particular you know server?
So that's another considerationwhen you're integrating many
(33:36):
different things.
Speaker 4 (33:39):
Yeah, that's a great point, Sally.
Speaker 1 (33:41):
Yeah, and what brought that up?
You know, sally, your initialvulnerability was just talking
about.
You know, if you're not writingthe server, you're not exactly
sure you know what thevulnerability might be.
That makes me think are wegoing to have a whole kind of
server economy here, where a lotof you know there's gonna be a
lot of vendors or solutionproviders that are writing their
own servers?
Is that going to be somethingthat pops up, or is it already a
(34:02):
thing?
Speaker 3 (34:03):
it's, it's there, um, and there are a lot on the
internet.
I mean, I've, you know, I'veused a lot too and and, like I
said, there have been changes sothat now it's not they're,
they're not storing any of yourmetadata.
So I would say it's, if aserver is uh verified to you
know, uh, follow all the modelcontext protocol rules, it's,
(34:27):
it's safer to use now than itwas even like a few months ago,
right, but, um, uh, yeah, therethere already is an economy, but
at the same time, somethingelse that I've sort of seen and
this is sort of almost a segue,but it's like okay, like there
might be a server to interactwith this specific thing, but it
doesn't have the tools I need.
(34:47):
So I'm either going to need touse the tools it already has to
add it to the server, you know,customize it a little bit, or
something like that.
So I think that there's like alot of flexibility and
variability around that.
Speaker 4 (35:04):
And Sally, I think one thing I wanted to get your
perspective would be I thoughtthat also, obviously there are
going to be some sort ofstandards that are going to
start coming up with thesecurity side, right.
But I think explainability thatespecially with the Atom, how
it builds citations to specificinformation, that it pushes back
(35:26):
on the explainability aspect ofit, is a way to secure.
It's a secure design to mebecause if I just put in a
prompt and say hey, what's theanswer, it splits out an answer
but without any explainability.
That immediately you know Ineed to do more scrutiny around
it.
But if I had explainability,saying hey, here's my answer,
(35:48):
and these are the reasons why Icame up with the answers and
here's the citation to specificarticles or the database or a
customer ID or whatever it maybe, I think that builds more,
you know, secure elements to howI've designed the MCP, for that
matter, right, yeah, yeah, Ithink so.
Speaker 3 (36:10):
I think explainability is a really
important part of it.
I think that and again, as youwere the one to bring up
guardrails too super important.
You know, how do I know thatI'm not getting prompt
injections in this server?
I found, and those kinds ofthings, and maybe even honestly,
maybe a way to to test them,you know, before you plug them
(36:33):
into prod solutions.
I think that would be.
Or prod environments is intobroad solutions, I think, or
broad environments is, you knowsilo.
It put it in a Docker containeror some you know other
environment of your choice andmake sure it can't touch
anything and pass it out.
Speaker 1 (36:49):
Well, recognizing this is, you know, relatively
new still do we have.
Do most organizations have thepeople to manage this, or are
they going to need to train orhire, or is it something that
potentially I can do for itself?
Speaker 4 (37:06):
At least in my article.
That was one of the bigchallenges, honestly, is that
you know the architecture, theengine, the concepts and the
frameworks are there, but youalso need the appropriate
engineering teams that can putthis together.
So they do need to understandthe aspects of what does a
(37:28):
context management mean?
What does a vector databasemean?
You know how do I apply servers, how do I structure the servers
.
You know how do I implementagent-to-agent distributed
approaches.
You know you need to have theright workforce that understands
these concepts.
You know to be able to pullthis.
(37:50):
So it is a challenge that thecompanies will face as it starts
to progress.
Speaker 3 (37:57):
In my viewpoint, yeah , I mean, I think the solution
to this is just clone me severalthousand times and hire me at
every org.
I will.
I will say, though, you knowmore on a on a personal.
You know, note, as a machinelearning engineer, I started as
a data scientist.
(38:17):
I think it's a, it's a prettycommon path and you are seeing,
you know, note, as a machinelearning engineer, I started as
a data scientist.
I think it's a, it's a prettycommon path and you are seeing,
you know, there are definitelymany cases where you know having
a pure data scientist is superundervalued, someone who just
really knows models andalgorithms well.
But I think you are seeing moreof a shift towards many data
scientists getting better atlike sort of the engineering
(38:38):
side of things and many roles,looking for someone who can sort
of straddle the line, and Ithink that that, you know,
transition will also help.
What David's talking about isthat, like you know again, not
for everyone, but like sort ofright now, what I do in NL Ops
is very niche, and the lessniche it becomes, the better
prepared the workforce will beto sort of deal with this kind
(39:01):
of thing.
Speaker 1 (39:02):
Yeah, what about moving forward?
What's to say that there's notgoing to be another deep seek
moment or something similar thatwould put this all kind of
behind us?
Is this is MCP, agent to agent?
Is all this going to berelevant when the next big
rollout comes around, or is thisgoing to be a consistent part
of our future and strategy?
Speaker 3 (39:38):
kind of say.
I think the reason it mightstick around and I'd be
interested in David'sperspective is it's not truly,
you know, like it's not like amodel right, it's not like deep
seeks, a model and a differentway of making an LLM, it's just
a protocol, it's just astandardization.
So unless someone comes up witha better standardization and
then also generate the same kindof hype, and then also generate
the same kind of hype Like oneof the reasons MCP and A2A, like
(40:00):
what will make them successful,what's making them successful
so far, is that adoption right,Like that's the sort of soft
part of it that you have to getto get it to work too, because
what's the point in having astandard if no one's using it?
So from my perspective, I thinkthat that's a huge hurdle.
But I could certainly seethings you know what I don't
(40:21):
know, but things coming out that, like you know, takes away the
hype from them and makes it moreabout how do we integrate this
new thing with systems thatalready have those.
Speaker 4 (40:32):
But yeah, I would agree with you, sally.
I think I would say MCP willactually mature a lot.
You know, and we can see right,like the, you know, as you know
, you had the basic internet andthen you started to have web
websites and then you started tohave, you know, we started
(40:54):
moving to the artificialintelligence.
You know, we started moving tothe artificial intelligence and
then AlexNet came in 2012.
And that made a big shiftbecause of computer vision and
how it saw it, and now we are atthe NCP, after large language
models.
So what I would say is thatit's only going to mature and
become more and moresophisticated and intelligent.
(41:15):
Become more and moresophisticated and intelligent,
but there will definitely be, inmy viewpoint, the direction
into what they call as physicalAI that we are talking about.
And then the question reallycomes is how would we advance,
like sensors, for example,taking raw information that
you're seeing or hearing, orvisualizing, or you're sensing,
(41:39):
touch, smelling, all of thattype of raw physical data?
How do you channel that to thelikes of a large language model,
to the likes where?
How do you interpret thatinformation, which will become
key for AI to really succeed atthat next level which will
become key for AI to reallysucceed at that next level, and
(42:05):
it is only going to be seen.
But that's kind of how, where Isee the big transition and I
just don't know how quicklythat's going to happen.
And then you can also look atthe quantum computing aspect,
which how do you really kind ofscale that?
That's what the interestingaspect to be.
Once the quantum compute thinggets sophisticated, then it's
(42:27):
going to get implemented intothe AI and then what happens,
right, that's to be seen.
Speaker 1 (42:33):
Lots to consider moving forward.
I know we're running short ontime, David and Sally.
Thank you both so much fortaking the time out of your
schedules today to walk usthrough what I know is on top of
mind for many of our listenersout there today.
So thank you for joining.
Speaker 4 (42:48):
Sure absolutely.
Speaker 3 (42:51):
My pleasure, and I'd just like to give a really quick
shout out to our intern, vasuKhanna, who taught me a lot
about A2A and wrote a greatarticle on WWG's website about
it, so check it out.
Speaker 1 (43:02):
Absolutely Okay.
Before we sign off, there'sthree things I hope stick with
you from this conversation.
First, the handshake mattersmore than the hype.
Think of it this way MCP putsevery scrap of data and every
tool your company owns into thesame shaped box.
The A2A protocol is the courierservice that moves these boxes
(43:25):
between agents.
When those two standards click,you don't rewrite integrations,
you just pick a box, pick acourier and let the work move.
Second, security is a day zerodecision.
Sally's warning was blunt Anunvetted MCP server is basically
a vending machine for yourcrown jewel data.
Encrypt every hop, everysandbox and every log off that
(43:46):
they hand off.
And third, talent is the realthrottle.
The frameworks are here.
What most firms lack are theengineers who can wire them
together.
So start small one use case,one KPI and give your teams time
to learn the new plumbing.
That's it for the AI ProvingGround podcast this week.
This episode was co-produced byNaz Baker, mallory Schaffran
(44:09):
and Cara Kuhn.
Our audio and video engineer isJohn Knobloch and my name is
Brian Felt.
Thanks for listening and we'llsee you next time.
From Worldwide Technology.
This is the AI Proving Groundpodcast Today.
Two important breakthroughs youmay be unfamiliar with model
context, protocol andagent-to-agent communication,
and how they are quietlyrewriting the rules of
enterprise AI.
On paper, they're juststandards.
One shapes the data an AI cansee, the other lets teams of AIs
(00:23):
work together and hand thatdata back and forth, but in
practice, they decide whetheryour customer bot can tap into
real-time inventory system orwhether a factory robot can talk
to a quality control camerawithout tripping over compliance
rules.
To understand why this mattersand what happens when hundreds
of these servers and agentslight up inside a single company
(00:43):
, I sat down with SallyJankovich, an MLOps engineer,
and David Gedham, a senior AIadvisor.
Together, Sally and Davidjustify why, as AI systems get
smarter and start makingdecisions by themselves, why we
need new rule books like MCP andagent to agent, and what
problems they actually solve,both today and in the future.
(01:06):
This is the AI Proving Groundpodcast from Worldwide
Technology everything AI all inone place.
Let's get to it.
Hey Sally, hey David, Thanksfor joining us today on the AI
Proving Ground podcast.
How are the two of you?
(01:27):
Good, Excellent, Well, 2025 hasbeen billed the year of agentic
AI, and two methodologiesstarted to emerge.
We've been hearing a lot aboutit on previous episodes of the
AI Proving Ground podcast, andthat is model context protocol,
MCP or agent-to-agent protocolA2A.
(01:48):
Sally real quick.
Start us off, in case some ofour listeners out there aren't
familiar with either of thoseterms.
What is MCP, what is A2A, andwhy is it important to
understand it in today'ssomewhat chaotic AI landscape?
Speaker 3 (02:03):
Right, okay, so they're both different forms of
standardization, basically.
So the high level you can thinkabout is how do we standardize
how agents and by agent we meanan LLM that has access to other
tools, including API, apis andthat type of thing how do they
(02:25):
integrate into you knowenvironments and interact with
objects?
So MCP deals with when youthink about the objects the
agent is interacting with, it'sthose tool calls.
So it's a way of standardizinghow your agent plugs into a
specific tool in a way that ismodular and reusable.
(02:46):
So it was developed byAnthropic and I believe November
2024 it was released.
Since then it's taken off.
But essentially the reason it'staken off is once you write an
MCP server, they're called.
That's an integration of a toolinto your agent.
You can repeat that with otheragents and so it's just a really
(03:09):
nice modular way of plugging intools and also this means that
it's a lot easier to always knowhow your agent is going to take
in a tool if it's always in MCPformat.
Speaker 1 (03:23):
So, oh, go ahead.
A tool if it's always in MCPformat?
So oh, go ahead.
Yeah, and David, tell me abouthow they work together, if at
all, and what it enables the enduser or the end client to do.
Speaker 4 (03:37):
Yeah, so it's interesting.
I was actually looking at thehistory of MCP, right, and
before MCP, what people weredoing was, you know, when they
were chatting with LLMs, likethe chat GPT, they would start
adding context into the thingslike, hey, you know, I had a
conversation two weeks ago ortwo months ago about this.
(03:58):
You know, these are some of theother events that happened.
By the way, can you make abetter sense of this?
And that's where the wholecontext aspect started to get
designed.
And one of the other pre-MCPwas the language server protocol
, where these are the codingassistants that you're hearing
about, right, how do theycomplete a coding sentence?
(04:21):
Oh, because they're reading allthe programming languages and
they know how to construct itand then, therefore, they know
what the user is trying to dowith the code.
And that's kind of where theMCP at least that's a history.
And so, going back to why MCPand where I came in was how does
(04:42):
MCP and A2A start scaling thetransition to agentic AI and
physical AI, right?
How does this work?
Because right now, everythingwas about generative AI.
So that's where the connect is.
So MCP is standardizinginformation, as Sally mentioned.
But the second part of thatequation is how does the agent
(05:05):
take advantage of thatstandardization?
And so that's where the agents,if you design it properly, are
able to rationalize it, reasonand be able to come up with
autonomous decision making.
And that's kind of where theagentic or the A to A uh
protocol starts to take over.
So anyway, that's kind of myfeedback yeah, sally, how does
(05:28):
it?
Speaker 1 (05:28):
how does a to a start to take advantage of of that
standardization and what is thevalue of of that?
Speaker 3 (05:37):
yeah.
So, uh, I mean, david did agreat job of setting it up.
A to a is is very similar in insome ways to MCP.
It's not something that hasn'tbeen done before, it's just
being done in a standardized way.
So someone who has a bunch ofdifferent agents working on
different things say, one agentis helping you know customers
(06:01):
and then another agent is on theback end, sort of like the Atom
AI we have at WWT, and for somereason you want them to talk to
each other, or one has a taskthat it might pass off to the
other.
Then the A2A protocol basicallystandardizes how those two
agents would interact with oneanother.
You might have a third agent,your sort of head agent, that
(06:23):
you could talk to and say, hey,get this data from that agent,
or get this data from that agent, or have those two agents pass
data from one another.
So again, many engineerslistening to this will think, oh
, I had a setup like that before.
This is just the way tostandardize it.
Speaker 1 (06:39):
Yeah, appreciate the mention of Adam AI.
Just for those out there thatmay not be familiar, adam AI is
WWT's AI chatbot that we have onWWTcom.
It's available for all of ourinternal WWT users as well as
our external registered users.
So you could, as you'relistening to this, go out and
even type in at WWTcom what isMCP, what is A2A, and see what
(07:02):
you get.
There is A2A and see what youget there.
David, you know Sally hadmentioned that some of these
methodologies, while being usedfor a while, you know, really
started coming onto the scenejust recently I think you said
November 2024, at least for MCP.
Does that mean that it's justnow getting integrated into an
enterprise setting, or how areenterprises adopting these
technologies?
Speaker 4 (07:25):
or how are enterprises adopting these
technologies?
I think that, because of thekind of the starting you know,
like, generative AI has becomesuch a kind of natural way in
which people are interactingwith it.
Now, this is a naturaladvancement of that.
And how do you take thatnatural advancement and scale it
right?
And with the push of NVIDIA,with the agentic and the
(07:47):
physical, it becomes very, veryinteresting.
I see the MCP becoming thebrain of the agentic aspects.
Right now we're looking at,maybe task you know, automation,
right, like if you had acustomer service, sort of it's a
customer service that's tryingto automate.
(08:08):
Let's say, somebody calling youand trying to schedule a travel
or looking at booking yourtickets or things of that nature
.
Can I automate that?
Well, let's take it a stepfurther.
And now let's start to look atreal-time systems that actually
work in an assembly line orrobots, right when.
(08:31):
How do you think MCP could workin that in a real-time sense?
And so this aspect of how MCPis designed and the scaling I
mean, if you just look at themeta and the open AI releases,
they're talking about thousandsof MCP servers running
synchronously to directinformation into the engine so
(08:55):
that tasks can be automated.
I mean that's significant.
So I think it's a natural stateof scaling and that's what I'm
really interested about.
That's why I started looking atMCP.
Speaker 1 (09:08):
Yeah, Sally, it looked like you wanted to jump
in there for a second.
Speaker 3 (09:10):
Oh, I was just sort of agreeing well with David when
David said it was like sort ofa massive thing.
It's both massive from, like, aresults perspective and then
also like what that scalinglooks like, right, like I think
that's a really importantquestion to ask because, like
you know, from an engineeringperspective, as someone I've,
you know, built, uh, you know,some baby mcp servers and it has
(09:34):
come a long way in the pastlike eight months for sure
things are improving.
Uh, there are still things thatyou know, um, in terms of scale
, right like a server is goingto be limited by the strength of
, like, the LLM you're using,because it might only be able to
call so many servers at once.
So there's a lot of differentinteresting limiting factors
(09:54):
when you're thinking aboutgetting to that point that David
is talking about.
But I think that that's where,now that the main buzz of MCP
has sort of begun to pass,that's where the work has been
going.
Speaker 4 (10:08):
And Sally, I had a question for you.
You know, from an engineeringstandpoint Obviously I'm sitting
at the use case, developmentand ROI how does it benefit a
customer in bringing an MCP typesolution?
A question for you would be,when I started looking at the
design that Meta and Google andAzure how they're looking to
(10:31):
architect it.
Right, some of thearchitectures are a little bit
different than others.
One of the things that I have aquestion is about the memory
management of this context,right, how much of a memory they
want to place, how fast theywant to have that in-memory.
You know, from an accessstandpoint, from an inferencing
(10:52):
standpoint, what do you thinkabout how that would be designed
from a dynamic and staticcontext management?
Speaker 3 (11:01):
Yeah, I mean, I think again it's you know the answer,
is it really right?
It's going to depend sort of onyour use case and on your goals
.
And when I say on your use case, part of it is going to depend
on, like, okay, like, how manyservers are you calling and then
how many tools does each serverhave?
(11:21):
Because you know, the more youhave, like, probably the more
memory you're going to want.
And essentially also right,like again, you are really
limited by your, your LLMs, incertain cases.
So I'd almost argue, you know Ihaven't looked too deeply into
those architectures, but thismight be a place where I would
(11:44):
want to use A to A and insteadof trying to, you know, scale
horizontally, see how many toolsand servers you know I could
pack in, see how much.
I would almost say, well, whycan't we have one agent have
this specific task and thisagent have this specific task,
and sort of link it out morehorizontally?
So you're sort of spreading outthe tasks you're trying to do.
Speaker 4 (12:16):
It's like a distributed kind of approach.
Yeah, yeah.
Speaker 3 (12:20):
Yeah, as an engineer, when you're dealing with, I
have to keep increasing memoryover and over again, whether you
do it the way I suggested oranother way.
The first question is how can Imake what's a vertical scaling
problem become horizontal?
Speaker 4 (12:38):
Yeah, I think that totally makes sense.
Speaker 1 (12:46):
so I'm hearing you both mention servers, um, often.
So how much, how, how much morecompute is necessary here?
How much more cost is thisgoing to add if we're talking
about dozens, hundreds orthousands of of servers need it
to uh to to execute this, thisstrategy?
Speaker 3 (13:12):
So, oh.
So, to sort of uh backtrack andmake sure I clearly defined
what a server is in an MCPcontext, right, that is the sort
of package that contains allthe connections to the tools.
So, um, you might have like a,a server that you know connects
to a Postgres database that'sjust a SQL database and it might
have different tools fordifferent queries, different,
(13:33):
you know, calls you want to run.
It might, you know, it mightjust have a general query tool,
a specific query tool, an addrows tool, whatever it is, and
so those tools would all bepacked into a server.
And so when I'm thinking aboutcompute, you know I guess
(13:54):
there's like the compute that'sthe server is running, and then
there's also the compute at theLLN is running in order to talk
to all of these things.
So it's almost it's a trickything to talk about, right,
because, yes, if you're runninga bunch of different processes
on a bunch of different servers,you're using all of that
compute.
But then also you know the morecomplicated of a network you
have.
If you have a bunch of agentstalking to each other, those are
(14:17):
tons of LLM calls you're sortof generating, and so that is a
downside of like one of thesolutions I proposed.
I don't know if you haveanything to add to that, david.
I mean.
Speaker 4 (14:25):
what I would add in that just giving a perspective
would be is that it would besomething like if you look at
Adam just getting back to Adam,right, so Adam is now connected
into Salesforce.
It's connected into ServiceNow.
It's connected into ServiceNow.
It's connected into all theother information repositories
(14:54):
at Worldwide, our platform, ourweb pages, all of that, right?
So the point that Sally ismaking is those are servers in a
virtual sense, but they reallydon't take the type of compute
that you may be thinking about,the type of compute that you may
be thinking about.
Where the compute really comesin, my viewpoint, would be the
memory allocation to actuallygenerate the context, in this
case, the vector databases whereyou're storing the vector
(15:17):
representations of thisinformation so you can quickly
search a semantic, like theFacebook similarity search, as
an example, and some of theother vector searches, your RAG
applications.
Those are where the compute.
And then when you look at aBlackwell architecture, right,
why does a Blackwellarchitecture start to benefit is
(15:38):
because of all the networkingcapabilities from GPU to GPU,
rack to rack, networkingcapabilities from GPU to GPU,
rack to rack.
You know all of those things.
That's where the compute reallywould speed up the response of
the system, and hopefully I'mmaking sense there, sally.
So that's kind of what I'mthinking.
Speaker 3 (15:55):
I think you said that far more specifically and
eloquently than I did, so reallythat's a really good breakdown,
I think, of where the computeis really coming in.
But, just to hammer in on thatpoint from what David is saying
then the more servers andvarious integrations you're
(16:15):
adding and those types of things, that's where the compute is
scaling up.
So I do think, like I wouldn'tsay it's linear, but, yes, the
more integrations you have,because of all the things that
David mentioned, you're going toneed more of those to support
your application and that'swhere, yeah, the size does
balloon.
Speaker 1 (16:36):
Yeah, so I do want to talk a little bit more about
integration and, david, feelfree to weigh in as well.
Where does MCP and A2A fitalongside existing?
You know how enterprise ITteams support AI Like.
What does this do in terms ofyou know some of the API
gateways that we've been using?
Does it sit alongside, does itreplace?
Are we talking somethingdifferently or is it a
(16:58):
disruption?
Speaker 3 (16:59):
Yeah, I wouldn't say it's a disruption.
I would say that there is goingto always be.
Something I would encourage allenterprises to think about is
there's going to be some initiallift, because likely you
already have agents that knowhow to call tools, and
integrating an MCP server isgoing to rip out some of that.
(17:21):
But that initial that's like aninitial down payment, basically
, because once you sort of haveyour agents running so that they
can talk to other agents or sothat they can call other MCP
servers, then it's much, mucheasier to integrate from then on
.
So like there's a high lift atfirst, but then I think it goes
(17:42):
much better from there and thenalso then I think it goes much
better from there.
And then also I think that thegateway end if your gateway is
calling an agent, right, likethat integration shouldn't be
touched at all.
So yeah, I would say if you'reinterested in integrating it,
you should be prepared for timeto be upfront.
That's the cost and then it'llsave you tons of time on the
(18:03):
backend.
That's the cost and then it'llsave you tons of time on the
back end and up front what needsto be taken into consideration
by some of our clientorganizations or any
organization for that matterlooking to explore these
methodologies.
Yeah, so there's a few.
(18:34):
One, like I said before, likeyou're just going to actually
have code based changes andthat's going to take time and
you want to test anything that'sgoing into production
rigorously.
I think another thing to beconcerned about and thoughtful
about is, you know, security.
These are very new practices,and so I know that MCP and
Anthropic, who again is behindMCP, has just been coming up
with.
You know better ways of runningservers, so, for example, they
don't store your metadata andthings like that.
But there also have beenvulnerabilities in certain
servers, like the Slack one, soyou would want to like sort of
(18:55):
evaluate those things, make surethat the tools that you're
implementing also are actuallyauthenticated properly.
That's going to be a little bitof a bigger lift up front as
well.
So, um, just just for inregards to that like production
level, like we can actually putthis out in the public and it
won't leak our secrets, kind ofthing, there's gonna be a little
(19:16):
bit of a lift there too, butit's already.
From when I uh first startedthinking about mcp to now it's
already gotten a lot better, soI can only see that improving.
Speaker 2 (19:27):
This episode is supported by Glean.
Glean is the work AI platformthat connects and understands
all your enterprise data togenerate trusted answers and
automate work grounded incompany knowledge.
Put AI to work at work.
Speaker 4 (19:41):
I do want to kind of come back to the
interoperability question, right, I mean, the reality of all of
this, right, and Sally can kindof chime into it is that we live
there.
Legacy systems are going to bethere, right?
It's not like just because webrought in MCP, suddenly we lose
all the legacy information.
So the way I see MCP is, it'sactually to the advantage that
(20:02):
it's a great interoperabilitysort of platform, right, so you
can connect legacy informationas well as brand new information
repositories together, and thatreally benefits, if designed
correctly, can benefit theorganization tremendously.
And I'll you know, mybackground is I've been in 30
(20:23):
years in healthcare, designingpicture archival systems,
quality management systems,enterprise document systems, all
of these things.
And so when I look at NCP I'mlike, oh my God, how great would
it be to connect all of thisinformation set, because at the
end of the day they're all anecosystem that has some relation
(20:46):
from one to the other.
And if you just look at aclinical IT example in a
healthcare organization, right,a patient walks in and you know,
for some reason they're havinga problem, right, so you get a
diagnostic.
Right, you get a diagnostic orthe image that then goes into
the picture archive.
Well, then the physician mayask for a blood test, and they
(21:09):
may ask for this.
Then they have an electronichealth record and then they have
a visitation appointment as towhat's happening next.
Then they have a drug that isprovided to them, so that's a
pharmacy.
It to them right?
So that's a pharmacy.
So when you look at all of thisinformation, they're all
disparate information butthey're all connected to the
patient, to the physician, tothe administration, to the
(21:32):
insurance.
All of this, well, if I had anMCP, well, if I structure the
interoperability correctly, Ican query all of that in a
fairly quickly manner withouthaving to take a time Like it's
very siloed today.
So these MCP and agent to agentcan really help not only bring
(21:53):
structure standardization butalso the quickness, the
automation to get the patient,at the end of the day, the right
medicine at the right time.
So that's how I look at it.
Speaker 3 (22:05):
I think, yeah, I think your vision is the correct
one.
Maybe if we even wanted to diginto that a little bit, david,
and like talk through what thatwould even look like as an
example, right, like.
So, like you're talking aboutlike there's tons of different
systems you might need to queryand stuff, so you know you can
think of each database as itsown server with its own
integration and then maybeorganizing, you know, on a
(22:29):
larger level you'll havedifferent, maybe different
agents have access to certaindifferent databases and then
connecting them all with onehost agent that can talk to each
one of them.
Speaker 4 (22:40):
Absolutely Like.
So if you look at theelectronic health record system
like Epic, for example, it'sstill pretty siloed, even though
information is prettystandardized in them Right now.
The way I see Epic, for example, is you can search information,
whether it's an x-ray, whetherit's a blood test, whether it's
a lab, whether it's genetics,all of that right, the true
(23:02):
aspect of NCP.
And then AI starts to come in.
What if the physician, justbefore seeing the patient, runs
a query and a prompt saying, hey, what is going on with the
patient and what's his history?
And immediately it brings abouta very summarized thing saying
hey, you know, 10 years ago theyhad an accident or whatever you
(23:22):
know, they came in, they did ablood test.
These are current stats.
By the way, they have awearable monitor and so far we
don't see any problems.
So here is some of thesuggestion based on the large
image models are already trainedwith that data.
You're giving context to themodel, context and then you get
the answer.
And, by the way, now here's aprescription already.
(23:45):
Here is the next steps, here isthe next steps, here is the
next appointment, you know, twomonths down the line.
Wow, like like.
You're really starting to talkabout efficiency there.
Speaker 3 (23:54):
I kind of sound like what you were thinking, sorry.
Yes, yeah, exactly, exactly.
I was even like, yeah, thinkingmore granularly, for each one
of those tests you might have adifferent database server.
So I was really digging intothe architecture, but I think,
yeah, that's a great, greatexample of, like, what we want
Gen I to take us to.
Speaker 1 (24:14):
Yeah, yeah, I love the real world application there
.
I'm curious is that an actualreal world implementation, david
, that you've been working onwith clients?
Or maybe walk me through alittle bit about what you're
seeing in terms of adoption orwhere it actually sits in
reality in terms of making itsway into enterprise?
Speaker 4 (24:34):
So I am seeing that, but in pieces.
It's not all there yet, becausehealthcare has always been
behind purposely.
They're very risk averse in howthey bring technology, whereas
you know the likes of a Meta ora ChatGPT.
They're much more faster justbecause it's an interaction for
(24:55):
customers, it's a lot more freeflowing, whereas you know, like
if you look at healthcare andsomeone like finance sector,
they're a little bit more riskaverse, like they want to make
sure that the integration andthe technology actually don't
make mistakes.
You know, in making a decisionyou know, especially with the
(25:16):
genetic aspects of it.
So I think that's kind of, butI am seeing that progression, I
would say is just maybe a littlebit more time, and we are
working with a lot of customersthat are looking in that
direction, and so part of ourgroup, the AI advisory group, is
how do you take the generativeand the pre-generative AI to a
(25:40):
genetic and physical?
How do you make those steps?
And a lot of that comes back to.
One of the fundamental things ishow good is your data?
That's where it starts right.
How good are your tokens thatyou are measuring and processing
and how good is your inferencegoing to be?
But if your data quality ispoor and that's why you look at
(26:01):
Atom and Worldwide.
They've done such a great jobbecause the data is really good.
Right, the approach is alreadygood, so you can build things on
top of it, just like afoundation.
So that's kind of my feedback.
Speaker 1 (26:14):
Yeah, I like how you say you're starting to see it
more in the enterprise setting.
I'm curious of those earlyadopters, david.
Where are some of them findingyou know bits and pieces of
momentum and where are theyfaltering a little bit?
You know, what are some of thewarning signs that others should
be looking out for?
Speaker 4 (26:30):
I think, places where they're really looking to use
AR and using as one example wedrug discovery, like J&J AbbVie,
some of these companies, someof these companies.
This is where they're reallyputting especially new chemistry
, biochemistry designs, proteinstructure designs, drug
(26:53):
formulations.
They go to thousands andthousands of formulations and in
the past that would take months, years to develop this, and now
with the AI, especially withhow quickly you can generate new
ideas and designs, that's agreat acceleration.
That's happening right.
Is it in full blown, you knowprocess?
(27:16):
Not, but I think it's startingto get there, at least from a
healthcare standpoint.
Another area I would say islike supply chain you know what
I would call as finance area,like fraud detection, even like
telecommunications, with networkoperation centers Worldwide has
(27:38):
taken a great lead in that area, based on what I'm seeing.
So those are some of the areaswhere I've seen how AI can truly
be beneficial, and maybe Sallycan add what do you think are
some of the other things?
Speaker 3 (27:53):
Oh, I mean I was just going to say I mean, you know,
from my perspective, I work inmanagement consulting at WWT,
right, and I would agree 100%with those and especially, I
think, with, like you know,communications and just anyone
who's dealing with networks,predicting outages, that kind of
thing, summarizing that dataquickly.
That is somewhere where I havecertainly seen an uptick of
(28:17):
interest and potential adoptions.
Speaker 1 (28:21):
So I'm curious from an engineering perspective are
there any warning signs orhiccups or lessons learned that
clients, if they're lookingtowards adopting MCP or A2A,
that they should be aware of orlooking out for as they go along
that journey?
Speaker 3 (28:42):
Yeah.
So I would honestly go searchfor the.
There's like an eight minuteYouTube video about like MCP
Slack vulnerabilities and Iwould go check that out and see
how, like you know, there can bein a server especially if you
(29:03):
don't write it, then there canbe vulnerabilities.
You know, one of the advantagesis you can sort of take a
server anybody's written and nothave to write that code
yourself that integrates intothe tool you want.
The disadvantages if there's avulnerability in that tool then,
like you could be exposingpotential data and it wasn't
even malicious, right.
(29:23):
So I would say the very firstthing people should think about
is security and making sure thatthey have the resources to deal
with that correctly.
Speaker 4 (29:33):
Number one thing I would say Sally, I think that's
a great point and I think that'swhere you know what you know.
I've been in recent discussionswith NVIDIA and using their
kind of enterprise architectureframework right, they provide
the guardrails, they providedthe validation models, they're
(29:54):
providing the scalabilityelements.
You know how to structure thestorage and the models and all
of those things, and so you doneed a safe environment where
you could run this to kind ofprevent what Sally is kind of
mentioning.
Because, again, like I said,you know how do you know that
(30:16):
this model and this architectureand framework is secure?
Right, that's one of thecritical things that you have to
make sure it's right, and sothat means that you need to have
somebody, a third party, thatneeds to validate that or
provide some sort of a registryso that you know that's kind of
safe, you know.
So I think it's a great point,sally, that you're making.
Speaker 1 (30:48):
Yeah, I love the fact that you guys are bringing
security into the conversation.
Here Is it, and we can bringsecurity experts on and talk
about this if we'd like.
But just from your perspective,what security considerations
should we be talking about?
Is it back to the basics, justno access and visibility and
things like that?
Or what types of securitysolutions are needed?
Speaker 4 (31:14):
to make sure, david, to your point, that these are
running in a safe environment.
Well, I think you need to havethe general security of you know
making sure your datatransactions are encrypted in
some cases, because a lot of theinformation could be IP related
that you are trying to getresponses to.
You need to have guardrails sothat information doesn't get,
(31:39):
you know, pushed out into anarea of discussion that you're
not really supposed to talkabout or that the responses can
lead to other hacking.
You know efforts, right, and sothere's several types of
security at the basic level,your Internet security, and then
(32:00):
your you know, your promptsecurity or your LLM security,
other models in a valid state.
How were they trained?
You know what are the responses.
All of those things need to bekind of addressed as a whole,
holistic, but yeah, I thinkthat's what I'm looking at when
(32:23):
I look at a frameworkvulnerability I was talking
about, right, but something youknow.
Speaker 3 (32:30):
just to even add on to that, there's also just the
integration perspective ofsecurity.
So to go back to data'shealthcare database sort of
example, say, you know like adoctor has certain amounts of
(32:53):
access, or different doctorshave access to different you
know different databases basedon what they need, or something
like that.
So at the server level again,right, this is what's connecting
to each database in thisexample, each tool.
You'd want to make sure thatthe correct authentications are
leveraged for each server, andthere are an increasing number
(33:15):
of ways to do this.
But it's just something tothink about when you're building
is right, not just the securityto authenticate to the LLM
itself, but you know how can youmake sure that, like, this
person is authorized to accessthis particular tool, this
particular you know server?
So that's another considerationwhen you're integrating many
(33:36):
different things.
Speaker 4 (33:39):
Yeah, that's a great point, Sally.
Speaker 1 (33:41):
Yeah, and what brought that up?
You know, sally, your initialvulnerability was just talking
about.
You know, if you're not writingthe server, you're not exactly
sure you know what thevulnerability might be.
That makes me think are wegoing to have a whole kind of
server economy here, where a lotof you know there's gonna be a
lot of vendors or solutionproviders that are writing their
own servers?
Is that going to be somethingthat pops up, or is it already a
(34:02):
thing?
Speaker 3 (34:03):
it's, it's there, um, and there are a lot on the
internet.
I mean, I've, you know, I'veused a lot too and and, like I
said, there have been changes sothat now it's not they're,
they're not storing any of yourmetadata.
So I would say it's, if aserver is uh verified to you
know, uh, follow all the modelcontext protocol rules, it's,
(34:27):
it's safer to use now than itwas even like a few months ago,
right, but, um, uh, yeah, therethere already is an economy, but
at the same time, somethingelse that I've sort of seen and
this is sort of almost a segue,but it's like okay, like there
might be a server to interactwith this specific thing, but it
doesn't have the tools I need.
(34:47):
So I'm either going to need touse the tools it already has to
add it to the server, you know,customize it a little bit, or
something like that.
So I think that there's like alot of flexibility and
variability around that.
Speaker 4 (35:04):
And Sally, I think one thing I wanted to get your
perspective would be I thoughtthat also, obviously there are
going to be some sort ofstandards that are going to
start coming up with thesecurity side, right.
But I think explainability thatespecially with the Atom, how
it builds citations to specificinformation, that it pushes back
(35:26):
on the explainability aspect ofit, is a way to secure.
It's a secure design to mebecause if I just put in a
prompt and say hey, what's theanswer, it splits out an answer
but without any explainability.
That immediately you know Ineed to do more scrutiny around
it.
But if I had explainability,saying hey, here's my answer,
(35:48):
and these are the reasons why Icame up with the answers and
here's the citation to specificarticles or the database or a
customer ID or whatever it maybe, I think that builds more,
you know, secure elements to howI've designed the MCP, for that
matter, right, yeah, yeah, Ithink so.
Speaker 3 (36:10):
I think explainability is a really
important part of it.
I think that and again, as youwere the one to bring up
guardrails too super important.
You know, how do I know thatI'm not getting prompt
injections in this server?
I found, and those kinds ofthings, and maybe even honestly,
maybe a way to to test them,you know, before you plug them
(36:33):
into prod solutions.
I think that would be.
Or prod environments is intobroad solutions, I think, or
broad environments is, you knowsilo.
It put it in a Docker containeror some you know other
environment of your choice andmake sure it can't touch
anything and pass it out.
Speaker 1 (36:49):
Well, recognizing this is, you know, relatively
new still do we have.
Do most organizations have thepeople to manage this, or are
they going to need to train orhire, or is it something that
potentially I can do for itself?
Speaker 4 (37:06):
At least in my article.
That was one of the bigchallenges, honestly, is that
you know the architecture, theengine, the concepts and the
frameworks are there, but youalso need the appropriate
engineering teams that can putthis together.
So they do need to understandthe aspects of what does a
(37:28):
context management mean?
What does a vector databasemean?
You know how do I apply servers, how do I structure the servers
.
You know how do I implementagent-to-agent distributed
approaches.
You know you need to have theright workforce that understands
these concepts.
You know to be able to pullthis.
(37:50):
So it is a challenge that thecompanies will face as it starts
to progress.
Speaker 3 (37:57):
In my viewpoint, yeah , I mean, I think the solution
to this is just clone me severalthousand times and hire me at
every org.
I will.
I will say, though, you knowmore on a on a personal.
You know, note, as a machinelearning engineer, I started as
a data scientist.
(38:17):
I think it's a, it's a prettycommon path and you are seeing,
you know, note, as a machinelearning engineer, I started as
a data scientist.
I think it's a, it's a prettycommon path and you are seeing,
you know, there are definitelymany cases where you know having
a pure data scientist is superundervalued, someone who just
really knows models andalgorithms well.
But I think you are seeing moreof a shift towards many data
scientists getting better atlike sort of the engineering
(38:38):
side of things and many roles,looking for someone who can sort
of straddle the line, and Ithink that that, you know,
transition will also help.
What David's talking about isthat, like you know again, not
for everyone, but like sort ofright now, what I do in NL Ops
is very niche, and the lessniche it becomes, the better
prepared the workforce will beto sort of deal with this kind
(39:01):
of thing.
Speaker 1 (39:02):
Yeah, what about moving forward?
What's to say that there's notgoing to be another deep seek
moment or something similar thatwould put this all kind of
behind us?
Is this is MCP, agent to agent?
Is all this going to berelevant when the next big
rollout comes around, or is thisgoing to be a consistent part
of our future and strategy?
Speaker 3 (39:38):
kind of say.
I think the reason it mightstick around and I'd be
interested in David'sperspective is it's not truly,
you know, like it's not like amodel right, it's not like deep
seeks, a model and a differentway of making an LLM, it's just
a protocol, it's just astandardization.
So unless someone comes up witha better standardization and
then also generate the same kindof hype, and then also generate
the same kind of hype Like oneof the reasons MCP and A2A, like
(40:00):
what will make them successful,what's making them successful
so far, is that adoption right,Like that's the sort of soft
part of it that you have to getto get it to work too, because
what's the point in having astandard if no one's using it?
So from my perspective, I thinkthat that's a huge hurdle.
But I could certainly seethings you know what I don't
(40:21):
know, but things coming out that, like you know, takes away the
hype from them and makes it moreabout how do we integrate this
new thing with systems thatalready have those.
Speaker 4 (40:32):
But yeah, I would agree with you, sally.
I think I would say MCP willactually mature a lot.
You know, and we can see right,like the, you know, as you know
, you had the basic internet andthen you started to have web
websites and then you started tohave, you know, we started
(40:54):
moving to the artificialintelligence.
You know, we started moving tothe artificial intelligence and
then AlexNet came in 2012.
And that made a big shiftbecause of computer vision and
how it saw it, and now we are atthe NCP, after large language
models.
So what I would say is thatit's only going to mature and
become more and moresophisticated and intelligent.
(41:15):
Become more and moresophisticated and intelligent,
but there will definitely be, inmy viewpoint, the direction
into what they call as physicalAI that we are talking about.
And then the question reallycomes is how would we advance,
like sensors, for example,taking raw information that
you're seeing or hearing, orvisualizing, or you're sensing,
(41:39):
touch, smelling, all of thattype of raw physical data?
How do you channel that to thelikes of a large language model,
to the likes where?
How do you interpret thatinformation, which will become
key for AI to really succeed atthat next level which will
become key for AI to reallysucceed at that next level, and
(42:05):
it is only going to be seen.
But that's kind of how, where Isee the big transition and I
just don't know how quicklythat's going to happen.
And then you can also look atthe quantum computing aspect,
which how do you really kind ofscale that?
That's what the interestingaspect to be.
Once the quantum compute thinggets sophisticated, then it's
(42:27):
going to get implemented intothe AI and then what happens,
right, that's to be seen.
Speaker 1 (42:33):
Lots to consider moving forward.
I know we're running short ontime, David and Sally.
Thank you both so much fortaking the time out of your
schedules today to walk usthrough what I know is on top of
mind for many of our listenersout there today.
So thank you for joining.
Speaker 4 (42:48):
Sure absolutely.
Speaker 3 (42:51):
My pleasure, and I'd just like to give a really quick
shout out to our intern, vasuKhanna, who taught me a lot
about A2A and wrote a greatarticle on WWG's website about
it, so check it out.
Speaker 1 (43:02):
Absolutely Okay.
Before we sign off, there'sthree things I hope stick with
you from this conversation.
First, the handshake mattersmore than the hype.
Think of it this way MCP putsevery scrap of data and every
tool your company owns into thesame shaped box.
The A2A protocol is the courierservice that moves these boxes
(43:25):
between agents.
When those two standards click,you don't rewrite integrations,
you just pick a box, pick acourier and let the work move.
Second, security is a day zerodecision.
Sally's warning was blunt Anunvetted MCP server is basically
a vending machine for yourcrown jewel data.
Encrypt every hop, everysandbox and every log off that
(43:46):
they hand off.
And third, talent is the realthrottle.
The frameworks are here.
What most firms lack are theengineers who can wire them
together.
So start small one use case,one KPI and give your teams time
to learn the new plumbing.
That's it for the AI ProvingGround podcast this week.
This episode was co-produced byNaz Baker, mallory Schaffran
(44:09):
and Cara Kuhn.
Our audio and video engineer isJohn Knobloch and my name is
Brian Felt.
Thanks for listening and we'llsee you next time.
Popular Podcasts
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.