Powering the Agentic Web: Building Web3 Agents on Google Cloudby Marcos Montero

Hi, everyone. I'm excited to be here with you all today. My talk is going to be about unlocking the agentic web, building Web 3.0 agents in Google Cloud. My name is Marcos Montero, and I am a customer engineer at Google Cloud.

I work with startups and scale apps in EMEA to build cloud-native solutions. I focus on Web 3.0, AI, and security. My talk will start with an introduction to the agentic web, and then it will be followed by the building blocks to build an architecture, talking about our open frameworks and services for AI and Web 3.0.

The last part will be a reference solution architecture for DeFi, using all of this tooling. The agentic web, so what is this? First, let's start with an evolution of the web. We saw that the web, one, started as a read-only format, where there was only content, was one-way and black paper. Web 2.

0 added the right features to it, and that was the advent of social networking. The data and the systems in Web 2.0 are centralized. Web 3.0 adds this ownership feature and layer to it, where dApps are built on B2B, content is owned by creators, and the data is decentralized.

Now, the agentic web expands on this with an execution layer on top. With it, you get decentralized intelligence, verifiable on-chain, and effortless and autonomous, so it helps with the UX and makes Web 3.0 features autonomous. What is an AI agent? Let's start with a definition.

An AI agent is an application that tries to achieve a goal by observing the world and acting upon it, using the tools that it has at its disposal. What is key here is that AI agents use LLMs, generative AI models, one or many, to achieve this goal, and they are aware of a context. So how have AI agents evolved? With the advent of generative AI, we saw chatbot applications that had an LLM and a prompt. This was very basic, in a way, and soon people realized there were problems with, OK, those models have hallucinations.

And also, what happens if I want to have my own data on these pre-trained models? If I want to have external data sources, that's when it came, RAC, Retrieval Augmented Generation, which is a method for expanding LLMs with external data so you can ask the models questions about them. And with it, you don't have to fine-tune the model, which is typically quite costly in terms of infrastructure. So you can have a pre-trained model and use external data into it. Now, after that, those agentic systems were expanded with tools, APIs, that are accessible by LLMs.

So you have now a much more complex agentic system. What we're seeing now is that this tooling has started to come into thinking models where there is reasoning loops in these applications. And this has been the advent of multi-agent systems, systems that you have multiple agents collaborating, models that call other models. Some models are text-based. Some other are multi-model, image-based, audio-based.

And these systems, up until now or up until recently, have been within a network, within a company, operated by the same personas, in a way, or developers. What we see now is these multi-agent systems are starting to talk to each other. And we are building the frameworks for inter-agent operability, where you can have an agentic system call another agentic system and achieve a common goal. So how are AI agents architected logically? So there are three things here.

There is a runtime that has an orchestration layer. That's the agent brain. In here, also, there is memory, short-term, long-term memory. They remember what you ask them. There is a definition for the agents.

What are the goals, instructions, the tool, the system from? What is what this agent is in charge of doing? Models. AI agents can have one or multiple models, which can operate in different realms, image, text, audio. Also, tooling, functions, APIs, databases.

A lot of these tools are now MCP servers. So you can have an agent talk to another system with the MCP server from Anthropic, which is a protocol I will be talking about later. And ultimately, remote agents that can be available via MCP or through all your agentic framework. The end user only talks to the agent with prompts and gets a response. These prompts can be text-based.

It can be voice commands. It can be audio, video. It can be multi-modal. So what are the use cases of AI agents for Web3? So I will be focusing on the architecture at the end on these two top ones.

But basically, how you operate a wallet, how you do blockchain operations, that can be automated by an agent. Submitting transactions, analyzing data, managing the wallet itself. That also helps a lot with user experience because you can use prompts to talk to these agents and you might not need to have online or offline wallet. When it comes to the interesting, it's also for DeFi. You can have things like automated trading, smart staking, analyze market news.

These agents can operate synchronously based on user prompts. But also, you can command the agent to run autonomously a reasoning loop or things like operate this trading strategy. Do a smart staking for me. Choose the best staking node so I get the most yield. Execute this portfolio trading strategy for me based on the news in real time.

So that's where it gets really powerful. Also, we have other uses like endows, governance, treasuries, autonomous decisions, and gaming, and more. Okay, so talking about Google, our AI services, which are available in our tool and also are open, and we provide third-party solutions as well there. So at Google, we have multiple AI services in different layers, and we provide flexibility as each of them. We have first-party infrastructure and services and models, but we also support third-party infrastructure, models, and services.

Also, we have our own protocols and frameworks, but we support third-party ones. So Gemini, which is here, is an agentic system that is available via an app and also via the web, but it's also a family of large language models. And when it comes to the agents, Vertex is our platform for AI and ML, which you can use in GCP. And ADK, Agent Development Kit, is a framework which is open source and supports our own first-party models, but also third-party models. You can use it in Google Cloud, or you can use it anywhere.

Also, we have GenKit, which is another agent development framework, and third-party frameworks. We support Limechain and others. When it comes to protocols, we are leading a new protocol standard called Agent-to-Agent Protocol, A2A, that has more than 50 partners already involved, and this allows for inter-agent communication. So it expands on Anthropic Model Context Protocol, MCP, an analogy of it, it's like a USB interface. It allows you to connect things to an agentic system, while A2A allows the collaboration between them.

Agents Space, which is the last one here, it's an enterprise solution that uses agents, and you can register your agents to use it. This is how it all works in an architecture. Main thing here, Agent Engine, that's a runtime. It's how you can run agents on Google Cloud. It's totally serverless.

It's built on top of Cloud Run, that you might know if you use GCP, and it provides all those things for you. Then in it, you can use our first-party ADK, or third-party agent frameworks if you want. We support an agent-to-agent protocol for inter-agent communication, tooling like MCP, other tooling as well, our first-party models, GMI, or third-party models as well, and we have features for it, observability, evaluation, and you can register them in Agent Space if you want to make your agent available for an enterprise. Okay, so talking about Web3, we do also have Web3 services, and I will be focusing just on two of them, which I think are the relevant ones for the architecture, starting with RPC. Blockchain RPC is our RPC service.

It's multi-tenant, and you can use that to read and write blockchain data on Ethereum using the standard API. We support Ethereum, Mainnet, HoloSky, and yeah, you can use it in Google Cloud. It's managed for you. Also, we have blockchain analytics, which is indexed blockchain data that we have for 25 chains. Of those 25 chains, eight of them are indexed by us, so that means we run the indexing pipeline, and we promise SLAs and SLOs, service agreements and objectives, for those eight chains.

If you want to use this data, you can use a SQL interface or via PubSub. Now, this is going to be the last slide, which is all of those concepts together. So, this is something I implemented as a solution architecture. I designed for a DeFi use case that uses all these building blocks. Instead, the user can do things like send ETH, check the balance, watch the price of ETH, stake it, tell me the crypto transaction volume from last week, but also more smart operations that the alien can run autonomously.

for your DeFi portfolio. So, all of this is hosted in GCP in this case, and you have a root agent and two sub-agents. The root agent is the crypto-based agent, the sub-agent is a wallet agent, and a trading and staking agent. KMS, Google KMS, is used to store the keys, and then we have RPC nodes for Ethereum, and also index data for Ethereum, and others, if we want to. Model Armor provides generative AI guardrails.

So, every prompt and response that your agent system gives the user in or out, is inspected and sanitized by Model Armor. So, then you can prevent jailbreak attempts, which are always on the news, and anything that is a content-based issue, you can also tell it not to speak about competitors, and things like this. So, the way this works, for example, you just say something like this in text, it could be also audio, and for example, send Ethereum, so it will end up going to the RPC node, and for that, you will get, you will send a transaction here, send TX, send TX, and it will go there. This is an example of things. Also, you can also have things like buy assets, get the news, get chain data, that could go to external MCP servers, or agents.

So, this is showing ADK, Agent Development Kit, that's the icon, but also, it's also, all the frameworks are supported. And this is why the importance of the A2A protocol. We need to standardize how agentic systems can talk to each other in the internet, or in Web3. And, yeah, I think it's very powerful. It can help with UX, it can help make Web3 widely adopted, and it can bring automation, and a lot of really, really cool features to Web3.

And with that, I think I'm on time. I have three minutes more. Here, if you want, we have the startup program that you can follow if you want credit to build these agentic systems on Google Cloud. I'm happy to connect, of course. And with that, I have time for questions.

So, any questions from the audience? Yeah? Matthew? Yeah? First question.

Yeah, go on. So, we're actually working on this, hopefully. And I cannot tell you just now, but we can follow after. And we would love to have, yes, an office chain on BigQuery. So, yeah, we can follow up on that after.

I don't know what is the status, but yeah, hopefully, yes. Yeah? Go for it. What's the real blocker for making it just infinite chains? Like, if you have an RPC, why can you not index that chain?

Well, we have to run the indexing pipeline somewhere. So, the way this normally works, you will have an RPC node, and every layer one or layer two will need to build that infrastructure so that the node is running, and then we push that to BigQuery. Because once you have BigQuery and you have a public dataset, you just click and it's ready for you. But it's serverless, it's great, fantastic. There's no boot-up time or anything like this, but that means there has to be a pipeline.

So, yeah, someone has to build this, and this is why we allowed in BigQuery for anybody to build a community dataset. We index eight of them ourselves, we run the pipelines, but also, there is like up to 25, minus eight, so those are community chains. Any other questions? Yeah, here. In the last slide, I see that you showed that the user talks to an agent, and the agent talks to two more agents.

Yeah. Why don't you, for example, in the first agent, use an LLM that would categorize, for example, the user input, and then talk to the other agents? Because that would be faster, right? Yeah, definitely. This is the way I build it, so you have, it's composable, and you can use, if you want, the valid agent for something else.

But definitely, you can build all this in one single agent. But it's kind of the paradigm of microservices and monolith architectures, so it's normally better, and we see this, to build agentic systems that have sub-agents that have differentiated tasks. And the way I envisaged this, it was like, okay, how about an agent that does all the wallet operations, while other does all the smart, forward-looking, crawling, new servers, and things like that, to build DeFi strategies. So that's how I envisaged it, but yeah, you can do it as you want. Thanks.

Any other questions? I think we are running out of time already. Okay. Well, thank you so much.