Agents Need Receipts, Not More Tool Calls - Armanas Povilionis, Alithea Bio

Transcript

Hello everybody, I'm Armanos. I work at Alifea Bio, where we focus on life sciences topics. More specifically, we work on immuno-oncology and immunopeptidomics. While we work on science topics, we use and provide our clients agentic automation or agentic AI solutions. However, we found a certain gap, which we would like to discuss today, and we have a solution we are working on that we would like to share. It's called Froglet. To start with, I would like to ask: what do you think is the most valuable work that agentic automation can do? My guess is scientific research automation would be quite high up that list. However, from my experience, adding more tools to agents will not suffice because science, especially life sciences, is an inherently collaborative process. In order to enable agents to collaborate, we need a way to have a verifiable chain of receipts. What do I mean? We need a solution that can provide these receipts, proving every step, ensuring that every result can be entrusted, and enabling repeatability as well as collaboration at scale. Having this thesis in mind, let's go to the next step. Stepping back: We imagine agents as cooks in the kitchen. Giving them more tools or better tools improves kitchen efficiency. Better knives, more pans, more ovens definitely boost the speed and quality. But it only enhances the local work. On the other hand, scientific work is not cooking alone in your own kitchen. It is closer to running a Michelin star restaurant. To overcome this business, the outcome depends on providers and quality of your produce, high-level services, as well as an ability to consistently deliver the same quality dish again and again and again. You cannot bring everything into one kitchen. The challenge isn't local. It's not local tools. The challenge is aligning the entire supply chain so that it's repeatable and consistent. Today, we already have agents with plenty of tools, increasing in volume, number, and quality. We also have on our hands data and specialized analytics algorithms and compute, which are distributed across different organizations and siloed. So our vision is that whenever AI agent workflow automation matures, organizations will give to the agents not only tools, they will give them budgets. We are already doing this in a primitive form by allocating token budgets for a specific task. But what I am talking about is a bit broader. It's allowing agents to manage their own budgets to achieve their own goals, whether it's to discover services, request data, negotiate execution terms, or pay for work across organizational boundaries. At that point, an agent is no longer just a cook with a better knife. It starts to act like a chef, like an executive chef, finding suppliers, ordering ingredients, coordinating work at the kitchen, and finally keeping the record of what has happened. That is why we are building Froglet, an open source protocol for agents to discover, transact with, and receive verifiable receipts from external data and service providers. For more detailed information, go to our page, froglet.dev, where you will find general descriptions of how it works and what it integrates with. Froglet is designed to be in between the moving parts. It's not designed to replace; it's designed to integrate. It integrates with different payment rails, it integrates with different agent harnesses, execution environments, and even transport protocols. And it doesn't require that every node in the network uses the same software stack. That's the beauty. We are not forcing everyone to use the same, to work the same way. We're just asking everybody to use the same interface. On the webpage, you will find how to run Froglet, how to install it locally with just one command, or even how to run it remotely with just one prompt. In essence, what we're saying is closed source scientific collaboration often turns into a bespoke enterprise project that can take years and cost millions before any reusable workflow exists. On the other hand, Froglet's mission is to make the transaction layer much lighter. Once an organization decides that the data, resource, or service is deemed shareable, and it's exposed in Froglet, an agent can discover it, understand the terms, request the work, and receive a verifiable receipt. That setup costs a few thousand tokens and takes minutes. If I may, let me open our website for a quick second. If you land on our homepage, you will see a couple of things. First, a lot of helper information, which allows you or your agent to read through and understand how it works. Most of our webpage is focused on agent use. But also, we have some helpful documentation for you. Let me go through a couple of steps in the demo. First of all, we find that a Froglet node by itself is not different implementations at each site. It is actually exactly the same node. It just plays different roles, whether it's a provider, requester, or marketplace. Marketplace itself is just a Froglet node, which is providing certain services. And what does it help to do? It helps to find, to trust, to pay, and to prove that work has happened. That is it. We're not trying to replace any other functionalities of other tools or protocols. Whenever you are generating or creating a new node, it generates a key pair for identity and signing the artifacts. During the execution, everything is being signed with that signature. Meaning everything is being signed in the chain, and the chain is only valid if all data points are not tampered with. In terms of discovery requests, providers are publishing what services they are providing to the marketplace using the same protocol. And the requester requests a known marketplace just to provide lists of services that are available in that marketplace. From that moment on, once the requester identifies the service that they want to work with, the communication is direct. There is no third party. Everything from quote to deal to execution and receipt happens in one interaction. Let me jump forward a bit. So far, what I showed you is just a node talking to a node. Where Agent comes in are the plugins that we placed inside the Froglet core. It integrates with different execution environments and different harnesses, whether it's OpenClaw, NemoClaw. It acts as an MCP server or plugin, and it's primarily designed so that it is used by an agent. The primary interface for humans should be an LLM. An LLM should drive usage of Froglet, whether you are a provider or a requester. So now maybe let's jump to a terminal, and I will show you a couple of things. First of all, I will show you how you can use Froglet remotely, meaning that there is a Froglet node running on a remote server where you can access and get a 15-minute trial identity that you can play with. Second, how to run a Froglet locally on my machine here on Docker. And third, how I will ask my Claude to interact with a local installation and actually configure a service and try it out. So first of all, what I would like to do is run a command to check whether Froglet try.froglet.dev actually exists and works. That's fine. So now what I can do is create myself a token, and this creates a temporary token for 15 minutes, and you can see it here, created. Then what I can also do, in exactly the same manner, is have access to the specific provider token. This is a specific provider which adds two numbers. It's a very simple example service provider. As you see now that the tokens are different, that means the Froglet nodes are different. So now, in order to execute this service, what I need is to create a payload. So I create a payload which includes many things, including schema, what kind of service I'm targeting, also which provider, and finally what input I'm providing to it. So I'm providing it to my remote Froglet. And this executes. I need to get a deal ID, and this is where I have a receipt of the deal actually happening. Now the deal has an ID already, but it might happen that it takes some time to execute. So I take a for command, for loop, to actually wait for it, but it depends on the load on that temporary small node that runs on the cloud. And here we have an answer. It's 12. Fantastic. We have a correct answer. So we have an entire loop finalized. Now, in order to run it locally, what I need is to install it here. So first of all, I clear everything. As you see, the directory is empty. And what I run is HTTP AES froglet dev agent. What it will do is download and install agent on Docker. Let's wait a second. It's actually already there. So it just confirms that it doesn't need to download anything. And it's working, and it's running. Now I can see that there are two Froglets running. But if I look at not the IP addresses and ports, but I actually look at the node ID, I see that this is one and the same ID. That means that each Froglet can assume different roles and at the same time can assume multiple roles. We have here two roles, as a provider and consumer at the same time. And just to prove that I'm running it on Docker, here it is, running on the same port, same IP addresses, my local server, my local installations. So now Claude. If I open my Claude, first of all, what I need to do is see where froglet.mcp is enabled. And it is. That's fantastic. What I will ask it to do is, first of all, I will change the permissions so that it doesn't bug me. And what I will ask it is: use froglet.mcp only. Do not install anything. Let's be very specific, and let's see if it understands the constraints. I have here prepared a couple of steps. I won't do them one by one. I'll actually ask it to do it all at once. Great, it even goes ahead and checks what is running. What I'm asking it to do is, first of all, see whether the status is live, which it already did above. Then, if provider and runtime are healthy, then I want it to publish an artifact from a template, which is exactly the same template, add two numbers. Then what I want is that it actually finds and calls that service and invokes it locally, asking it to add again 5 and 7. It can wait a bit because it's an asynchronous new call. Then show the output. If we go down here, here is what we see: it actually executes all commands. And what we see is that it's actually done exactly as we asked, or it has a result, sum 12. What does this mean? This means that now, using exactly the same installation, I can ask this installation to provide access to any arbitrary code that I have on my local machine, and it can create anything that you want. It can connect to your database, and you can ask Claude to connect your database and provide row-by-row access for a payment, or you can have your GPU running in the background and welcome requests for computation, any kind of computation. In essence, it's a very simple way how to use it, but it packages a lot of underlying protocols and underlying tools, where now you're not shoving everything into an LLM context. It just has the services that it needs to interact with, and underneath there is a receipt, there is a payment, there is an execution environment, and there is a negotiation and marketplace hidden, and it doesn't stuff your LLM context. Going back to the slides, for some reason it's scrolled down. Going back to the slides: What do we have on our hands? We have an open protocol called Froglet, which has multiple things. First of all, it provides a way to find resources outside the organizational boundaries. Then it allows your agents to actually execute remote commands. And third, what it allows is to have a verifiable chain of receipts of what has happened. And I think that actually enables collaborative science. That enables the progress of perpetual science automation. So please join us either via Froglet or Alfea Bio, and please join us on GitHub. Thank you for listening. So, if I may, let me open our website for a quick second. So, if you go and land our homepage, you will see a couple of things. First, a lot of helper information, which allows you or your agent to read through and understand how it works. So, let's see if we have a lot of information on our website, and most of our webpage is focused on agent queues. But, also, we have some helpful documentation for you. Let me go through a couple of steps in the demo. So, first of all, we find that froglet node by itself is not different implementations at each site. It is actually exactly the same node. It just plays different roles, whether it's a provider, requester, or marketplace. Marketplace itself is just a froglet node, which is providing certain services. And what does it help to do? It helps to find, to trust, to pay, and to prove that work has happened. That is it. We're not trying to replace any other functionalities of other tools or protocols. Whenever you are generating a or creating a new node, it generates a key pair for identity and signing and the artifacts. And during the execution, everything is being signed with that signature. Meaning, everything is being signed in the chain, and the chain is only valid if all data points are not tampered with. And in terms of discovery requests, providers are publishing what services they are providing to the marketplace using the same protocol. And the requester requests a known marketplace just to provide lists of services that are available in that marketplace. From that moment on, once the requester identifies the service that they want to work with, the communication is direct. There is no third party. And everything from quote to deal to execution and receipt happens in one interaction. Let me jump forward a bit. So, so far what I showed you is just a node talking to a node. Where Agent comes in are the plugins that we placed inside the Froglet core. It integrates with different execution environments and different harnesses. whether it's OpenClaw, NemoClaw, it acts as an MCP server or plugin, and it's primarily designed that it is used by an agent. The primary interface for humans should be an LLM. An LLM should drive usage of Froglet, whether you are a provider or a requester. So now maybe let's jump to a terminal and I will show you a couple of things. First of all, I will show you how you can use Froglet remotely, meaning that there is a Froglet node running in a remote server where you can access and get a 15 minutes trial identity which you can play with. Second, how to run a Froglet locally on my machine here on Docker. And third, how I will ask my Claude to interact with local installation and actually configure a service and try it out. So first of all, what I would like to do is to run a command to check whether Froglet try.froglet.dev actually exists and it works. That's fine. So now what I can do is to create myself a token and this creates a temporary token for 15 minutes and you can see it here, created. And then what I can do also in exactly the same manner, I can have access to the specific provider token and this is a specific provider which adds two numbers. It's very simple example service provider. As you see that now the tokens are different, that means the Froglet nodes are different. So now in order to execute this service, what I need, I need to create a payload. So I create a payload which includes many things including schema, what kind of service I'm targeting, also which provider and finally what input I'm providing it to. So I'm providing it a payload to the remote. So I'm providing it to my remote. So I'm providing it to my remote. Remote Froglet. And this executes I need to get a deal ID and this is where I have a receipt of actually deal happening. Now deal has an ID already, but it might have happened that it takes some time to execute. So I take a for command, for loop to actually wait for it, but it depends on the load on that temporary small node that runs on the cloud. And here we have an answer. It's 12. Fantastic. We have a correct answer. So we have an entire loop finalized. Now in order to run it locally, what I need is to install it here. So first of all, I go clear everything. As you see the directory is empty. And what I run is HTTP AES froglet dev agent. And what it will do, it will download and install agent on a Docker. Let's wait a second. It's actually already there. So it just confirms that it doesn't need to download anything. And it's working and it's running. And now I can see that there are two froglets running. But if I look at the actually not IP addresses and ports, but I actually look at the node ID, I see that this is one in the same ID. And that means that each froglet can assume different roles and the same time can assume multiple roles. And we have here two roles as a provider and consumer at the same time. And just to prove that I'm running it on a Docker, here it is running on the same port, same IP addresses, my local server, my local installations. So now cloud. If I open my cloud, first of all, what I need to do is to see where froglet.mcp is enabled. And it is. That's fantastic. And what I will ask it to do is, first of all, I will change the permissions that it doesn't bug me. And what I will ask it is use from froglet.mcp only. Do not install anything. And let's be very specific. And let's see if it understands the constraints. And I have here prepared a couple of steps. I won't do them one by one. I'll actually ask you to do it all at once. Great, and even goes ahead and checks what is running. And what I'm asking it to do is, first of all, I will be able to see whether the status is live, which already did above. Then if provider and runtime is healthy, then I want it to publish an artifact from a template, which is exactly the same template, add two numbers. Then what I want it that it actually finds and calls that service and invokes it locally, is asking it to add again 5 and 7. And it can wait a bit because it's an asynchronous new call. And then show the output and then show the output. So if we go down here, here is what we see that it actually executes all commands. And what we see that it's actually done exactly as we asked or it has a result some 12. and it it can create anything that you want it can connect to you can ask load to connect your database and provide row by row access for for uh for a payment or you can have a just your gpu running in the background and welcome requests for computation any kind of computation in essence it's a very simple way how to use it but it packages a lot of underlying protocols and underlying tools where now you're not shoving everything into a LLM context it just has a services that it needs to interact and underneath there is a receipt there is a payment there is a execution environment and there is a negotiation and marketplace hidden and it's doesn't stuff your LLM context so going back to the slides some reason it's called down going back to the slides um so what we what do we have on our hands we have an open protocol called froglet loglet which um has multiple things first of all uh it uh provides a way uh to to find resources outside the organizational boundaries then it allows your agents to actually execute uh remote uh commands and third what it allows it allows to have a verifiable chain of receipts of what has happened and i think that actually enables a collaborative science that enables a progress of perpetual science automation so please join us either via froglet or alfea bio and please join us on github and thank you for listening