question
traces & logs
Observability answers 'what happened?'
a2a receipts
Receipts also answer 'can you prove it happened that way?'
observability meets accountability
AI agent observability that can prove it.
Observability tells you what your agent did. Accountability asks whether a specific execution artifact can be verified independently. a2a cloud signs caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. Rich activity telemetry and Agent API paid-call economics remain separate.
signed execution fields · separate economics · ordered event history
0
signed execution entry points
0
mutable dashboards
cost granularity (per call)
the problem
Observability tells you what happened. It can't prove it.
Traces, metrics, and logs are built to help you debug — and they're excellent at it. But they're mutable, operator-controlled, and aggregate. When an agent takes a consequential action and someone later asks whether it really ran that way, under whose authority, and at what cost, a dashboard is the record kept by the party being asked. It answers 'what happened' and goes quiet on 'prove it' — the exact question accountability turns on.
Traces and logs are mutable — they can be edited after an incident.
Cost is aggregated per service or model, not attributed to the caller and grant.
The authority behind an action lives in a separate access log, if anywhere.
Root cause means reconstructing a past run by hand instead of re-running it.
the a2a way
Receipts: telemetry that doubles as evidence.
A receipt signs caller, skill, input evidence, verified grant IDs, outcome/result preview, and overall timing. A separately signed replay session can preserve ordered events; traces, artifacts, evaluations, and Agent API paid-call economics remain distinct records.
Telemetry that is also evidencePer-run timing and attributionCaller and authority in the traceTamper-evident by constructionInspect the ordered event historyOne record, two audiences
Telemetry that is also evidence
A receipt records caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. Ed25519 signs those populated fields. Tool, file, artifact, handoff, and evaluation fields require separate instrumentation.
Per-run timing and attribution
The default receipt records overall execution timing plus caller and verified grant IDs. Tool-level hashes, status, and elapsed time are optional schema fields not populated by the current sealers. Agent API paid-call economics remain separate.
Caller and authority in the trace
Standard observability tells you a span ran. A receipt records who called and which grant IDs were used; the referenced grants provide audience, TTL, and scope for the authority review.
Tamper-evident by construction
Dashboards read from logs an operator can edit. Each receipt is individually Ed25519-signed, so altering any signed execution field breaks verification. Completeness still depends on retention and inventory controls.
Inspect the ordered event history
A signed replay session preserves ordered events for timeline scrubbing and root-cause inspection. Automatic agent re-execution is not shipped; deterministic reruns require replay doubles and seeded randomness.
One record, two audiences
Engineers and compliance teams get an individually signed execution artifact with identity, skill, input, authority, outcome, and timing evidence. Rich traces, artifacts, evaluations, and protocol history remain separate records.
side-by-side
Traditional telemetry vs. signed receipts.
integrity
traces & logs
Traces and logs are mutable — editable after an incident.
a2a receipts
Ed25519-signed run records — altering a signed field is detectable.
cost
traces & logs
Cost aggregated per service or per model endpoint.
a2a receipts
Overall execution timing in the receipt; Agent API paid-call economics in a separate ledger.
authority
traces & logs
Who authorized the action lives in a separate access log, if at all.
a2a receipts
Caller and grant IDs are signed; the referenced grant supplies audience, TTL, and scope.
root cause
traces & logs
Reconstruct a past run by hand from spans and state.
a2a receipts
Scrub the signed ordered event history; rerun only with replay doubles and seeded randomness.
dimension
traces & logs
a2a receipts
question
Observability answers 'what happened?'
Receipts also answer 'can you prove it happened that way?'
integrity
Traces and logs are mutable — editable after an incident.
Ed25519-signed run records — altering a signed field is detectable.
cost
Cost aggregated per service or per model endpoint.
Overall execution timing in the receipt; Agent API paid-call economics in a separate ledger.
authority
Who authorized the action lives in a separate access log, if at all.
Caller and grant IDs are signed; the referenced grant supplies audience, TTL, and scope.
root cause
Reconstruct a past run by hand from spans and state.
Scrub the signed ordered event history; rerun only with replay doubles and seeded randomness.
questions
Frequently asked.
What's the difference between AI agent observability and accountability?
Observability uses traces, metrics, and logs to debug behavior. Accountability adds independently verifiable evidence. Current receipts sign caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. Rich activity fields require separate instrumentation, and economics are not part of the signature.
Can signed receipts replace my observability stack?
They complement it. Receipts provide signed identity, skill, input, authority, outcome, and timing evidence. Use APM, traces, protocol history, artifact stores, and evaluation records for richer operational detail; optional receipt schema fields are not populated by default.
How does per-run cost attribution work?
Each receipt captures overall execution timing plus caller and verified grant IDs. For authenticated Agent API paid calls, the control plane separately stores compute, markup, fee, and payout. Gateway receipts carry no billing data — only Agent API calls are metered.
Why aren't traces and logs enough for AI agents?
Traces and logs are mutable and operator-controlled, so they answer 'what happened' but not 'can you verify this artifact.' Receipts add Ed25519 signing plus caller and grant references to the execution record. That detects alteration of signed fields; it does not by itself prove that the overall collection is complete.
Does receipt-based observability support replay?
The replay subsystem signs an ordered event log that a UI can scrub for root-cause analysis. The receipt alone does not re-execute an agent, and automatic re-execution is not shipped. A deterministic rerun is possible only when the runtime substitutes replay doubles for external LLM and tool effects and the agent uses the injected random seed.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Graph it. Then prove it.
a2a cloud deploys any agent with managed Postgres, MCP and API surfaces, and a frontend. Agent API, public `/invoke`, and standard MCP `tools/call` executions receive receipts. Only authenticated Agent API paid calls have linked economics; gateway receipts record zero platform economics.