the count
DIY
Emit usage events from your code and hope none drop or double-fire.
a2a
A unique verified receipt ID produces one stored run row and one idempotent debit.
meter once, bill from the same number
AI agent metering and billing: signed execution, separate economics.
a2a cloud's native commercial primitive is authenticated Agent API per-call pricing. The control plane checks known buyer credit before execution, then signs and persists successful execution fields and stores compute, markup, fee, payout, and an idempotent debit beside the receipt. The separate self-reported ingestion endpoint remains post-hoc.
credit preflight · signed evidence · separate ledger · idempotent debit
0
count per call
0
native seller pricing models
0%
billable calls signed
the problem
Metering and billing as two systems is where the money leaks.
Roll your own and you build two things: a meter that emits usage events, and a billing system that turns them into charges. Then you spend forever keeping them in sync. Events drop or double-fire. Aggregation windows disagree. The invoice says one thing, the usage dashboard another, and reconciliation becomes a monthly ritual. The leak isn't in either system — it's in the seam between them.
Usage events dropped or double-fired quietly corrupt the invoice.
A meter and a billing system that drift apart force monthly reconciliation.
Rendering paid work before checking the balance means uncollectable calls.
A usage row in your database is something the customer has to take on trust.
the a2a way
Verify the run. Store per-call economics beside it.
A unique receipt ID ties an independently verifiable execution record to separate control-plane economics. Per-call is native; recurring entitlements and outcome settlement remain external integrations.
One ledger row per receipt IDProof and economics stay distinctPer-call economics are explicitAgent API and ingestion paths, separatedPer-call is the native modelMetering you don't have to build
One ledger row per receipt ID
The control plane verifies the signed execution receipt and rejects a duplicate receipt_id. A successfully ingested run therefore gets one durable receipt row and, when billable, one idempotent debit keyed to that identifier.
Proof and economics stay distinct
The Ed25519 signature covers execution fields, not money. After verifying the receipt, the control plane stores compute, markup, platform fee, seller payout, and buyer charge beside it as separate ledger fields.
Per-call economics are explicit
At receipt ingestion, the current agent card supplies price_per_call_usd and declared resources. The control plane stores gross, compute, markup, platform fee, and seller payout on the receipt row for operational reporting.
Agent API and ingestion paths, separated
Authenticated Agent API paid calls check known credit before execution and debit after success. The separate self-reported receipt path is post-hoc and can leave a negative collections balance; its debit and receipt row commit together, and duplicate receipt IDs cannot charge twice.
Per-call is the native model
The product currently supports seller price_per_call_usd. Subscription access, recurring allotments, outcome fees, and hybrid plans require an external billing and entitlement layer; the per-call ledger can be an input to that layer.
Metering you don't have to build
Usage metering is normally a project: emit events, dedupe them, and reconcile billing. For native Agent API per-call pricing, a2a checks known credit before execution, persists signed evidence after success, records separate economics, and applies an idempotent debit and payout calculation.
side-by-side
Two systems drifting vs. one metered number.
usage vs. invoice
DIY
A metering system and a billing system that quietly drift out of sync.
a2a
Signed execution fields and unsigned ledger economics are linked without conflating them.
the split
DIY
Reconcile platform cut and creator earnings in a spreadsheet after the fact.
a2a
Gross, compute, markup, fee, and payout are stored beside the verified receipt.
collecting
DIY
Treat authenticated Agent API billing and self-reported receipt ingestion as the same path.
a2a
Document Agent API credit preflight and post-hoc receipt ingestion as distinct paths.
proof of usage
DIY
A usage row in your database the customer has to take on trust.
a2a
A verifiable execution receipt linked to a separate charge ledger entry.
dimension
DIY
a2a
the count
Emit usage events from your code and hope none drop or double-fire.
A unique verified receipt ID produces one stored run row and one idempotent debit.
usage vs. invoice
A metering system and a billing system that quietly drift out of sync.
Signed execution fields and unsigned ledger economics are linked without conflating them.
the split
Reconcile platform cut and creator earnings in a spreadsheet after the fact.
Gross, compute, markup, fee, and payout are stored beside the verified receipt.
collecting
Treat authenticated Agent API billing and self-reported receipt ingestion as the same path.
Document Agent API credit preflight and post-hoc receipt ingestion as distinct paths.
proof of usage
A usage row in your database the customer has to take on trust.
A verifiable execution receipt linked to a separate charge ledger entry.
questions
Frequently asked.
How does metering work for an AI agent on a2a?
For an authenticated Agent API paid call, the control plane checks known credit before execution, signs and persists successful execution fields, stores one run row, calculates economics from the current agent card, and applies the buyer debit idempotently. Price and fee fields are adjacent ledger data, not part of the signed payload.
How is a metered call turned into a bill?
When a verified receipt is ingested, compute is derived from declared resources and the seller markup comes from price_per_call_usd. The control plane stores gross, compute, markup, platform fee, and seller payout alongside the receipt row. Those values support line-item reporting but are not Ed25519-signed receipt fields.
What stops a caller from running up a bill they can't pay?
The current self-reported paid-run path is post-hoc: the call has already happened when the receipt is ingested. A matching user debit can take the balance negative as a collections state. Debit and receipt commit together, and duplicate receipt IDs are rejected so they cannot apply the same debit twice.
Do subscription and outcome pricing use the same native billing path?
No. Native seller pricing currently supports price_per_call_usd. You can export or consume per-call ledger data inside an external subscription, entitlement, outcome-verification, or hybrid billing system, but a2a does not currently implement recurring plans, allotment burn-down, outcome charges, or hybrid settlement on the agent card.
Can the buyer trust the meter?
A buyer can verify the default signed execution fields: identity/caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. For authenticated Agent API paid calls, charge and fee fields live in a separate ledger row linked by receipt ID; direct gateway paths record zero platform economics.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent, trust the receipt
Price per call. Keep proof and money distinct.
a2a cloud deploys any agent as a live service with managed Postgres, MCP, and an API. Authenticated Agent API paid calls check known credit before execution, then persist Ed25519-signed evidence plus separate per-call economics and idempotent debits after success. Public `/invoke` and standard MCP gateway receipts remain evidence-only with zero platform economics.