Hi everyone,
I want to propose a discussion around execution receipts for AI agents.
A lot of current agent work focuses on identity, reputation, permissions, payment, and tool execution. Those are important, but I think there is another layer that production agent systems will need:
«a verifiable record of what the agent actually did.»
For coding agents and tool-using agents, the question is not only:
«Can this agent perform the task?»
It is also:
«Can a user, another agent, or a verifier later check what happened?»
Problem
AI agents can now:
- modify files
- run commands
- call tools
- generate patches
- prepare deployments
- interact with APIs
- potentially trigger higher-impact actions
But after the session ends, the user often has to trust the agent output or inspect logs manually.
For production use, especially when agents act across codebases, wallets, infrastructure, or paid tools, we need a receipt layer.
Receipt model
A session receipt can capture structured evidence such as:
- task / prompt
- workspace or project context
- agent/runtime metadata
- scope or permissions
- changed files
- diff hash
- command/tool summary
- verifier inputs
- full evidence JSON
The full evidence should stay off-chain by default.
From that evidence, we can compute a deterministic receipt hash/root.
full agent evidence off-chain
→ canonical receipt JSON
→ deterministic receipt hash/root
→ compact on-chain anchor
→ later verification by recomputing the root
The goal is not to put private prompts, code, logs, or full workflows on-chain.
The goal is:
private evidence off-chain
public commitment on-chain
verification by recomputation
Session / workflow roots
For larger agent sessions, a single action receipt is not enough.
A session may contain many actions:
receipt_1_hash
receipt_2_hash
receipt_3_hash
…
Those can be batched into a Merkle tree:
many receipt/evidence items
→ receipt hashes as leaves
→ Merkle tree
→ sessionRoot / workflowRoot
→ on-chain anchor
This gives one compact root that commits to a larger workflow.
A verifier can later:
1. load the receipt JSON
2. canonicalize it
3. compute “receiptHash”
4. verify the Merkle proof against “sessionRoot” / “workflowRoot”
5. compare that root with the on-chain anchored value
Relationship to agent identity / reputation
I see this as complementary to agent identity, reputation, and validation registries.
Identity/reputation can answer:
«Who is this agent, and how has it behaved historically?»
Execution receipts answer:
«What did this agent do in this specific session?»
Both seem useful.
An agent can have a good reputation, but users may still need a verifiable receipt for a particular code change, tool call, deployment step, or paid action.
Prototype
We have been prototyping this pattern in Stealth/CYPHES:
Current prototype direction:
- local receipt evidence
- deterministic receipt root computation
- Sepolia receipt-root anchor demo
- local Merkle proof demo for batching multiple receipt/evidence items into one session/workflow root
- full evidence stays off-chain
- only the root/hash is anchored on-chain
The important boundary:
«the full workflow is not on-chain.
the root/hash is on-chain.
verification happens by recomputing the root.»
Questions for the community
I would be interested in feedback on:
1. Should execution receipt roots be treated as a type of agent validation evidence?
2. Should session/workflow roots be modeled as a separate attestation layer that can plug into registries later?
3. What canonicalization format would make sense for agent receipts?
4. What should the minimal verifier interface look like?
5. Should receipt roots be anchored directly by agents, users, validators, or some shared registry?
6. How should private evidence bundles be referenced without leaking prompts, code, or logs?
In short:
«Not “trust the agent.”
Verify the receipt.»
Curious how others are thinking about verifiable agent execution and whether receipt roots / session roots fit into the broader Ethereum agent stack.