Talk by Armanas Povilionis (Alithea Bio) arguing that agent-to-agent commerce should be built on verifiable work rather than payment checkout flows. The talk demonstrates one agent publishing a service, another discovering and invoking it, and a signed receipt proving what happened. It introduces Froglet, an open-source protocol and node for agent-to-agent compute, which reduces named services, data-backed services, and open-ended compute to a single signed flow: Descriptor → Offer → Quote → Deal → Receipt. The same surface is exposed through MCP and OpenClaw/NemoClaw as one tool, so agents can publish, discover, invoke, and verify work without custom integration per provider. The core claim is that receipts, identities, workload hashes, and deal state should survive across models, hosts, and marketplaces, since payment rails may change but verifiable work records must persist. # Channel Identity Observations: Armanas Povilionis / Alithea Bio ## Explicit Self-Description - **Organizational affiliation:** Speaker introduces himself as working at **Alithea Bio**, which "focus[es] on life sciences topics. More specifically, we work on immuno-oncology and immunopeptidomics." - **Dual role claim:** "While we work on science topics, we use ourselves and provide our clients agentic automation or agent AI solutions." — the presenter positions the organization as both a life-science practice and an **agent AI solutions provider to clients**. - **Product introduction:** The talk announces **Froglet**, "an open-source protocol for agents to discover, transact with, and receive verifiable receipt from external data and service providers," with a public site at **froglet.dev** and a GitHub presence ("please join us on GitHub"). ## Intended Audience - **Researchers and life-science organizations** seeking scientific research automation — evidenced by the framing question "what do you think is most valuable work that agentic automation can do? My guess… scientific research automation would be quite high up that list." - **Agent/AI practitioners and developers**, demonstrated by the technical demo (terminal walkthrough, Docker install, MCP server integration, Claude agent configuration) and instructions like "how to run froglet… just with one command." - **Potential data/service providers**, addressed via scenarios such as "You can ask [it] to connect to your database and provide row by row access for… a payment." ## Claimed Scope - **Cross-organizational agent collaboration** with verifiable trust: "in order to enable agents to collaborate, we need a way to have a verifiable chain of receipts… proving every step, ensuring that every result can be trusted." - **Integration, not replacement:** "It's not designed to replace, it's designed to integrate. Integrates with different payment rails… agent harnesses, execution environments, and even transport protocols." - **Open, heterogeneous network:** "It doesn't require that every node in the network uses the same software stack… We're just asking everybody to use the same interface." - **Stated mission framing:** a contrast between enterprise bespoke projects "that can take years and cost millions" versus a setup that "costs few thousand tokens and takes minutes." ## Demonstrated Presentation Patterns - **Live product demonstration** with terminal and website walkthroughs: remote trial node ("15 minutes trial identity"), local Docker install, and a Claude-driven service invocation producing the result "12." - **Analogy-driven explanation**: agents as "cooks in the kitchen" versus an "executive chef" running a "Michelin-star restaurant." - **Vision-oriented argumentation**: prediction that "organizations will give to the agents not only tools, they will give them budgets… to pay for work across organizational boundaries." - **Audience call to action with concrete channels:** "please join us either via Froglet or Alithea Bio. And please join us on GitHub." ## Claims vs. Demonstrated Evidence - **Creator claims (unverified here):** verifiability of signed receipts ("everything is being signed in a chain, and the chain is only valid if all data points are not tampered with"); ease of setup; open-source status. - **Demonstrated in the material:** a simple arithmetic service executed remotely and locally; a Claude agent following multi-step constraints to publish and invoke a service; the speaker's screen-based walkthrough of froglet.dev documentation. No curated metadata was supplied; all observations derive from the title and transcript. # Delivery Observation: "Agents Need Receipts, Not More Tool Calls" ## Overall Tone - **Conversational, lightly improvised pitch style** — the talk blends a structured vision pitch with a live terminal demo, delivered in an informal register ("Hello everybody. I'm Armandus."). - Frequent **verbal restarts and self-corrections** suggest spoken, unscripted delivery rather than a read talk: - "in in terms of discovery, request uh providers are publishing..." - "It It helps to find, to trust, to pay..." - "the the outcome depends on providers" ## Vocabulary & Framing - **Extended cooking analogy** is the talk's central framing device, sustained across the pitch: - "we imagine agents as cooks in the kitchen" - "scientific work is not cooking alone in your own kitchen. It is closer to running a Michelin-star restaurant" - "an agent is no longer just a cook with a better knife. It starts to act like a chef" - **Recurring key terms** — "verifiable receipt(s)" or "receipt" appears throughout ("a verifiable chain of receipts", "receive a verifiable receipt", "underneath there is a receipt"), anchoring the talk's title thesis. - **Contrast rhetoric**: repeated opposition of local vs. system-wide ("The challenge isn't local. It's not local tools.", "It's not designed to replace, it's designed to integrate"). ## Teaching Habits - **Rhetorical question to open**: "what do you think is most valuable work that agentic automation can do?" - **Signposting transitions**: "let's go to the next step", "Now, if I may, let me open our website", "So now maybe let's jump to a terminal". - **Enumerated structure** in the demo: "First of all... Second... And third..." for the three demo segments. - **Reassurance/summary pattern** — states what a system does *not* do before what it does: - "We're not trying to replace any of functionalities of other tools or protocols." - "We are not forcing everyone to use the same to to work the same way." - **Simple worked example** in demo: a "provider which adds two numbers", later verified "here we have an answer. It's 12. Fantastic, we have a correct answer." ## Communication Patterns - **Fillers and hedges** are pervasive: "uh", "um", "kind of", "maybe" ("we're already kind of doing this in a primitive form"). - **Emphasis through repetition**: "again and again and again", "That is it." - **Quantified benefit claims** to close the pitch contrast: closed-source collaboration "can take years and cost millions" vs. Froglet's setup "costs few thousand tokens and takes minutes." - **Action-oriented close with calls to action**: "please join us either via Froglet or Althea Bio. And please join us on GitHub." - Non-verbal sounds noted in transcript ("[clears throat]", "[snorts]") — observable but sparse; cannot establish any pattern from these alone. ## Uncertainty Notes - Single-talk sample; patterns like the cooking analogy are strong within this talk but stability across other talks is unverified. - No curated metadata was provided, so no cross-check on delivery context is possible. # Observation Record: "Agents Need Receipts, Not More Tool Calls" **Speaker:** Armanas Povilionis (self-identified as "Armandus"), Alithea Bio **Video ID:** 01a15ca8-7b2f-7a44-b3e5-1115ba85ebc7 ## Background & Context - Speaker works at **Alithea Bio**, focused on **immuno-oncology and immunopeptidomics**. - The company uses and provides clients with **agentic automation / agent AI solutions** for life sciences. - They identified a gap in current agentic tooling and are building a solution called **Froglet**. ## Core Claims & Reasoning ### 1. More tools alone won't suffice for agents - Speaker's opening premise: adding more tools to agents will not be enough, because **science (especially life sciences) is an inherently collaborative process**. - To enable agent collaboration, we need a **verifiable chain of receipts** proving every step, ensuring results can be trusted, and enabling **repeatability and collaboration at scale**. ### 2. Kitchen analogy - **Agents as cooks**: more/better tools (knives, pans, ovens) improve **local efficiency only**. - **Scientific work as a Michelin-star restaurant**: depends on produce providers, high-level services, and consistent repeatable quality. - Claim: "You cannot bring everything into one kitchen" — the challenge is **not local tools** but **aligning the entire supply chain** for repeatability and consistency. ### 3. Agents will manage budgets - Prediction: as agent workflow automation matures, organizations will give agents not just tools but **budgets** — beyond today's "primitive" token budgets. - Agents would manage their own budgets to: **discover services, request data, negotiate execution terms, pay for work across organizational boundaries**. - At that point an agent "starts to act like a chef… an executive chef" — finding suppliers, ordering, coordinating, keeping records. ### 4. Froglet: what it is - An **open-source protocol** for agents to **discover, transact with, and receive verifiable receipts** from external data and service providers. - Design principles: - Positioned "in between the moving parts" — **designed to integrate, not replace**. - Integrates with payment rails, agent harnesses, execution environments, transport protocols. - Does **not require the same software stack** at every node — only a **common interface**. - Contrast claim: **closed-source collaboration** tends to become bespoke enterprise projects taking years and costing millions before reusable workflows exist. Froglet aims to make the **transaction layer much lighter** — once a resource is deemed shareable and exposed, an agent can discover, understand terms, request work, and receive a verifiable receipt, at a cost of "a few thousand tokens" in "minutes." ## Demo Claims (as stated by speaker) - **Architecture**: a Froglet node is identical software everywhere; it plays different **roles** (provider, requester, marketplace). A marketplace is itself just a Froglet node providing certain services. Functions summarized as: **find, trust, pay, prove** work happened. - **Identity/signing**: each node generates a key pair for identity and signing; artifacts are signed in a chain, valid only if **no data points are tampered with**. - **Discovery**: providers publish services to a marketplace via the same protocol; requesters query marketplaces. After matching, **communication is direct — no third party**; quote, deal, execution, and receipt happen in one interaction. - **Agent integration**: plugins inside Froglet core work with execution environments/harnesses (mentions Open Claw, Nemo Claw), acting as an **MCP server or plugin**. Speaker's stated design stance: **the primary human interface should be an LLM**. - **Terminal demo**: remote node at try.froglet.com.dev offering a **15-minute trial identity**; demo of a simple add-two-numbers service (7+5=12), obtaining a **deal ID** and receipt. Local install via Docker with one command; showed that one **node ID** can assume **multiple roles simultaneously** (provider and consumer). - **Claude demo**: Claude with Froglet MCP enabled, instructed to use only the MCP and not install anything — it checked status, published an artifact from a template, invoked the service locally, and returned 12. Speaker framed this as showing the agent "understands constraints." - **Use-case flexibility** (speaker's examples): a database offering row-by-row access for payment, or a GPU accepting computation requests. - **Context claim**: Froglet packages underlying protocols so "you're not shoving everything into an LLM context" — receipt, payment, execution, negotiation, and marketplace are handled underneath. ## Concluding Summary (speaker's framing) Froglet provides three capabilities: 1. Finding resources outside organizational boundaries 2. Allowing agents to execute remote commands 3. Verifiable receipts of what happened Speaker's closing claim: this **enables collaborative science** and "the progress of a perpetual science automation." ## Calls to Action - Visit **froglet.dev** (also referenced as try.froglet.com.dev for the trial node) - Join via Froglet, Alithea Bio, or **GitHub** ## Qualifications & Notes - Speaker's prediction about agent-managed budgets is explicitly framed as a future vision ("our vision is that…"), not a present fact. - The demo service is acknowledged as "a very simple example" (adding two numbers). - Speaker notes execution wait time "depends on the load" on the temporary cloud node. - Speaker self-describes as guessing audience priorities ("My guess… scientific research automation would be quite high up that list") — stated as conjecture. # Speaker Attribution & Provenance Record ## Video - **Title:** Agents Need Receipts, Not More Tool Calls - Armanas Povilionis, Alithea Bio - **Video ID:** `01a15ca8-7b2f-7a44-b3e5-1115ba85ebc7` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Armanas Povilionis ("Armandus" per self-introduction) | **Sole speaker / creator / presenter** | Opens with "Hello everybody. I'm Armandus. I work at Alifeia Bio" and delivers the entire talk solo | - **No other speakers** appear in the transcript (no guest, narrator, or co-presenter). - No timestamps are present in the transcript; segment boundaries are inferred from content flow and are approximate. ## Presentation Structure (Inferred, No Timestamps) - **Introduction:** Self-introduction; Alithea Bio's focus on immuno-oncology and immunopeptidomics; framing of the problem. - **Conceptual framing:** Agents as cooks vs. executive chefs; supply-chain analogy. - **Product introduction:** Froglet, an open-source protocol for agent discovery, transactions, and verifiable receipts. - **Live demo segments:** - Website walkthrough (froglet.dev) - Terminal demo: remote node trial, local Docker installation, and Claude-based agent interaction. - **Closing:** Summary and calls to action. ## Promotional Segments (Flagged) - ⚠️ **Product promotion — Froglet:** The talk introduces and demonstrates the speaker's own project ("we're building Froglet"), including a live demo. - ⚠️ **Website/distribution promotion:** "go to our page froglet.dev" for documentation, local install, and remote trial. - ⚠️ **Calls to action:** "please join us either via Froglet or Althea Bio. And please join us on GitHub." ## Referenced Sources & Third-Party Claims - **froglet.dev** — product website referenced for documentation and installation instructions. - **try.froglet.com.dev** — remote trial node used in the demo. - **Mentioned integrations (named only, no details):** Open Claw / Nemo Claw, MCP server/plugin, Docker, payment rails, execution environments, transport protocols. - **Claude (Anthropic LLM)** — used as the agent interface in the demo. - **No cited external studies, publications, or third-party data sources** appear in the transcript. - Third-party claims: none identified beyond the speaker's own claims about his product. ## Provenance Facts - **Domain affiliation:** Speaker works at Alithea Bio (life sciences, immuno-oncology, immunopeptidomics). - **Product status:** Froglet described as open-source and in development ("a solution which we're working on"). - **Demo evidence:** On-screen demo of token creation, payload execution (7+5=12), local Docker install, and Claude agent invocation. - **Comment availability:** Not stated in the transcript or metadata; unknown. - **Curated metadata:** None supplied beyond the title. ## Uncertainty Notes - Speaker's name spelling varies between title ("Armanas Povilionis") and self-introduction ("Armandus"); company name rendered variously as "Alithea Bio" (title) and "Alifeia Bio" (transcript) — likely transcription variance. - No timestamps, participant metadata, or channel information provided. Hello everybody. I'm Armandus. I work at Alifeia 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 ourselves and provide our clients agentic automation or agent AI solutions. However, we found a certain gap which we would like to discuss today and we have a solution which we're working on which we would like to share. It's called Froglet. But to start with, I would like to ask what do you think is most valuable work that agentic automation can do? My guess, uh scientific research automation would be quite high up that list. However, from my experience, adding more tools to agents will not suffice. Because science and especially lives in in specially in life sciences is inherently collaborative process. And 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 which can provide these receipts proving every step, ensuring that every result can be trusted, and enabling repeatability as well as collaboration at scale. Having these pieces in mind, let's go to the next step. So, stepping back, um we imagine agents as cooks in the kitchen. Giving them more tools or better tools, it improves kitchen's 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 the the outcome depends on providers and quality of your produce, high-level services, as well as an 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 that it's repeatable and consistent. Today, we have already agents with plenty of tools and increasing in volume, number, and quality. And we also have on the hand data and specialized analytics algorithms and compute which is 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're already kind of doing this in a primitive form by allocating tokens for token budgets for a specific task. But, what I'm talking 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. Uh like a executive chef, uh finding suppliers, ordering ingredients, coordinating work at at the kitchen, and finally keeping the record of what has happened. That is why we're building Froglet. An open-source protocol for agents to discover, transact with, and receive verifiable receipt from external data uh data and service providers. For more detailed information, obviously, go to our page froglet.dev, uh where you will find um general descriptions on how it works, what it integrates with. It Froglet is designed to be in between the moving parts. It's not designed to replace, it's designed to integrate. 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 to work the same way. We're just asking everybody to use the same interface. In the web page, you will find how to run froglet with just how to install it locally just with one command. Or even how to run it remotely just with one prompt. So in essence, what we are saying is closed source and the collaboration often turns into a bespoke project, enterprise project that can take years and cost millions before any reusable workflow exists. On the other hand, froglet's mission is to make transaction layer much lighter. Once an organization decides that the data or resource or service is deemed shareable and it's exposed on froglet, an agent can discover it, understand the terms, request the work, and receive a verifiable receipt. That setup costs few thousand tokens and takes minutes. Now, if I may, let me open our website for quick second. So if you land our 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. And most of the 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. So first of all, we define 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 It helps to find, to trust, to pay, and to prove that the work has happened. That is it. We're not trying to replace any of 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 the artifacts. And during the execution, everything is being signed with that signature. Meaning, everything is being signed in a chain, and the chain is only valid if all data points are not tampered with. And in in terms of discovery, request uh providers are publishing what services they uh they uh they're providing to the marketplace using the same protocol. And requester requests a known marketplace just to provide lists of services that are available on that marketplace. From that that moment on, once the requester identifies the service that they want to work with, the communication is direct. There is no uh 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 uh are the plugins that we placed inside the Froglet core. It integrates with different execution environments and different harnesses, whether it's Open Claw, Nemo Claw, it's acts as an MCP server or plugin, and it's primarily designed that it is used by an 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 to 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 a 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 we what I would like to do is to run a command to check whether Froglet try.froglet.com.dev actually exists and it works. That's fine. So now what I can do is to create myself a token. And this this creates a temporary token for 15 minutes. And you can see it here created. And then what I can do also in exactly 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 the tokens are different. That means that froglet nodes are different. Now, in order to execute this service, what I need, I need to create a payload. So, I created 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 seven and \[clears throat\] five, 7 + 5. Now, what I need is to provide this payload 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 \[snorts\] that it takes some time to so 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 uh that runs on on the cloud. And here we have an answer. It's 12. Fantastic, we have a correct answer. Um, so we have a entire loop finalized. Now, in order to run it locally, um what I need is to install it here. So, first of all, I will clear everything. As you see, the uh the the directory is empty, and what I do is I what I run is HBS 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 uh there are two Froglets running, um but if I look at at the actually not IP addresses and ports, but I actually look at the node ID, I see that this is one and the same ID. And that means that each each Froglet can assume different roles, and at 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 ports, same IP addresses, my local ins installations. So, now Claude, if I open my Claude, first of all, what I need to do uh 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 from that um CP only. Do not install anything. And um let's be very specific. Let's see if it understands constraints. And I have here prepared a couple of steps. I won't do it them one by one. I'll actually ask it to do it all at once. In steps and provide the specific output. Great, it even goes ahead and um uh checks what is running. And what I'm asking it to do is first of all to see what was the status is life, 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. \>\> \[snorts\] \>\> Then uh what I want it that it actually finds and calls that service and invokes it locally. Uh asking it to add again five and seven. And it can wait a bit because it's an asking for a call. And then show the output what it got. So if if we go if we go down here, here is what we see that it actually executes all commands. And what we see that is actually um done exactly as we asked. We 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 to 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 the requests for computa- any kind of computation. In essence, it's a very simple way how to use it, but it packages a lot of um underlying protocols and underlying tools where now you're not shoving everything into a uh 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 uh there is a negotiation and marketplace uh hidden and it's uh doesn't stuff your LLM with context. So, going back to the slides. Some reason it scrolled down. Going back to the slides. Um So, what we what we have uh on our hands. Uh we have an open protocol called froglet 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, uh what it allows, it allows to have a verifiable receipt of receipts of what has happened. And I think that actually enables a collaborative science. That enables a progress of a perpetual science automation. So, please join us either via Froglet or Althea Bio. And please join us on GitHub. And thank you for listening.