---
title: "Agents Need Receipts, Not More Tools"
description: "AI agent receipts are signed, verifiable proof that a step of work happened. Why adding tools stops paying off, and what agents need to collaborate across org boundaries."
author: "MDflow"
date: 2026-08-16
reading_time: "15 min"
canonical_url: https://mdflow.cz/blog/agents-need-receipts-not-more-tools
md_url: https://mdflow.cz/blog/agents-need-receipts-not-more-tools.md
---

# Agents Need Receipts, Not More Tools

*Published August 16, 2026 · 15 min read*


The default answer to an unreliable agent, for about two years now, has been to give it another tool. Another MCP server, another API wrapper, another integration. It is a satisfying move because it is easy to make and it demos well.

At AI Engineer in July 2026, Armanas Povilionis of [Alithea Bio](https://froglet.dev/) argued that this instinct runs out much earlier than people think — and that what agents actually lack, once they have to work with anyone outside their own process, is not capability but **proof**.

> **TL;DR** — Tools make an agent better at working alone. They do nothing for work that crosses an organisational boundary, because the blocker there is trust, not capability. What unlocks that is a chain of **verifiable receipts**: signed, tamper-evident records of what was requested, agreed, executed, and paid for. Protocols like [Froglet](https://froglet.dev/) and [AP2](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) are building the cryptographic half. The other half is prose — the terms, the service descriptions, the decisions a receipt refers back to — and prose needs a durable home that both people and agents can read, which is what a markdown workspace like [MDflow](https://mdflow.cz) is for.

## What is a verifiable receipt for an AI agent?

**A verifiable receipt is a signed, tamper-evident record that a specific piece of work was requested, executed, and settled.** It states who asked, what was agreed, what came back, and what it cost — and it is signed by the counterparty rather than written by the party that benefits from it.

That last distinction is the whole point. A log line is an assertion by one participant about its own behaviour, stored somewhere that participant controls. A receipt is a mutual artefact. In Froglet's design, receipts are the last link in a chain of signed documents:

```text
descriptor → offer → quote → deal → invoice → receipt
```

Each node in the network generates a key pair on creation and uses it to sign every artefact it produces. Because each step is chained to the one before, you cannot quietly rewrite an earlier link — the chain breaks. The requester keeps a proof that the work was ordered on those terms; the provider keeps a proof that it delivered.

Froglet itself is an open, Apache-2.0 protocol ([github.com/armanas/froglet](https://github.com/armanas/froglet)). Its network is made of homogeneous nodes: every actor runs the same core software and simply plays a different role. **Providers** publish descriptors of what they offer. **Requesters** consume an index and then talk to providers directly — no middleman in the execution path. A **marketplace** is just a node running the indexing service, used for discovery and nothing else.

## Why more tools stops paying off

**Because tools scale an agent's reach inside its own boundary, and most of the hard problems are outside it.**

Povilionis used a kitchen analogy that is worth keeping. Giving an agent more tools is like giving a cook better knives, more pans, more ovens. It genuinely improves throughput — but only for the work happening in that one kitchen. Real scientific work, his domain, is closer to running a Michelin-star restaurant: the outcome depends on suppliers, on the produce they ship, on service, and on the ability to deliver the same dish consistently. **You cannot bring everything into one kitchen.** The bottleneck is the supply chain, not the cutlery.

There is also a blunt technical ceiling, independent of the philosophy. Tool definitions occupy the same context window the agent has to reason in:

- The [RAG-MCP paper](https://arxiv.org/abs/2505.03275) built an MCP stress test in the style of needle-in-a-haystack — one correct tool among *N* distractors — and measured **13.62%** tool-selection accuracy for a model handed the full pool. Retrieving a shortlist first raised it to **43.13%** while cutting prompt tokens by more than half.
- Anthropic's [code execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp) guidance describes agent workflows where loading tool definitions and routing intermediate results through the model consumed on the order of **150,000 tokens**, versus roughly **2,000** when tools stay on disk and the model writes code against them instead.

So the tool-count strategy degrades in two directions at once. It gets worse per tool added, and it never addresses work that has to leave the building.

## Why receipts matter

### For developers

**Because "did that actually happen?" is a question your logs cannot answer to anyone but you.** Inside one company, that is usually fine — you trust your own telemetry. The moment an agent orders work from a system you do not operate, self-reported logs are worth roughly what a vendor's own uptime dashboard is worth during an outage.

Receipts change the failure mode from *dispute* to *verification*. If a provider claims work was executed and the requester claims it was not, a signed chain settles it without a support ticket, and without either side having to trust the other's storage. That is the same reason double-entry bookkeeping outlived every clever ledger format that came before it.

There is a second, quieter benefit. A receipt is a natural unit of **budget**. Povilionis's framing was that the next step past giving agents token budgets is giving them real ones — letting an agent discover services, request data, negotiate execution, and pay for work across organisational boundaries. At that point the agent stops being a cook with a better knife and starts behaving like an executive chef: finding suppliers, ordering ingredients, coordinating the kitchen, and keeping a record of all of it. You cannot delegate spending to something that produces no receipts.

### For AI agents

**Because an agent cannot verify a claim it has no artefact for.** This matters more than it sounds. Multi-agent systems fail in a characteristic way: agent A reports success, agent B builds on that report, and the error only surfaces three steps later when something downstream is inconsistent. Every post-mortem of a [multi-agent pipeline that got killed](/blog/why-multi-agent-pipelines-fail) contains some version of this.

A receipt gives a downstream agent something checkable rather than something asserted. It also gives it something *durable*: the receipt outlives the context window in which the work was ordered, which is the difference between a system that can resume and one that has to redo.

And there is a cost argument. Povilionis claimed that setting up close scientific collaboration between organisations today typically becomes a bespoke enterprise project — years of work and millions of dollars before the first reusable workflow exists. Froglet's stated goal is to reduce that to: a provider exposes a resource it has already deemed shareable, an agent discovers it, reads the terms, requests the work, and receives a receipt — **a few thousand tokens and a few minutes**. That is his number, not a measured benchmark, but the shape of the claim is the interesting part: the expensive thing was never the integration code. It was establishing trust.

## Payment is where receipts get teeth

**A receipt with money attached is a receipt someone has an incentive to keep honest.** Froglet splits any paid transaction into two parts: a **base payment**, which protects providers from being drowned in speculative requests, and a **success fee**, which protects requesters from providers that take the job and do not deliver. The published protocol docs go further with a stake mechanism — providers post collateral, and dishonest execution slashes it — so that honest work pays and cheating costs.

This is not a lone effort. The broader agentic-commerce stack has been converging on the same primitive since 2025:

| Protocol | Origin | The signed artefact |
| --- | --- | --- |
| [AP2](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) | Google Cloud + Coinbase, Sept 2025, 60+ partners | Three **Mandates** — Intent (what the user wanted), Cart (what the agent assembled), Payment (what will be charged) |
| x402 | Coinbase, folded into AP2 | Deterministic stablecoin settlement, including micro-payments below a cent for API calls and inference |
| Froglet | Alithea Bio, 2026, Apache-2.0 | The full `descriptor → … → receipt` chain, with base payment + success fee |

The common denominator across all three is not the payment rail. It is the insistence that **every step produces a signed artefact a third party can check later**. AP2's Intent Mandate exists so that "the user asked for this" is provable after the fact, not reconstructed from a chat transcript.

Notably, Froglet is explicit that it does not require everyone to run the same stack — it integrates with different payment rails, harnesses, execution environments and transports. It requires only a shared interface. That is the right instinct, and the same one that made [MCP and A2A](/blog/mcp-and-a2a-agentic-interfaces) spread.

## Which applications benefit most

1. **Cross-organisational research and data sharing** — the original case. Labs, biobanks, and analytics providers holding data and specialised algorithms in silos, where the barrier to collaboration is legal and procedural rather than technical.
2. **Agent-to-agent commerce**, where one agent buys inference, data, or compute from another and someone eventually has to reconcile an invoice.
3. **Regulated workflows with audit obligations** — finance, healthcare, clinical trials — where you must show not just the result but the chain of authorisation that produced it.
4. **Long-running autonomous agents** whose work spans many sessions, where "what did this thing already do?" cannot be answered from a context window.
5. **Multi-agent pipelines with handoffs**, where the receiving agent needs to verify a claim rather than inherit it.
6. **Any team giving an agent spending authority**, however small. A budget without receipts is not a budget, it is a leak.

## How MDflow fits

**MDflow does not issue cryptographic receipts.** It is not a signing authority, a settlement rail, or a trust protocol, and it will not be. That layer belongs to Froglet, AP2, x402, or whatever wins — and none of them are things a markdown workspace should try to be.

What MDflow addresses is the half of the problem those protocols deliberately leave out. A receipt is a pointer. It says *this work, on these terms, at this price*. But the terms, the service description, the runbook the provider was supposed to follow, the decision about why this provider was chosen, the note explaining what the result means — all of that is **prose**, and a cryptographic chain is not a place to put prose. In most organisations it ends up in a PDF attachment, a Slack thread, and someone's memory of a call in March. Then the receipt survives and the meaning of it does not.

### What already lines up today

**The written record is markdown, so both audiences read it natively.** Service descriptions, data-sharing agreements, provider evaluations, and the runbook a job was supposed to follow are documents. MDflow stores them as plain markdown with no proprietary layer, and every document has a [raw `.md` twin](/markdown-ai) an agent can fetch directly, complete with YAML frontmatter.

**The Document Log names the actor on every change.** A cross-document activity feed at `/log` records created, edited, shared and deleted events, and anything arriving through the HTTP API or MCP is attributed as `automated · <token name>` rather than blurring into "you". Click an edited row for a side-panel diff of exactly what that change did. It is not a signed receipt, but it is the honest answer to "which agent touched this, and when" — and it is the layer most teams are missing entirely.

**Version history answers what changed, and lets you undo it.** Every saved change captures the previous version across every write path — editor, API, and MCP — with line-by-line diffs and non-destructive restore. If an agent rewrote a data-sharing agreement, the diff is the evidence. (Version history is a Pro feature, private to the document owner, and deliberately **not** exposed over the API or MCP — an agent can write, but it cannot rewrite the record of what it wrote.)

**Scoped tokens keep the actor identifiable.** Agents connect over the [remote MCP server](/docs/mcp) with OAuth or a named Personal Access Token, and over the [HTTP API](/docs/api) for scripts, cron jobs, CI and n8n. Naming a token per agent is what makes the log rows meaningful — and it is the same discipline behind [scoped authorization for agents](/blog/agent-authorization-scoped-tokens).

**Folder descriptions make the right agreement retrievable.** Every folder carries a description of what belongs inside it, and [`mdflow_get_context`](/docs/mcp) ranks those descriptions **above** folder names and document titles before returning matching bodies. A folder described as *"Executed data-sharing agreements and provider terms — authoritative; check before ordering external work"* is a retrieval signal you wrote deliberately, not one a model guessed. That is [why folder descriptions beat file names](/blog/folder-descriptions-agent-context).

**Sharing crosses the org boundary without an account.** A receipt chain is inter-organisational; so is the paperwork around it. Public read-only links, [collections](/use-cases/sharing) that bundle a set of documents into one link, and per-person email-scoped access mean a counterparty can read the terms without being onboarded into your workspace.

**Comments anchor a dispute to the clause it concerns.** Readers of a shared document can attach a comment to a selected passage of the markdown source, highlighted inline, with the owner moderating from the normal editor. When the argument is about what clause 4 actually required, that is where the argument should live.

**Encryption for what should not be readable server-side.** Terms sheets and pricing are often confidential; documents can be [client-side encrypted](/blog/client-side-encryption-for-online-notes), which also means they are never scanned or indexed server-side.

### Where we are headed

Direction, not a dated commitment. The thing we find most interesting in this space is **making a document referenceable at a specific version** — so a receipt, a log line, or an agent's own note can point at *the terms as they stood on 12 August*, not at whatever the document says today. Alongside that, richer structured retrieval over folder descriptions, so an agent about to order external work can reliably find the agreement that governs it. We have no plans to become a settlement layer.

## The bottom line

The instinct to fix an unreliable agent by handing it another tool has a hard ceiling, and the ceiling arrives earlier than the roadmap assumes. Tools improve local work. They do nothing about the question that blocks every interesting cross-boundary workflow: *how do I know that actually happened?*

The answer the agentic-commerce protocols are converging on is receipts — signed, chained, checkable by a third party, and increasingly tied to real money. That is the right primitive, and it is being built by people who should be building it.

But a receipt only points at meaning; it does not contain it. Keep the agreements, the service descriptions, the runbooks and the decisions in plain markdown, with version history and an activity log that names which agent did what. Then when the chain says the work happened, you can still answer the second question: what was it supposed to be.

[Start free](/login) · [Connect an AI agent](/docs/mcp) · [Read the API docs](/docs/api)

## Frequently asked questions

### What is a verifiable receipt for an AI agent?

A verifiable receipt is a signed, tamper-evident record that a specific piece of work was requested, executed, and settled — who asked, what was agreed, what was returned, and what it cost. It is different from a log line, because a log is written by one party and can be edited by that party. A receipt is signed by the counterparty and chained to the artefacts before it, so altering any step breaks the chain.

### Why does adding more tools stop making an agent better?

Because tool definitions compete for the same context window the agent reasons in, and because tools only extend what the agent can do alone. The RAG-MCP paper measured tool-selection accuracy of 13.62% when a model had to pick the right tool from a large pool, rising to 43.13% once retrieval narrowed the candidates first. Anthropic's code-execution-with-MCP guidance describes workflows where loading definitions and passing intermediate results through the model consumed around 150,000 tokens, reduced to roughly 2,000 by keeping tools out of the context. More tools is a local optimisation; it does nothing for work that crosses an organisational boundary.

### What is the Froglet protocol?

Froglet is an open, Apache-2.0 protocol from Alithea Bio that lets agents discover external services, agree terms, execute work across organisational boundaries, and receive a verifiable receipt. Every node runs the same core software and plays a different role — requester, provider, or marketplace. Each node holds a key pair used for identity and signing, and each transaction produces a signed chain: descriptor, offer, quote, deal, invoice, receipt. It was presented by Armanas Povilionis at AI Engineer in July 2026.

### How is a receipt different from provenance?

Provenance answers where a fact came from. A receipt answers whether a piece of work actually happened, on what terms, and who is accountable for it. Provenance is about the lineage of information; receipts are about the accountability of execution. A mature agent system needs both, and they are usually produced by different layers.

### Does MDflow issue signed receipts for agent work?

No. MDflow is not a signing authority, a settlement rail, or a trust protocol, and it does not mint cryptographic receipts. What it holds is the human-readable half of the record: the agreements, service descriptions, runbooks, and decision notes that a receipt refers back to, plus a Document Log that names the actor on every change as `automated · <token name>`, and version history with line-by-line diffs. Agents read and write those documents over MCP or the HTTP API, so the written record survives the session that produced it.

## Further reading

- [Agents Need Receipts, Not More Tool Calls](https://www.youtube.com/watch?v=Q9ycQHbDdJs) — Armanas Povilionis, Alithea Bio, AI Engineer, July 2026 (the source talk)
- [froglet.dev](https://froglet.dev/) and [github.com/armanas/froglet](https://github.com/armanas/froglet) — the protocol and its Apache-2.0 implementation
- [Announcing the Agent Payments Protocol (AP2)](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) — Google Cloud, on Intent, Cart and Payment Mandates
- [RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection](https://arxiv.org/abs/2505.03275) — the 13.62% → 43.13% tool-selection figures
- [Code execution with MCP: building more efficient agents](https://www.anthropic.com/engineering/code-execution-with-mcp) — Anthropic, on keeping tool definitions out of the context window
- [Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions](https://arxiv.org/abs/2606.04193) — a research take on attested receipts for agent actions
- [Provenance for AI agent memory](/blog/provenance-for-ai-agent-memory) — the other half: where a *fact* came from
- [Why multi-agent pipelines fail](/blog/why-multi-agent-pipelines-fail) — what unverified handoffs cost in practice
- [Scoped tokens for AI agent authorization](/blog/agent-authorization-scoped-tokens) — making the actor in a log row mean something
- [MDflow MCP documentation](/docs/mcp) and [HTTP API documentation](/docs/api)