Agents Need Receipts, Not More Tool Calls

What is the most valuable work to automate with agents? Scientific research is a strong candidate—but giving an agent more tools does not resolve the dependencies between collaborators. Drawing on a decade of life sciences collaboration projects, Armanas Povilionis identifies a missing requirement: a chain of verifiable receipts that documents the steps performed across organizations. The goal is to make results trustworthy enough for other participants to build on them.

Imagine agents as cooks. Better knives, more pans, and more ovens improve the speed and quality of work inside a kitchen. Scientific collaboration resembles running a restaurant: the outcome also depends on suppliers and their produce, the service provided, and the ability to deliver the same quality repeatedly. You cannot bring that entire system into one kitchen.

The corresponding engineering problem is coordinating the supply chain. Agent tools already exist, but the data and specialized analytical algorithms needed for scientific work remain distributed across organizations. Improving a local agent does not, by itself, give it a dependable way to obtain those external resources.

Alithea’s vision for Froglet starts with a change in what organizations delegate. Agents already receive token budgets for individual tasks. A broader budget would let an agent discover services, request data, negotiate execution, and pay for work across organizational boundaries. That is a larger responsibility than choosing which local tool to call.

In the restaurant analogy, the agent becomes an executive chef: finding suppliers, ordering ingredients, coordinating work, and keeping records. Froglet is the proposed protocol connecting those activities. It lets agents discover external data and service providers, transact with them, and receive verifiable receipts. Procurement and recordkeeping become parts of the same workflow.

Froglet is designed to sit between existing systems rather than replace them. Its integration points include payment rails, agent harnesses, execution environments, and network transports. Participants need a common interface, not identical surrounding software stacks. This matters when a requester and a scientific service provider belong to different organizations with different infrastructure.

The talk points to the project website for a local run advertised as requiring one command, or a remote trial advertised as requiring one prompt. The current hosted trial is narrower than the full transaction vision: it demonstrates free services and signed receipts, not paid settlement, persistent identity, or service publication.

Povilionis says bespoke scientific collaborations can take years and cost millions before producing a reusable workflow. Froglet’s proposed shortcut begins after a critical organizational decision: the resource has already been deemed shareable. The protocol does not replace that approval.

Once that decision is made, the intended workflow is straightforward:

1. The provider exposes the approved resource through Froglet.
2. An agent discovers it and understands its terms.
3. The agent requests the work.
4. The agent receives a verifiable receipt.

Povilionis says this approved-resource workflow takes minutes and costs a few thousand tokens. That is a scoped claim, not a measured speedup against the entire collaboration process; the talk supplies no benchmark methodology.

The demonstration then opens the website’s walkthrough, with documentation available for a deeper explanation. The walkthrough moves from the publication workflow to the network roles and records that support it.

The network shown in the walkthrough consists of homogeneous nodes: every actor runs the same core, but plays a different role.

The marketplace is itself a Froglet node, not a separate kind of core infrastructure.

Together, these roles address four connected questions: how a requester finds a provider, how the participants establish trust, how they pay or settle, and how they retain evidence that execution occurred. Discovery alone would answer only the first question.

Creating a node generates a key pair for identity and signing. In the walkthrough, the transaction history proceeds through a descriptor, offer, quote, deal, invoice, and finally a receipt. The node’s keys sign records along that chain, connecting the initial description and commercial commitments to the final execution record.

For an application displaying this sequence, a small TypeScript model can keep unfinished work visibly separate from a transaction with a receipt:

type Stage =
  | "descriptor"
  | "offer"
  | "quote"
  | "deal"
  | "invoice"
  | "receipt";

const stages: readonly Stage[] = [
  "descriptor", "offer", "quote", "deal", "invoice", "receipt"
];

function receiptStatus(records: readonly { stage: Stage }[]): string {
  return records.some(record => record.stage === "receipt")
    ? "Receipt present; verify signatures and chain"
    : "Receipt pending";
}

const transaction: { stage: Stage }[] = stages
  .slice(0, 4)
  .map(stage => ({ stage }));

console.log(receiptStatus(transaction)); // Receipt pending

This models record presence only. A record labeled receipt still needs verification; its presence is not a cryptographic check.

Povilionis describes the chain as tamper-evident: changing a component breaks the chain. The essential distinction is between integrity of the record and correctness of the scientific result. Signatures can make commitments attributable and alterations detectable; they do not independently establish that an analysis is scientifically correct.

Discovery uses the marketplace, but subsequent execution does not require it as an intermediary. Providers register and describe their services there. The marketplace supplies descriptions and an index of available services. Once a requester finds a provider through that index, the two communicate directly. Povilionis describes requests, signing, execution, and receipt as one interaction between the requester and provider—not as a requirement to route every step through a middleman.

For services that are not free, the proposed payment model has two parts:

The split addresses two different risks: a provider can spend resources handling requests, while a requester can pay for work that fails to deliver. It is an incentive mechanism, not a guarantee of correct results. The talk does not specify how success is verified or disputes are resolved.

Froglet is not an AI agent. It is an interface intended for agents to find each other, discover data and services across organizational boundaries, and execute deals directly. The agent chooses what work to pursue; the protocol supplies the transaction structure around that work.

The scientific ambition depends on connecting those capabilities: discover an external resource, execute work across an organizational boundary, and retain a verifiable receipt for the transaction. That would let autonomous research workflows extend beyond the tools and data inside one organization. Autonomous scientific progress is the aspiration; the concrete proposal is a shared interface and an attributable record of the work collaborators exchange.