Agents Under the Hood: Building the Agentic Stack

Transcript

Can you guys hear me? Yeah. >> Yeah. Hey everyone. Uh, my name's Chris Wessles. Really happy to be here. Um, by day I work on GraphOps, a web 3 infrastructure company, and Summerstone, a DeFi market ops company. And I have these fantastic panelists here with me today to discuss the Agentic stack. Um, I'll hand over to my left first. Please intro yourself. >> Hey, I'm Clemens Juan. I'm the solution architect head of AI and marketing at Den which uh eg gave a intro to Den we are decentralizing infur and metamask all right I'm Nat dab I'm the director of developer relations at iigen labs we're the team behind the ien layer

protocol IEN cloud and specifically for this talk I might throw out IEN AI and IEN compute which is a verifiable runtime for AI agents and anything that you'd like to run verifiably >> hey everyone I'm monto from Barcel Uh I'm working at Visero. Visure is an AI development platform and yeah I'm here to talk about what the stack for building AI Asians. >> Awesome. Thank you all. Uh we have our fourth panelist just in time. Welcome. >> Google developer experts cloud. Are we doing English or Spanish?

>> English. >> English. So, uh, focus on cloud and AI. So, happy to be here. >> Amazing. Okay. Let's start by building a shared understanding of the agentic stack. So, if I were to give you a simple loop, something along the lines of while, not done, call the LLM, call the tools, repeat. Is that an agentic system? What more needs to be there? We'll start with you, Bernice. Yeah, I I personally believe that uh a Gentic system, if you think about it from a retail level, would likely have to have some purpose, has to have some uh subset of what you want to do and have it go off and run those tasks. So, you have a

lot of bots today, but what you're giving them is additional preferences so that they're able to complete that task. If you just run the loop that is more of access to using the natural language processing but not necessarily doing the intent of what you want it to do with the available uh APIs or available MCP servers are there connections that it it can discover. >> Mater seems to be a lot of nuance when someone calls something an agent. Um everything from something that I would consider just an app to something that truly is an agent and then everything in between.

So, it kind of depends um on what someone's definition is, but really I guess if you can start a process and just have it run forever and actually take decisions that are not uh requiring any human intervention that provides value that couldn't be done using um a traditional software stack, that might be um something that I would kind of like give as a definition. >> Yeah, I'm pretty aligned. Uh I think it's a little in a loop with tools to solve a problem. So yeah, I'm pretty late with that. >> Yeah, for me I I'd say it's the reasoning capability. So for me, what separates an agent from a traditional application is the ability to decide what tools and context to use in order to achieve their goal. So the reasoning

which is basically provided by LLMs nowadays. Uh that's the what makes an agent. >> Cool. And maybe we can try to build like a shared understanding with the audience of the stack from a builder's perspective. So it's clear that we have an LLM in the mix and we have some tools, but if you were to kind of give a layered definition of like what are the pieces in the stack, where would you start? >> Okay, I'll go first. Um, so I think key components in building applications right now revolve around of course LLMs having a a good model to power the

reasoning part, but you also need key components like memory, the ability to keep context in the long run. um traditional data storage which most people don't consider but having a highly available highly available low latencies data store is key to having these agents working properly. So um I mean there's there's a lot going on right now. there's a lot of movement towards distributed tools using MCP protocols, multi- aents, A2A.

Uh but I think that there are essentially um software applications but they're very sensitive to latency especially voice powered agents. Uh so I yeah that's basically my take. Uh nice. If I would need to like divide it in some places, I would say first you have the environment layer. Yeah. Uh at versal we run our Asians in something called flu compute that is like real serverless. So you can run your agent and while your ch5 is thinking you are not getting charged because that uh then uh I think there is the context

layer that I want to dig deep a little bit. For example, in B 0, we have a dynamic system prompt. And this is really cool because depending on the app of the user, we have a injectable system prompts. And this is really cool because you can cache it and you make all the requests much cheaper for all the users. uh then I would say that you have the actions layer that is all the tools NCPs and in the end you have the application layer that I want to dig deep a little bit that is not only the UI but also is how the agent interacts with the UI and how the UI gives context to that agent.

For example, in B 0 after the LLM finishes uh writing the code, we run we build that code and if you have any error, we it get back to the agent so the agent can like autofix it. So yeah, I think those are the parts >> I'd love to um I'd love to learn more about the ser the serverless runtime because like in my head when I think of an AI agent, I'm thinking of it running in like a traditional server because it always needs it's almost like always needs to be running whereas I'm thinking more serverless is like action based. So I'm kind of curious how that works and I know that like Verscell has done incredible like amount of work in the AI agent space with Vzero early on was one of the coolest products I had ever used.

So yeah, I know you all have a lot of experience there. So I'm just kind of wondering how that works. >> So basically we have a server but we only charge on CPU usage. So we are able to to see when you are using the CPU. For example, when you are like doing a fetch to a GP5 you are waiting to that response. You are not using the CPU. That's why it's like real serverless. In AWS for example you you do the fetch and where you are waiting you are getting charged. Okay, that makes sense. I don't really have a lot to add to the stack part from what they already mentioned.

Other than like when you think of a agents, you often think of like agents talking to each other. That's ultimately well where we want to be, I think. So, you often need some layer or I would say some protocol or standard for everyone to agree upon. So, there's a couple of ways that people are doing this. I think A2A from Google is a pretty good one. Um, you know, we have now a bunch of standards, right? We have MCP for context and tool calling. We have A2A. We have AP2 also from Google which is like uh payments layer. Then you have X42 for crypto payments. So I think the stack also kind of might include some of these uh components as well. And if we're here talking about crypto, you might also consider what are some of the standards for trustless agents. So you have ERC8004 obviously is kind of like a

new one. Uh it's interesting. No one really knows if that's going to be kind of like what everyone ends up using, but that's a really good start. So yeah, I think that's kind of where we are. We're still fairly early on in this in this stack because everyone hasn't really come to a consensus on everything. MCP has been something that people have come to a consensus on though. I would just add that a lot of people are building for businesses. So if you have a a business that has, you know, a website and now like a social media account and hopefully at some point like a DAO or or some ENS address associated to it.

They'll likely have a URL or DNS that connects them to the agent that represents that business. I like to think about it from the perspective of a retail user. If I have my phone, it has, you know, fingerprint identification. There could be a nano small language model where if you are downloading information from other agents, you can download conversational packets to have it more knowledgeable. You can have all that storage on your phone. And so at least I'm looking forward to you know in like the movie Her where you're kind of doing this type of conversation you are keeping a lot of that private data on your trusted execution environment on your phone and then from there all those connections that you have to build it's another type of layer where you're

augmenting the app view but now you have other methods of communicating between the agent that represents the app to yourself which might be authentication it might be you know other types of intention that you might have. I might want to go somewhere and it might have to pull from multiple applications to get that information. >> Yeah, agents at the edge are definitely going to be an important part of the stack. U Touan um Google's introduction to agents white paper speaks specifically about models, tools, memory, evaluators, and orchestration as a reference architecture.

Um, how does the Vertex AI and agent builder products turn those components into real things developers can use? >> So, Vert.Ex AI is the main platform for Google Cloud. Uh, in terms of AI products in there, you have the tools to train your models to serve them, customize them and whatnot. Um I think that right now the biggest product right now which is criminally under underpromoted in my opinion it's called agent engine which is basically the stack that Google launched to host uh agents not only developed with the with ADK which is the the Google the Google

open source stack but any any agent built with open source like langraph or uh even hugging face stuff like that you can host it on GCP on Google cloud and agent engine does most of the heavy lifting in terms of memory management session allocation is mostly serverless you can configure it for low latency and stuff like that um but I do believe that Vertex is eventually going to be the go-to place for people interested in AI right now there's multip people entry points. Google is a little messy right now in terms of AI.

There's a lot of different bets coming out. Um we they just published Gemini two days ago, Gemini 3. Super interesting. There's a new ID fully powered by agents called anti-gravity. If any anyone is interested into getting into agentic development, super interesting and results has been really really interesting. But going back to Vertex, uh I I think it really gives the opportunity for people who are who have a dedicated team of business uh data scientists, AI engineers that if they want to fine-tune and trade their models on the

cloud, that's definitely the way to go. But if you're a hobbyist or you are a nontechnical person, uh you still have the tools to either get a built-in agent or model from the marketplace or beat one using no code or loco tools. So >> cool. Yeah, I always feel like a little kid when the latest frontier or open source model drops. So congrats on the Gemini. >> It's hard. I mean, we we did a um AI master class at Google yesterday and we were running through the presentation when they announced the new model, so we had to scramble and change it on the fly, which was an interesting challenge.

But yeah, it's an ever ever changing game. I mean, you you cannot really I have a backlog of articles and stuff to read. It's really really hard to keep up, but it's a it's nice place to be right now. >> I can definitely relate to that. Um, so I I think it's clear we've established that tools are a really important part of the stack in connecting AI to the rest of the world. Um, and that includes the digital world, but also the physical world. Um, we're we're obviously here at Dev Connect and at Agentic Zero and Web 3 is a really important context um for AI. So to Clemens, um if h how do we think about uh AI agents interacting

with the blockchain? If if you were to hand an AI agent a clean interface for reading and writing, what does that look like? And maybe as a bolt-on, how should builders think about security when they give their AI agents onchain access? Yeah, the security part is is very difficult and I think the one to to focus on first because imagine if your MetaMask or other smart wallet uh does have an AI agent that can trade on its behalf. What's more important is actually what restrictions you give it.

Maybe each trade is up to a certain amount. Maybe the tax implication is up to a certain amount. So I think it has to do with the preferences and you have to have the proper administration of these AI agents or else they're going to go off and blow up your account by accident. Uh different talks today about like this uh agentic you know agentify right how does this interact with finance probably most of the bots out there that trade high frequency trading have ways to you know figure out the best way to take advantage of the infrastructure. I think what we need is much more on the operating system level first. So imagine, you know, location for GPS. You don't care which satellite that you connect to. You kind of have a

general idea that you're connecting to some ISP, some services to get that result. Uh that abstraction is really important and in order to choose which path is best for you. So, if you're on Amazon and the last mile delivery, it doesn't matter about the brand of who's delivering it to, you just want something faster or cheaper or eco-friendly, whatever preference that you have. In that same way, you may just be closer to certain bare metal nodes or you may want something that, you know, runs on compute a little bit longer. And and so I think those preferences are what Den and and kind of in our space what we've been thinking about because we've been collecting data about access to RPCs and that's kind of our starting point to think about other services that

we can expand to. >> Cool. And any comments on the interface? Yeah. So, I think the best interface for me would be one where I can approve some steps, but it's not going to be as intrusive as I don't know if you remember like when you run like as an administrator on Windows and it just pops up like okay, I'll just do that every single time. It has to be in such a way that uh you you verify personally human in the loop what's going to happen and then when you get something right maybe it remembers the path that it took and maybe other people have written these workflows and paths and it will remember those paths that are taken and the reputation that's built with those

that are being you that are using these APIs will actually increase its usage overall. So what's like the SEO version with AI? there is an AI optimization for, you know, the version of search that happens with discoverability of these tools. >> Yeah, UX is a real challenge, but we're getting there. Um, so yeah, I mean, Agent Fi has obviously been a hot topic today, and it's clear that aenic systems are moving towards more and more autonomy. Um, and you could even say sovereignty, right? Like sovereign agents will eventually be a thing. Uh so to nater can you tell us about iigen cloud and about how some of those verifiable services can plug into agents

and yeah where does the rubber meet the road there >> so I think one of the things that are are like the most important characteristic of a blockchain it's that it's kind of like trustless right and it's also I would say um unruggable in the sense that if you can view the code and you can audit it and you know what it's going to do then no one can come in and like change that Right. But the uh nature of of AI agents is much more complex. You can't build an agent in a smart contract. There's so many reasons you cannot do that. But a few of the reasons are uh smart contracts are actionbased. Agents are essentially just running at all times. Um also you need a lot more flexibility than what you can do in a smart contract. You can't make external API calls. There's just a

million other things you can't do. So what is even the point of like crypto in this whole uh discussion? I think you would use uh smart contracts or you know a blockchain for trust like an underlying trust layer or for onchain like tokenized actions and then you would need some type of environment that is running this agent that has similar properties of a blockchain. Maybe you can't get everything. You can't have the full security of a chain at the moment. But you essentially need a trustless runtime. So what we're seeing a lot of people do at the moment are trusted execution environments. Now, if we're talking about trust trustless agents, the first word in a T is tr trusted. So, that's a problem already, right? So, I

think like what we're trying to achieve right now with iigen cloud and with a lot of other great teams building different TE products, it's like how can we make a trust uh a trustless execution environment? How can we have that program programmability and flexibility of a web server with the characteristics of a blockchain which are trustlessness, immutability, censorship resistance, all these different things. So one of the things that we have is I can compute. It's essentially a uh verifiable runtime where you can verify the code that's being written. there is a pneummonic a pneummonic that it's uh built into the runtime that only the runtime can spend and over time uh we will make it to where uh you're able to have I would say

delayed upgrades and also uh transparency into the code updates so there's no ability to kind of extract that pneummonic so you end up having kind of this runtime that no one has the the keys to that wallet other than the agent so it can if you send money to that agent address. It can spend it, but no one else can spend it. So, I think like uh the combining the programmability of a web server with the security of a blockchain is kind of what we're all trying to achieve to build these trustless agents. Uh I can compute is that product. And then you also need there's other layers of verifiability.

ERC8004 is great for uh reputation, but you also need uh the ability to have verifiable inference and also deterministic inference. So, I AI is another product that we have available. It allows you to essentially have similar characteristics of a blockchain in the in the sense that you can re-execute every uh inference and have the same output and you can also verify the model, the prompt and the response are actually what came from the LLM and then you can now build auditable uh products. You can build all types of like interesting uh mechanisms similar to blockchains. So that's kind of the two areas that that we're focused on and I think the the TE space with agents is a really really interesting one to look into in general.

Yeah, makes a lot of sense to maybe throwing it over to MTO. Um, if if we think about some of the layers of the stack that we spoke about earlier, um, which would you say are most critical to really be decentralized for agentic economies to work and like maybe touch on things like trust, payment, settlement? Okay, it's a it's a tricky question because I do think that Asians, this is my hot take, but Asians doesn't need to be like decentralized because you you're running them on a server. You you need to trust in the end LLM provider or LLM model

that you are running locally, right? Uh what I think that is really interesting is on the payment side because you have protocols like X42 uh that there are like big companies like Combase investing a lot on like in that in that protocol. Um, so I think that payments is like the the the coolest thing to decentralize for Asians because I do see a world where Asians are able to do their job and pay between have payments between Asians. Uh and yeah, I think one

>> oh I just wanted to add that uh yeah agents really really don't fit into the traditional decentralized definition but I do feel like we are moving to this multi- aent architecture um as a philosophy I do feel like eventually we're going to have to develop similar concepts to what to trust basically between agents because we're coming to a place where we have specialized agents developed by different teams on different stacks working on different environments. So I I do feel like agents do provide a great opportunity for people working with large amounts of data that can be

processed and summarized or provide opinions to to the users. But I do feel like there's an untapped potential in the other going the other way like learning from decentralized architectures what a blockchain is and how we can apply that to an ever ever expanding and ever more abstract concept of what an agent is because agents keep expanding but they keep getting more siloed or specialized. So we I think that eventually we're going to reach that point where we need to work on the concept of trust which right now we are not talking about something that uh I didn't hear mention

around uh identity is really important and I I worked on very early like decentralized identity uh types of projects and I think this might be the best use case for SS stations and figuring out the proofs that you have from others instead of you entering when your email and password are using Google to sign up or Facebook to sign in. Having the ability for your agent to prove its attestation to you and you are its owner um can do stuff on your behalf. And I think that the blockchain layer does provide you with a an ability to store that data and to be able to retrieve that properly. So >> yeah, definitely see how DIDs are relevant here. Um, I think Google's

actually done some great work with, you know, we we kind of have MCP as very much a trusted tool calling protocol, but A2A introduces and and A2P, you know, things like verifiable credentials and generally the architecture of the protocol assumes much less trust between parties, >> right? Because eventually you'll get a more broader context than the one you can actually control. So you'll default to a decentralized architecture eventually. That's where we at least that's where we're going today. Monday might be a different thing but right now uh we're going to a decentralized architecture and eventually we're going to need that concept of identity of trust of how can I I as a LLM powering

the reasoning of an agent. How can I define what the best tool or agent partner is to achieve my goal? And that's definitely going to need some sort of trust system so we can leverage. >> Okay, we're getting to the end here. So, let's move to some lightning questions. Uh, so I think almost everyone in the audience will have hacked together a basic agent with a while loop. Um, if you were to share one piece of dev experience from your respective stacks that you would recommend builders lean on, what would that be? We'll we'll start with Clemens.

>> So, I I think memory is really important. Uh, the instance that you have there's I I think in the future there'll likely be much larger context windows and it doesn't just get stuff together. But for me, when I was building my personal Clembot, that's my digital twin AI, the management of memory was interesting because the articles that I was reading, I would feed to my Clembbot to read at the same time. And then I would have a discussion about it. And that's kind of how I digest information now is there's almost a parallel version of me living in the digital world that's trying to update its memory with the applications and the feeds that I give it. And it's expensive to run, which is why I don't always run it, but when I do, I think it's really rewarding. But thinking about the memory

piece and how you can apply it to yourself at scale, it's a little bit harder because we we don't want to burn all the trees and run out of water. So I wouldn't suggest that we we build it at scale for the enterprise level. But I do think that on the personal level, it's fun to experiment with. >> Uh for me, it would be to like not sleep on the latest AI tools that are out there. Literally keep up with the newest thing that's out that people are hyping up. And if it's hyped up, jump on it, use it shamelessly. copy and paste hundreds and thousands of uh like lines of documentation and put them in your context. Don't try to learn everything anymore. It's just there's too much going on. Dump as much context in your code editor as possible and just build That's kind of my number one thing

I would say because it'll accelerate what you're doing. It's a different world today. Like 10 like lean into it 100x. No matter how things were a year ago, they're they're different today and they're going to be different a year from now. >> Yeah, I agree that it changes a lot. I would say that from Barcel side we have AI SDK that is our SDK to talk with any model that you want and I would recommend to use AI gateway that is our gateway to talk with any model right you you just change a string and you are talking with CHPd or with entropic or with any provider um I would say on top of that that something really cool about building AI applications is that every

time that you do a change, it's a hypothesis. It's sometimes it's just vibes. You know, you change a model and it's vibes, right? So, something cool is at Vascel, we have our feature flags and the biggest customer of our features flags product is Vzero. This is because we are testing all the time different models and different tools and different context and we are changing it like on the fly for users. We we test this new model to the 50% of our free users and we say okay was okay the the metrics and the observability is is right and we say okay but let's change it to back I don't

know to set and users are like in our feedback channel hey why this get worse so for AI apps the vibes needs to be right right so yeah I would recommend using AI gateway way to get higher rate limits to any model and our AICK to change it on the fly. >> Okay. Uh on my end, I probably would like to plus one Nator's comment on there's definitely not uh a definite stack I would use. We def we we change that a lot depending on the problem, the complexity. There are different use case that require different models. Some models are better on some use case than others. some architectures work better

than others. Um, personally we do use a lot of the Google tools obviously ADK which is the agent development git is the internal tool Google used to build their own agents that they open sourced and let out into the into the market. uh that plus a a agent engine which I also mentioned it does saves us a lot of headaches memory back in the day beginning of this year when we started working on agents back when we were young um implementing memory was a real pain right now that's being commoditized it's being it's being implemented it's been getting part of the de development

platforms but definitely ADK at least from as a developer it sits between Langraph and a NHN. So it's it's the LA right level of abstraction for me. Uh if you're not a technical person check out conversational agents which is a UI based interface in Google cloud you can use to build agents without a single line of code. >> Awesome. Clemens Nater Monto Juan thank you so much. Please join me in giving them a round of applause. Thank you.