This video introduces open protocols that standardize how AI agents connect to tools, other agents, and user interfaces, solving the N-into-M integration complexity problem where traditional approaches require O(N×M) custom integrations. The Model Context Protocol (MCP) acts as a USB-C standard for tool connections, reducing complexity to O(N+M) using standard transports like STDIN/STDOUT and Server-Sent Events. The Agent-to-Agent Protocol (A2A) enables specialized agents to coordinate and delegate tasks through registries and machine-readable agent cards. The Agent-to-UI Protocol (A2UI) allows agents to generate dynamic, personalized user interfaces using trusted component catalogs. Additional protocols include the Universal Commerce Protocol (UCP) for autonomous shopping cart building and the Agent Payment Protocol (AP2) for secure payment processing with human sign mandates.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
DAY 2 Livestream - 5-Days of AI Agents: Intensive Vibe Coding Course With Google
Added: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 Q&A.
>> 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 Q&A.
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 Q&A 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.
Related Videos
AI Agent Mastery Certification Course: Lab 4 – Tools & MCP
arizeai
350 views•2026-06-16
Real-time Voice cloning, Kimi K2.7 CODE, GLM 5.2 and 3D reconstruction | AI News
kaiexplainsYT
111 views•2026-06-16
He Believes AI Could Replace Humanity Faster Than Anyone Expects
LondonRealTV
815 views•2026-06-15
General Session by Rami Rahim-The next generation of networking: From vision to self-driving reality
HPE
108 views•2026-06-17
[PLDI 2026] Flatirons 3 - LCTES (Jun 16th)
acmsigplan
191 views•2026-06-16
Google DeepMind’s AI Halves UK Housing Planning Time
60secondsignals
467 views•2026-06-17
The Creators of Claude Code and OpenClaw don't Prompt Their Agents Anymore?!
ColeMedin
569 views•2026-06-18
Why prompt injection is AI's biggest fail
usemultiplier
1K views•2026-06-17











