# Agents Need Receipts, Not More Tool Calls

Armanas Povilionis, Alithea Bio | AI Engineer World's Fair 2026 | 19:36

Source: https://www.youtube.com/watch?v=Fu45geO3zX8
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/agents-need-receipts-not-more-tool-calls
Published: 2026-07-18
Tags: mcp, open-source, security, tool-use

## TL;DR
- Adding more tools to an agent does not solve collaboration across organizations because scientific work depends on repeatable services, data, and compute from different providers.
- Froglet lets agents discover services, negotiate execution, run work, and receive a signed receipt through a shared interface that can connect different stacks and payment rails.
- Agents can use Froglet through MCP, OpenClaw, NemoClaw, or a remote or local node, while the underlying service, payment, negotiation, and execution details stay outside the LLM context.

## Summary
Armanas Povilionis argues that agents need a reliable way to coordinate work across organizational boundaries. More tools improve what an agent can do inside one environment, but scientific workflows depend on outside data, specialist analytics, compute, and service providers. Froglet is his open-source protocol and node for this transaction layer. A provider publishes a service, a requester discovers it, the parties agree on execution, and the system produces a signed receipt. Each node creates an identity key pair and signs the artifacts in the execution chain. The same node can act as provider, requester, or marketplace, and different nodes do not need to run the same software stack. In the demo, Povilionis uses a remote service and a local Docker installation to publish and invoke an add-two-numbers service through Claude and MCP. The result is 12, with the deal and receipt recorded underneath the agent interaction.

## Key ideas
### More tools improve local agent work, while scientific workflows depend on collaboration
[00:54](https://www.youtube.com/watch?v=Fu45geO3zX8&t=54s)
Povilionis says adding tools to agents will not solve the main problem in scientific automation. He compares an agent with better tools to a cook with better knives, pans, and ovens. Those improvements make one kitchen more efficient, but scientific work resembles running a Michelin-star restaurant. The result depends on suppliers, produce, specialist services, and consistent delivery. Data, analytics algorithms, and compute already sit across different organizations and silos. The problem therefore spans the supply chain, where each part needs to work in a repeatable way with the others.

### Agents will need budgets to discover, negotiate, and pay for outside work
[03:05](https://www.youtube.com/watch?v=Fu45geO3zX8&t=185s)
Povilionis expects organizations to give agents budgets alongside tools as workflow automation matures. Token budgets for a task are an early, limited version of this idea. A broader budget would let an agent discover services, request data, negotiate execution terms, and pay for work across organizational boundaries. He compares this agent to an executive chef that finds suppliers, orders ingredients, coordinates work, and keeps a record of what happened. The record matters because the agent is coordinating actions outside its own local environment.

### Froglet adds a shared transaction layer without forcing one software stack
[04:38](https://www.youtube.com/watch?v=Fu45geO3zX8&t=278s)
Froglet is an open-source protocol for agents to discover, transact with, and receive verifiable receipts from external data and service providers. Povilionis says it is designed to integrate with payment rails, agent harnesses, execution environments, and transport protocols rather than replace them. Nodes do not have to use the same software stack. They need to use the same interface. Once an organization exposes a shareable data resource or service, an agent can discover it, understand the terms, request the work, and receive a receipt.

### A Froglet node can take several roles and signs the execution chain
[07:36](https://www.youtube.com/watch?v=Fu45geO3zX8&t=456s)
The same Froglet node can act as a provider, requester, or marketplace. A marketplace is also a Froglet node that provides services. A new node creates a key pair for identity and signing artifacts. During execution, the artifacts are signed in a chain, and the chain is valid only when its data points have not been tampered with. Providers publish services to a marketplace, while requesters ask the marketplace for available services. Once a requester chooses a service, communication becomes direct, and the quote, deal, execution, and receipt happen in one interaction.

### Agents drive Froglet through existing harnesses and MCP
[09:34](https://www.youtube.com/watch?v=Fu45geO3zX8&t=574s)
Froglet places plugins inside its core so it can work with different execution environments and agent harnesses. Povilionis names OpenClaw and NemoClaw and says Froglet can act as an MCP server or plugin. He describes the primary human interface as an LLM, with the model driving Froglet whether it is acting for a provider or a requester. This keeps the agent-facing surface consistent while the underlying execution environment and protocols can differ.

### The demo shows remote execution with temporary identities and a signed deal
[10:48](https://www.youtube.com/watch?v=Fu45geO3zX8&t=648s)
Povilionis first connects to a remote Froglet node and creates a temporary token for a 15-minute trial identity. He also gets a separate provider token for a service that adds two numbers. The request payload includes the schema, target service, provider, and inputs of 7 and 5. Submitting the payload returns a deal ID. Because execution can take time, he polls the deal until it completes and receives the answer 12. The deal ID and receipt provide a record that the interaction happened.

### A local node can publish and invoke a service through Claude
[13:25](https://www.youtube.com/watch?v=Fu45geO3zX8&t=805s)
For the local demo, Povilionis runs Froglet in Docker and shows that the local nodes have the same node ID while taking provider and consumer roles. He then opens Claude, confirms that Froglet MCP is enabled, restricts it to the existing MCP tools, and asks it to perform several steps. Claude checks the node status, verifies the provider and runtime, publishes an add-two-numbers artifact from a template, finds and invokes the service locally, and reports the result. It completes the requested flow and returns 12.

### Receipts keep service interactions outside the LLM context
[17:17](https://www.youtube.com/watch?v=Fu45geO3zX8&t=1037s)
Povilionis says Froglet packages several underlying protocols and tools without putting every detail into the LLM context. The agent interacts with the services it needs, while the receipt, payment, execution environment, negotiation, and marketplace remain underneath that interaction. He gives possible providers such as a database that exposes row-by-row access for a payment or a GPU that accepts computation requests. In his view, remote execution plus verifiable records can support collaboration in scientific workflows.

## Notable quotes
- "Adding more tools to agents will not suffice." (00:54)
- "We're just asking everybody to use the same interface." (05:30)
- "Everything from quote to deal to execution and receipt happens in one interaction." (09:02)
- "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." (17:20)

## Tools & references mentioned
- Alithea Bio
- Froglet
- froglet.dev
- MCP
- OpenClaw
- NemoClaw
- Claude
- Docker
- GitHub

## Who should watch
- You are building agents that need to use data, compute, or services owned by other organizations and need a record of what occurred.
- Your agent workflow involves payment, negotiation, or execution across providers, and API logs do not give you a shared proof of the deal.
- You work on scientific automation and want to see a concrete remote and local service flow exposed through MCP.
