Welcome back everyone to day two of the
Kaggle and Google five days AI agents
intensive course. I'm Smita Kolli,
senior developer relations engineer at
Google Cloud, and I'm here again with
Anant Nawalgaria. Anant, welcome back.
Hi everyone.
I haven't seen you all since yesterday.
Uh thanks for joining and looking
forward to taking you through the rest
of the course.
Good to see everyone again. I see some
folks from yesterday already in the
chat, and if you're new and just joining
us, welcome. Drop in the chat what was
your best takeaway from day one was. We
would love to hear it.
All right. To get started, let's
actually do a quick overview.
So, throughout the week, you will get
white papers, companion podcast,
hands-on code labs, daily live streams,
and AMAs just like this one. And also,
an optional capstone project at the end
where you can compete for Kaggle
certificates, badges, swag, and
recognition across Kaggle and Google's
social channels. So, if you have
registered for the course, the content
will actually land directly in your
inbox. If not, everything is actually
going to be on the Kaggle learner
portal, and it will be announced in
Discord as well.
Also, before I forget,
quick thanks to everyone who put this
together, the Google researchers and
engineers who wrote the white papers,
the speakers joining us this week, and
also the amazing Discord moderators who
have been answering questions non-stop.
They are truly heroes.
And before we proceed, uh Smita, I
wanted to add on something. We have seen
a lot of you uh having an
um token quota um
restrictions, and as we communicated, um
since the the free quota is limited, and
a lot of you will have these issues as
you proceed across the code labs.
However,
even though the course material is no
cost and free like all the white papers,
the podcast, etc. If you if you'd like
to go through all the code labs without
hassle,
you you can choose to upgrade to the
paid version for the
if you'd like to. The course material is
free. However,
the free quota is limited so
you you can if you'd like to make the
most you can choose to do so or do so
do so next week when the quota is
refreshed.
Awesome. Okay.
So, let's actually get into day two.
Yesterday, we covered what an agent
actually is and the shift from writing
syntax to expressing intent. Today is
all about the layer that makes agents
actually useful.
How they connect to tools, to other
agents, and to the rest of the world.
So,
here's the problem the white paper
actually opens with and it's actually
worth thinking about for a second. Say
you have a handful of different models,
Gemini or maybe an open source model or
whatever you're using and you want them
to work with a handful of tools like
Jira, BigQuery, GitHub, or even your own
APIs.
The traditional way is to actually wire
this up in one custom integration, you
know, per per model tool pair. So, for
example, five models and 10 tools, you
would have to write 50 integrations to
write and maintain and all of that. But
when anyone's tools API actually changes
or multiple integrations can actually
break all at once. So, that's the
technical debt that the protocols that
we're going to be talking about today
are actually designed to eliminate. The
white paper today is really about to
tell you how you can get out of that
trap. It walks through
a set of open protocols that actually
standardize how agents connect to tools,
to other agents, to user interfaces, and
even to payment systems. So, Anand, do
you want to walk us through the white
paper in more detail?
Yes, thank you, Smitha. And hi,
everyone.
I hope you've had the chance to go
through the white paper, the new white
paper for day two. Please bear in mind
that these the white papers for this
iteration are
more white coding adjusted and specific,
but if you'd like to go through general
agent building, and especially
how agents are built without the white
coding aspect, we have also linked in
the FAQ the updates to the order white
papers from the last iteration with the
newest content and tech. So, right.
Starting off with the white paper for
today, the new white paper, which is
titled Agent Tools and Interoperability
for white coding. So, in yesterday in
yesterday's white paper, we established
how the software development life cycle
is shifting from manual syntax
translation to expressing pure intent in
natural language under the core and
architectural formula, agent is equal to
model plus harness, where the harness
plays a very major role in making all of
this happen, especially for AI-assisted
coding.
Today, in today's white papers, we
explored the industry standards that
allow our agents to safely talk to the
rest of the world. First, as Smitha
mentioned, we tackled the N-into-M
prototyping crisis. So, if you have N
models and M tools, like the five and 10
as Smitha mentioned, that leads to all
N-into-M integrations, which is like 15
in this case, but can easily blow up as
you can imagine.
And this is especially important when
your coding agent, etc., connect to lots
of external tools and MCP servers. And
then we in the later on the white paper
we showed how the MCP um or or the model
context protocol or MCP acts like the
USB-C for tool connections, reducing
that complexity that N into M complexity
to a clean linear O N plus M scale using
uh standard transports like STD uh input
output as well as
uh uh server-sent events or SSE. Later
on in the second section of the white
paper, we also look at the evolution of
agent architecture. Just like web
applications moved from monoliths to
microservices, we are moving away from
bloated single agent monoliths to
distributed multi-agent networks. You
also see that in some of the if you have
tried out the code labs and the gravity
is a multi-agent system behind the
scenes. And as well as the ambient
agents that you can build with uh uh
with with multi-agent system
architecture. We also broke down the
agent-to-agent or A2A protocol. This is
an open standard designed to serve as a
universal language for specialized
agents to coordinate and discover each
other via registries and then delegate
tasks using machine-readable agent
cards.
We also demonstrated agent-to-UI or A2UI
in short. Uh
personally, I think this is a
game-changing open-source standard that
allows agents to output interactive user
interfaces dynamically and safely
specific to um the the need of the the
the user instead of having one static
interface and using trusted component
catalogs instead of just running
arbitrary code. Finally, we cover
autonomous commerce. We also talk about
universal commerce protocol or UCP as
it's well known and how it helps agents
build shopping carts while the agent
payment protocol or AP2 acts as a secure
payment gateway applying strict human uh
sign mandates so your agent never
overspends or minimize chances of
overspending. So yeah, we covered a lot
in this uh white paper. So hopefully you
had a chance to play with the code labs
and read through the white papers off to
you Smitha to the exciting QA.
Uh thank you, Anant. And also same tip
as what we mentioned yesterday, if you
haven't already, the podcast is actually
a really great entry point before you
dive into the white paper.
With that said, let's head on over into
the QA.
So, we have some really amazing expert
hosts on the panel today. We have Alan,
Kanchana, Mike, and Pierre from Cloud
AI. And let's actually now get into the
questions.
Welcome, everyone. How are you guys
feeling?
Feeling great. Excited to be here.
Awesome.
So, uh, Mike, this question is for you.
Uh, how is Google Cloud lowering the
barrier for developers to integrate open
protocols like MCP and A2A, just like we
I had mentioned in the summary,
into production cloud stacks, and what
do you see as their long-term future?
Yeah. Uh, before I answer the question,
you thanked everybody else, and I want
to thank you, Anant and Smitha, for
doing such a great job pulling this
together this week.
It, uh, means a lot to us at Google and
the whole community, everything that
you've been doing. So,
in the same way that Google's putting
these protocols out there, you're
putting a lot of knowledge out there.
So, thank you for that.
Um,
I think in the same way, like if you go
back in time to the origins of the
internet, the same way that protocols
like TCP and UDP UDP became the
ingredients
and the standards by which so many
things run on top of, and everything
since, it's very much the same way that
we at Google have been trying to invest
and work with the rest of the industry
to come up with ways to make sure that
interoperability
is there for all the pieces that you
need for agents to be able to work
together,
interact together, to be able to get to
the right tools at the right time. I
look at protocols like MCP
and you're going to spend a whole bunch
of time on that today, but just like how
do I take care of a simple transaction
to A2A, which is how do I actually ask
another agent to take on some work on my
behalf and come back and solve a problem
to A2P and stateless state stateless MCP
and UCP and all of the other pieces that
are out there.
I think the ways that we're making this
easier for developers and actually like
make it you know, lowering that barrier
of entry is one I'm making these open
standards, making sure they're donated
to the right kinds of foundations that
can maintain them.
Um two, making sure that they are
standards, making sure that it's not
something that's implemented in a bunch
of different ways, but that can be
implemented whether you're running
things here on Google or whether you're
running them elsewhere.
Three, we're also
um integrating them into the products.
So, whether you're using a ADK as agent
developer kit or whether you're using
one of the other software developer kits
out there in the industry,
you will find these same protocols
implemented and used in very, very
similar ways
to help make sure that you can integrate
those into your workflow. And then this
is a vibe coding class, and so having
things like agent CLI and other things,
be very aware of how these different
protocols work so that as you're
building agents, you're able to build
them right into it from scratch. So,
uh hopefully that helped answer the
question.
Can I also jump in and add more? Is that
all right?
Yeah.
Um
I I will say
underneath the protocols, there's a
whole lot of infrastructure and design,
right? And the design is required for
the protocol to to work at scale. If
you're just running on your laptop and
you're the only user, perhaps scale
isn't a concern. Um but there's a lot of
concerns at running
MTP
servers at scale, especially at Google
scale.
We've done some pretty heroic heavy
lifting on
the current version of the protocol and
helping to design the next version of
that protocol to allow for a stateless
transport and a handful of other
affordances at the core transport level.
So you as a user, your developer agent
just wiring the bits and pieces in may
not see all of that. But under the hood
there's a lot of really impressive
engineering going into it to make it
scale.
Oh,
uh I hope everybody has a chance to play
around with this because I personally
find
agent to agent protocol is one of my
favorites and all the protocols that are
coming along with [snorts] it.
Awesome. All right, then let's move on
to the second question.
So this is to do with another one of the
protocols and Allen it's for you.
Will ATUI
protocols like ATUI replace traditional
app stores with temporary highly
personalized agent generated user
interfaces which are rendered
dynamically on demand or where do you
see like like I can imagine in a mobile
app
do you see this being like a customized
for each user or do you see like
this being more
like application specific not generic
thing across app stores?
Um
Probably. It's hard to say. I think that
we're moving to a future where all
software is somewhat agentic, right? It
doesn't have to everything be generated
on the fly all the time, but we're going
to get used to interacting with software
that
fits our needs and our context in the
moment a little bit more closely. Um
the UI layer of that, how do I interact
with with system, will follow a similar
trajectory. It will
be
um
personalized to me and it will remember
that I like buttons or I like sliders or
I prefer an audio interface or whatever.
So, all of our applications and all of
our user interfaces will become more
personalized and also more specific to
the moment. So, if my agent can talk to
your agent or my subsystem can talk to
your subsystem and fill in 2/3 of a form
for me, I don't even need to see that
form. I just have to say yes, go ahead
and do it. And then I fill in the parts
of the form that are necessary for this
interaction.
So,
those seem relatively small, but they're
going to end up changing how we interact
with applications and going forward.
Um
that's not even super future-looking.
Some of that is totally happening right
now.
Uh one of the
uh anecdotes that I talk about a lot is
um
a tracker app on your phone
uh has a UI that is provided for you by
the creator of that phone that app. Um
Uh but maybe you don't need all of those
buttons and you want half of those
buttons or you want to add something
else to track or whatever.
Uh it's very easy to just change the
configuration of the UI. All of the same
widgets persist. You just change the
configuration of the UI and that static
app keeps working. That's like the
smallest example, but it gives you a a
hint of where we think we're going with
everything being configurable and
customizable.
Uh you know, uh what would be really
cool? I really like the idea of
personalizing automatic personalization.
Uh imagine uh maybe you can work on a
prototype on this someday, Alan.
Like imagine like keeping track of
interactions of what users are doing uh
and then seeing what they like and then
customizing your UI uh proactively. You
say, "Oh, we noticed that you like big
search bars. So, we have created it for
you in this color or I don't know.
Yeah. I think parts of that are are
absolutely happening. I mean, I've got
demos that do bits and pieces of this.
I'm looking forward to putting them
together.
If you do link them to it if you have
some, otherwise share it later.
Sure.
All right, cool. Thanks a lot. Uh
All right, then to the next question,
Smitha.
All right, this is for you, Kanchana and
Pierre.
Uh so, how should database architectures
evolve to natively expose secure
read-only MCP servers to reduce their
integration complexity? So, like I'm
talking about native database, like
think Spanner, SQL, or even non-SQL. How
should they evolve?
Yeah. Oh,
I'll start first. So, we talk when we
talk about MCPs in general,
in even in the last last iteration of
the white paper, we talked about
security and we talked about trust a
lot. And in this paper, we did talk
about why it's needed and what are the
key components of it with respect to
configurations and stuff. MCP is kind of
becoming the standard. It is a USB-C
kind of a protocol for across your
databases. So, you know that.
When I think about how do you make it
secure, particularly with respect to,
you know, avoiding a DDL, DML kind of
transaction, then we need to keep it at
different layers. And some of that is
very much, you know, protocol-based.
So, for example, if you are using, say,
MCP and in Google's, you have MCP
toolbox. Um and MCP toolbox, if you're
using, and we talked extensively during
the last iteration about it,
um is how do you prevent it in such a
way that it only registers tools that
are needed for um
a select versus giving access to a DDL
or a DML. Uh and I've also seen
iterations where
customers use it for read replicas. Like
they don't give access to the production
data or they give access to the
production read data, not for the right
instances. Uh we need to be very
specific in the architectural choices
and make it um
security native as part of your design
of building an MCP based architecture.
Uh in one MCP, which is the MCP for all
of the databases, we do provide options
where you could the specified the
viewer, um
like the endpoint is always the viewer
and not um
the writer or
any other segments which could be added.
But
security should be
front and foremost of your
decision-making and you also need to be
very specific in how you are defining it
as part of your architecture.
[snorts]
[clears throat]
My perspective is also about uh
a lot trying to put ourselves in the
shoes of an agent, let's say.
Agents
experience sense the world and interact
with it in a different way than we do.
So we just need a bit of more of a
introspections.
And all these databases have been
designed for humans and the experience
has been optimized for humans as the
main consumers.
And now that we're moving to an agent
first world world where agents might be,
let's say, on par users, users are
alongside with humans or be the primary
users over time.
Then that means that also the experience
there has to change to make it more
friendly for how agents like to do
things or agents like to
uh express things cuz they might not be
able to
uh have the same sense of uh
risk that humans do or they might not
have the same sense of uh automation
that humans do.
And therefore, this is is better, you
know, try to optimize experience for
them. And uh making the agent experience
uh optimized for that. Cuz uh there have
been lots of people, let's say, or
developers out there that have been
focusing on optimizing developer
experience.
And now uh when trying to make uh MCP
data connections for agents and so on,
then we need to optimize for agent
experience here. So, obviously, things
like uh
be able to
um
interact with uh the database without
external processes, but using natively
service sent events. This is a good
thing to do there.
Uh be able to create agent-specific
role-based access controls.
Uh do some context-aware payloads
optimization, so that uh the results
that come back from the databases are
optimized for agents' views instead of
humans.
Or built-in telemetries are all things
that uh help towards that uh that path,
let's say.
Great. Uh so, putting security first I
took away take away the following
phrases. Putting security first and
foremost, which we'll see a lot into our
day four white paper, especially in the
context of I coding security has could
is a big concern.
And the second thing is agent, put
yourself in agent's shoes. Uh that's uh
quote I'm going to do, I guess.
[laughter]
All right, thanks a lot uh Pierre. Now,
Smitha, off to you for the community
questions.
Awesome. Let's get into the community
questions. So, uh the first one we have
from Seema.
How are Google's standardized data
pipelines for autonomous AI
collaboration actually reshaping the
core skills that an aspiring data
analyst needs to remain valuable? And I
think this is actually a good one to
start with because this is the question
I think a lot of folks in adjacent roles
are quietly asking themselves right now.
So, Mike, do you have anything to add
here?
Yeah, Seema, that was a great question.
Thank you for asking that today. I uh
Ooh, everything's changing from the name
of our systems to
[laughter]
um to the role. I uh
I you know, I think even like as we talk
about all of our pipelines, and we talk
about all of our systems, like we've
even started calling it the Agentic Data
Cloud.
Um where you've got the tools like uh
you know, there's a big BigQuery data
engineering agent, there's the data
science agent, there's all these things
that are available now. And when I think
about what that means from a role
perspective, I think as
as you know, I look at some of my best
friends that have been data analysts,
data scientists, data engineers,
um you you walk up to this big pile of
work with this little shovel and take a
whole bunch of manual work to make sense
of where that data's coming from, what
that data looks like, what are the
patterns, how do you make it usable for
others?
And I feel like I feel like this is
really changing what your role is from
trying to dig into this big pile of data
to like really becoming more of an
architect and and really becoming more
of somebody that's that's um that's
operating how these and supervising how
these systems are coming together, and
able to do so using some of the things
that we've already talked about. Talking
to things like the agents I mentioned
via A2A, um and and treating these data
systems as autonomous systems that you
can then generate code to to get to the
data you need, you can generate
processes, you can generate data,
and equally as important, generate
visualization and have some of that
visualization come out and be able to
experiment with a variety of formats
that instead of taking days or weeks
like it might have before can happen in
minutes. And that's really empowering
for you as an individual to do that and
really important for you to experiment
and so I'm really glad Seema you're
taking this course in order to pick up
some of those things.
Amazing. Thank you, Mike.
Um and then to kind of add on to that,
what do you think this means for someone
who's kind of maybe early in their
career if you are giving advice to like
a junior analyst right now? Like what
would you tell them to focus on?
Yeah, I mean I I go back to early in my
career and I go back to like watching
others early in their career and it was
really hard to get access to scale. It
was really hard to get access to
proprietary expensive data systems
um and tools.
And it really democratizes access. It
means that wherever you are, like you
can access the same thing that an
engineer at Google's using to get access
to data or an engineer in these other
many other huge organizations.
And and it really helps you be able to
operate in the same way.
Um and in fact, you know, being able to
take the course and do these things
that's it's you know, you're you're not
just operating the same way, you're
operating with the same knowledge and
tools
as everybody else. So
um it's really important to play around.
I've been excited recently cuz I've been
looking at things like ADK downloads and
trying to troubleshoot some stuff
and other things and even myself, like I
used uh BigQuery agent to look go to the
public BigQuery download of user agent
and get a bunch of details and there's
all kinds of public resources and public
tools out there that you using agents
can go do in order to get this data and
come up with really simple scripts and
tools which a couple years ago would
have been
a ton of work and would have been
inaccessible to most folks.
And especially also in in terms of
learning new uh new tools like writing
BigQuery optimized pipelines and
queries, now you can just
use anti-gravity or any of the
coding agent and it's just all CLIs and
just does it for you, right? Like you
don't have to kind of the the the
learning curve is much shorter now than
it used to be.
Okay. And you can put that shovel back
in the shed and like now focus on like
operating all these things together.
[snorts]
Definitely.
Awesome. Okay, let's move on to question
number two from the community. So, we
have this from Aus me.
How can organizations maintain design
system governance within dynamically
generated A2UI environments while also
practically separating tools from
collaborative agents along the MCP and
A2A boundaries.
Um Alan and Pierre, if you would like to
answer this.
Uh the first part of that is easy and I
need to think more about the second
part.
The first part is um
uh A2A is designed
to support your design system. Um we do
ship it with a set of uh basic
components to let you get started and
you can use what we're handing you and
render some configurable UIs on the fly.
But the expectation is that you already
have a front end, you already have a
design system, you already have a UI
that works. Maybe it's on web, maybe
it's on Android, etc. You've got a bunch
of components. You've got a bunch of
styles. Uh that's the thing that you
want the agent to be able to drive. You
don't want to have to
rebuild your front end to let your agent
drive it. You just want the agent to be
able to drive your front end. So, that's
the approach taken by A2UI and sometimes
that's not obvious, so I I reinforce
that message. Uh
it is a catalog of your components that
establishes a the
between your front end or your design
system with the agentic back end. Um so
that part of the question, that's just
how it works.
Uh the second part of the question is
with clear separations between MCP and
A2A uh boundaries. And I think that
that's going to be maybe a design thing.
I don't know, Pierre, do you want to
jump in on that?
Yes, like um yeah, I agree it's a design
thing.
Uh definitely. And maybe I can also get
shut up a small anecdote about it. Like
uh when I joined Google uh about 2 years
ago now,
there is the opportunity to uh
usually in the first month sort of a
experiment capstone project or anything
like that. And that was before the
protocol existed. And I was quite into
generative UI. So what I did there was
uh
I just tried to take the Gemini 1.0
family of models uh from a couple of
years ago and uh just send a prompt and
get back uh some widgets auto-generated
to generate Pokemons or these kind of
things out of the box.
And then in that case, there was no
protocol at that point. And then
therefore I I just started uh trying to
At times it would just work incredibly
well out of the box and at times it just
failed catastrophically and nothing
would just generate and then you just
get some random errors.
And then I would start just trying to
write some boilerplate code to intercept
errors, uh fix react code or interact
dynamically and things like that. And
that was very, very messy.
And uh that's when obviously then having
this protocol like this uh completely
changed the game since uh it just maps
uh the intent of the agent to JSON and
then uh you have discoverable
components. And with MCP, obviously you
just give it superpowers and uh it's up
to the users then to decide if you want
it more on the front or at back
of the interaction there.
Yeah, agreed. And then also on the MCP
versus A2A boundary, the framing that I
would kind of pull from the white paper
is
like the caller actually needs a result
or needs maybe like another, you know,
participating agent to take
responsibility. If like you need a
result, such as you need something from
a document, you're fetching something,
you're reading a role, that's probably
MCP. And then if it's actually a, you
know, active collaboration and and
result that you want to get from another
agent, that would be more along the A2A
route. So, it's two different problems
and then two different protocols.
That's why we'll see more MCP for design
system side and
A2A for interaction handling, basically.
Yeah, the the delegate, so I mentioned
it was a design thing. I guess the UI
that I am interacting with, if I'm
interacting with a agent and that agent
is doing everything, perhaps the tools
under the hood are what matters. But if
I'm interacting with an agent and it
hands me off to some other agent or it
says, "I'm asking somebody else to take
responsibility, we'll get back to you
later." That's like a user experience
design system. That's where I think the
boundary is.
Great. Okay, let's move on to question
number three from Kushal.
Um how do you design an automated safety
kill switch to prevent AI agents from
getting stuck in an infinite loop and
also something which drains API budgets?
Thanks.
I think this is really practical as
well.
Yes.
Especially for people who want to run an
agent for many hours these days, yeah.
Uh
that yes, uh Kushal, thank you. That
that was an excellent question,
particularly because I think it's not
just the consumers, uh more enterprises
are feeling this as well.
Uh we see this in the news, we see, you
know, token budgets being cut off, uh
enterprises giving some restrictions
over uh their employees to make sure
it's they all stay in the budget. So,
it's not just the AI it's also
everywhere we see that. And FinOps
itself is a huge um practice by itself.
Um when I were to think about
um you know, for the last decade we have
been talking data is the new oil. Uh but
in the era of uh AI agents, the token is
the new oil. When you think about data,
it's just a raw reserve, whereas the
token becomes that refined fuel that
actually powers the engine. For engine
in the sense is um agents. So, whoever
is optimizing their token pipeline is
probably going to win. So, that is a
like a serious context by itself. And in
cost optimization, particularly like
here the question referred to, you know,
how do I give a kill switch is like, how
do I make sure it's suddenly switched
off is a good question because we want
to avoid problems that causes
immediately. And uh I have to say
though, you probably already started,
you know, looking at ADK agent
development kit in
our previous iteration, but in there
there are some maximum iterations cap
you can specify. So, it doesn't go in a
loop, it terminates exhaust like
correctly. And also in agent development
kit, you have meta usage data where you
could track for anomalies. You could
look for, you know, where am I seeing a
skew where it's causing problems, so you
could develop it accordingly.
And in Google Cloud, you could specify,
hey, a billing budget, like when it
crosses 550 dollars, 5 dollars, whatever
is your amount to cut it off. Like that
is kind of a kill switch I would offer,
but I would strongly suggest we need to
think of this in an architectural point
of view. Particularly, hey, are you
implementing caching? And tomorrow you
would learn about probably skills. So
are you learning about skills? Are you
doing batch requests? And one more more
important thing which I normally see is
are you using a high expensive model for
all of your transactions versus you
probably need a lower cost model for
some regular transactions. So there are
some architectural choices you need to
make, but yes, you do need to have a
kill switch so you can switch off the
agents as and when it comes. And I'm
glad you asked that question because
that often gets overlooked when you're
so excited and over like you know,
creating your new iteration. But yes,
that needs to be part of your
architecture design pattern.
Yeah, and and just to add on to that a
bit. So one more thing I would say even
going back to the basics.
Like go back to our prompt engineering
the second iteration of this course and
read that prompt engineering like white
paper to see how you can engineer your
skills or prompt to be very token
efficient. Fine-tuning or like even just
prompt engineering sales can save a lot
of tokens which can help with minimizing
token usage to not require a kill
switch. Hopefully that's soon at least.
[laughter]
Right.
Yeah, awesome response Contessa. I
really agree tokens are the new oil. And
then also on the prompt engineering
front, am I the only one who asked my
agent to always just talk in bullet
points to save up [laughter] on tokens?
Yeah.
Okay, we can move on to the final
question from the community. So this is
from Ritika.
And she's asking will the next major AI
breakthrough come from better base
models or from agents autonomously
developing their own tools?
Yes.
Yeah.
[laughter]
It's Ritika this is a really good
question because I think it's
and Alan, I I I bet we're going to like
be very similar on this. It's it's both.
It's it's going to be a combination of
and we should expect models to continue
to improve. We should expect the
capabilities of those models to continue
to expand. We should expect to see
additional kinds of models coming out in
the industry.
But we should also expect to see new
ways to interact with those models, new
ways to build things with those models.
Um I think the question was on agents um
autonomously developing their own tools.
I think more and more like we're going
to see reuse matter. We're going to see
um you know, as these model capabilities
continue to increase, cost of these like
really um premium models
gets higher as well. And so we're going
to see I think breakthroughs are going
to be all over the place. Breakthroughs
are going to be in efficiency.
Breakthroughs are going to be in knowing
when to use the right model at the right
time. Breakthroughs I you know, I look
at like being able to solve the broadest
sets of problems, which are going to
come not just from the model and not
just from the agents, but from the
context and the data that we're making
available in very usable ways.
I think I think there's a lot of
breakthroughs that we're going to see
and observe. And and the message that if
you listen to podcasts, if you listen to
you know, if you listen to interviews,
we're still very early in in agents and
still very early in AI.
And so I you know, I these breakthroughs
are going to come from all directions.
Alan, I'm curious your thoughts.
Yeah, I mean I think that we're already
seeing
the feedback loop or the inner loop
tightening up.
I think uh
uh
all of the research labs uh uh
are using agents in their workflow to
improve their workflow, to improve the
models.
Researchers are working on
uh trying to get to the next algorithm
breakthrough for
uh efficiency or, you know, to to attack
different angles of
uh trying to make the models better.
All of those individuals are using
agents and using these tools. That is a
feedback loop. I don't think that the
feedback loop is super closed and super
tight and fully autonomous. I think that
these are tools that humans are using to
improve the system.
But that still matters. We are seeing
the acceleration continue because of
that.
Um
your question was, is it going to come
from the model or is it going to come
from
developing better tools? And I really
can't tease those things apart. I think
that they are uh
the processes that we are using to uh
continue to improve the capability
spectrum. Uh uh
They're they're intrinsically released.
Uh
uh to to linked. That's the word I'm
thinking of.
Awesome. Uh Kanjun and Pier, do you have
any thoughts on this question as well?
Uh
[clears throat]
uh They both uh Mike and Alan had
covered it pretty well. Um in my point
of view, as you know, both of them are
saying, models are becoming closer and
closer to agentic in nature by itself.
And the new coin word for this for this
week in
uh X is loop engineering. So, when
[laughter]
when I think about, you know, where the
evolving comes from, like I'm I'm
overwhelmed. I don't know what others
hear. So, is it harness? Is it loop? Is
it model? Is it agent? Um
but one thing I am confident about is
the models are going to be, um, more and
more very specific in its capability,
specialized abilities, like coding, like
AI for science, like, you know, other
abilities. But the experiences we are
going to bring in our consumer or in our
enterprise world is more going to be in
this engineering loop, harness,
architectural pattern, whatever that you
might call it. That might be the case,
uh, which might come. Um, but I'm so
excited for the future, just to see this
evolving and the era we live in.
Yeah, amazing times, definitely. Any
last sentences, like, uh, from each of
our guest speakers? Alan, starting off
with you.
Uh, we I didn't get a question about AP2
or or UCP. I expected that to show up.
Uh,
uh,
uh, there's an alphabet soup of all of
the protocols. I think it's justified
because we have new tools and we have
new capabilities and we're trying to
figure out how to get work done.
Ultimately, all of this is just us
trying to establish conventions to get
work done so that I can talk to you and
you can talk to this other person and we
trust those interactions. That's really
what our goals are. Um,
uh, it is where I spend a lot of my my
brain power.
Nice. Yeah, I think it's what we just
selected, uh, like four questions. There
were a lot of questions which we haven't
been able to select. Show them.
[laughter]
Pierre, uh, off to you.
Uh, for me, I mean, right now when we
talk about models, we mainly talk about
LLMs,
which are most common, let's say,
popular, and so on. But one of the main
thing that I like most about Google
DeepMind that is different from other
uh, research labs
is that there is still lots of focus on
research that is pure, that is not just
LLM-driven.
And I think, uh, from going on that
aspect, uh, there is still, let's say,
there is no wall there. There is still a
lot of way to go.
A lot of progress to go on models that
are non I say autoregressive in nature,
but could be diffusion based or JEPA or
other architecture like AlphaFold and so
on
that are completely different and also
embedding domain knowledge.
And I that's one of the main thing about
DeepMind that I really love and I I'm
really curious to see how this is going
to evolve into the agentic world once
these models are mature from the
research lab.
Nice. And especially
the
the void models I'm very excited about
the that Demis mentioned IO, which kind
of diverge a bit from the tech
typical text-to-text models and like
anything-to-anything. I find that also
very exciting just to add on to your
point there. Cool. Mike, you're
Yeah, I mean, I I was just thinking
about the other day with this with this
coming up that you know, I look at this
class and I look at folks that are
starting to write code who've never been
developers and I look at traditional
developers who are becoming more like
consumers and consumers are becoming
more like developers and like these
walls and boundaries are falling down
and that's really it's really exciting
to see and I think like look at examples
out there. You know, the author of
OpenClaw had never been a professional
developer himself
and and wrote this product and sold it
for a billion dollars and and did that
like there's a lot of opportunity.
There's also a lot of realism in all of
this. I think um
as you build things, as you deploy
things don't just use these tools for
the sake of building
use them for the sake of securing your
product. Use them for the sake of
protecting people's data. Use them for
Use them for the good of building better
products, not just for building products
and I think it's one message that I
think is really important in how we
build and deploy agents is
even though you've now got the ability
to do anything with it, just like a car,
you can go out and drive it as fast as
you want.
But you've got to, you know, you've got
you've got some boundaries and some
things that you should do because
there's others on the road you've got to
interact and and do that. So I think
like take all this power you're being
handed this week in the course, but
apply it responsibly and realize it's
it's really on you to make design
patterns and choices in how you build
things. As you talk to other agents, as
you build these things, like more and
more transactions and more and more
things are going to happen this way. So
like I'm really excited to see everybody
here jumping into it. I was really
excited to see these questions. I'm
excited to see where the capabilities go
and I'm I'm also excited to see people
do it responsibly.
Yes, absolutely.
Uh thank you to all the guest speakers
for coming on here to answer all these
questions. Really appreciate the
in-depth answers that we got here. Thank
you everyone.
Thank you.
All right, moving into the code labs.
Today's two are really nice pairing
because they actually take you from I've
heard of MCP to I have MCP servers
actually plugged into my coding agent.
So Fran's going to walk us through both
of them. Over to you, Fran.
Thank you, Samantha. Uh hi everyone. Hi
Chad. [clears throat]
Um another day of code labs. We're
already on day two.
Can I get some reactions in chat if you
worked through day one code labs? How
did day one go?
Oh, oh, quite a few, quite a few. I like
it and I saw some good discussions on
Discord, too.
Um
if you get stuck when you work through a
code lab, your first instinct should be
to prompt antigravity for help. Like,
help is right there where you're already
working. And if that doesn't work,
Discord is a great place to get help and
discuss what you've been doing.
I'm Fran Hinkelman. I lead the AI
DevTools team in Google Cloud DevRel,
and I'll guide you through the code labs
for day two.
We have, like, Smith already said, we
have two more excellent code labs. The
first one will look at how to make your
agents even more powerful by connecting
them to external tools and canonical
documentation using MCP.
Second, we'll show you how to run the
same agentic workflows directly from
your terminal using the Antigravity CLI.
So, let's look at the first code lab.
So, again, the links for the code labs
for today two, you find them in your
emails and the discussion post. There's
no submission process once you're done.
We just want you to carefully work
through the code labs and learn as much
as you can. Go experiment.
So, our first code lab shows you how to
configure an MCP in Antigravity.
Who knows what MCP stands for? This came
up a bunch in the QA today already.
Give me a thumbs up in the chat if
you've used MCP before.
Yes, Model Context Protocol, MCP.
So, for agents to be truly useful, they
need access to real-time accurate
information. If you only rely on the
model and the training data, it might be
outdated and you get hallucinations. MCP
is an open protocol standard that solves
this by allowing agents to connect to
external APIs securely.
So, in this first code lab, you'll
configure MCP, you'll configure
Antigravity to use the developer
knowledge API in Google Cloud. And that
makes your agentic workflows much more
sustainable and reliable.
And then in the second code lab for the
day,
um
we will introduce the Antigravity CLI,
the command line interface. If you did
yesterday's code lab, I hope you did, I
saw a lot of you did, you already know
the Antigravity Agent Manager, where you
worked all the time, and you also worked
with the IDE, but this is all about the
CLI, the terminal. Um UI is great, but
sometimes you need the control of the
command line. So, the Antigravity CLI,
AGY, brings all the core agentic tools,
like planning and tool calling, directly
to your terminal.
Um in the lab, you'll go through how to
install it on your operating system.
Um we'll go through the basics, and then
you'll work through some really powerful
use cases here.
So, these are the code lab assignments
for day two. As I said before, you don't
need to submit your code labs at the
end. There's no test or submission
required. We just encourage you to work
through them, explore, learn as much as
you can.
Have fun with the day two labs. Back to
you, Smitha.
Thank you, Fran. Both of those code labs
are amazing, definitely worth running
end to end. And also, the developer
knowledge MCP server that you just used
in one of those code labs is actually
one of over 50-plus Google managed MCP
servers. So, what you got hands-on today
is actually something that teams are
pointing to at production, anyway. So,
once you're done with that code lab,
it's also worth checking out a bunch of
other code labs that I'll be leaving in
the description box below, which include
the BigQuery MCP server, the Maps MCP
server, as well as Cloud Run's MCP
server. With that said, let's move on to
the pop quiz.
Amazing. Here's your favorite part of
the day, everyone. Moving on to the
first question. In traditional ad-hoc
development, integrating N models with M
tools requires O of N into M complexity.
So, how does the model context protocol
help with this complexity?
Uh your options are
A, to logarithmically scale it or log N
of M. To linearly scale it or N plus M.
To constant complexity scale of O of 1.
Or to polynomially scale it. Think back
and the answer will be shown in 3 2 1
and
it's B. MCP helps in linearly scaling
your
N models into M tools integration.
Moving on to the second question. What
represents the transition from a Swiss
Army knife or single agent monolith to
logically partitioned internal sub
agents with restricted tools? Your
options are A, cloud native
microservices scaling. B, internal
specialization. Or C, rag context
chunking. Or D, prompt schema
validation.
So, think about it. Your answer will be
shown in
3 2 1 and it's B. Uh internal
specialization. And about spec driven
development, for that you learn a little
bit about this in day five. Stay tuned
for that.
All right, next question.
So, your next question is which protocol
developed by Google and donated to the
Linux Foundation acted as a lingua
franca allowing specialized agents to
negotiate, brainstorm, and delegate
tasks to each other? Your options are A,
MCP. B, A2A. C, A2UI. Or D, AP2 which is
the agent payment protocol. Think back
to Allen's conversation and Mike's
conversation and the white paper and the
answer will be shown in three, two, one
and
the and correct answer is B, A2A, which
is uh which allows you to um
uh specialized agents to uh negotiate,
brainstorm, and delegate tasks to each
other.
All right, the la- second last question.
Which What is the agent to user
interface of A2UI protocol?
Is it
A, an LM LLM executing raw arbitrary
code as Pierre mentioned earlier,
a framework agnostic standard for
declaring UI intent using um trusted
components,
or is it C, a tool that translates
screenshots into database schemas, or is
it D, a terminal interface utility for
command line prompting for GUI?
Your answer will be shown in three,
two,
one and it's B. It's a framework
agnostic standard for declaring UI using
trusted components.
All right, our last question for the
day.
Uh what are the respective roles of UCP
and AP2 in autonomous procurement?
Your options are A, AP2 builds the
order, UCP secures and authorizes the
financial transactions, you or UCP uh B,
UCP defines database schema where AP2
connects the MCP server to client, or C,
UCP handles merchant side of things
where AP2 manages the payment side of
things, or D, where UCP manages local
storage where AP2 manages dynamic
browser execution. The correct answer
will be shown in
three,
two, one
and it's C. UCP handles the merchant
side of things where AP2 manages the
payment side of things. And that brings
us to the end of the pop quiz.
Awesome. Thank you, Anand. Also, quick
wrap-up before we sign off. Day three
assignments will be dropping shortly and
tomorrow's topic, agent skills, picks up
right where today's left off. We've
covered how agents connect to the
outside world today. Tomorrow is all
about how they manage their inside
world. Memory, long contact strategies,
and skill set let agents specialize
without bloating every single prompt.
Keep the discussion going on Discord.
The mods are active. And also, as a
reminder, questions selected from
Discord can win Kaggle swag. So, keep
that in mind as well. And get started on
the code labs if you haven't already.
Try plugging in one of those MCP servers
that we talked about into your agent and
see how the output is. Also, if you've
missed day one's live stream, it will be
linked in the description box below as
well. Thank you, everyone. See you
tomorrow.
Looking forward to your questions. See
you tomorrow.