billing path
bolted on
A subscription engine wired separately from your usage metering.
a2a
External subscription billing consumes a2a per-call usage as an input.
subscription strategy, honest product boundary
AI agent subscription billing: external plans over native per-call usage.
A subscription can be the right model when an agent is a standing dependency. On a2a today, it is an integration pattern rather than a native seller-pricing feature. Keep the recurring plan, entitlement, allotment, overage, and collections logic in an external billing system; use a2a's per-call ledger and signed execution records as inputs without claiming the plan itself is built in or signed.
external recurring plan · external entitlement · a2a per-call usage
0×
meter per call
0
native subscription plans
0%
calls with a receipt
the problem
Subscriptions bolted onto usage rarely agree with it.
Recurring billing looks simple until it has to know how much was used. Teams stand up a subscription engine, then a separate metering pipeline, and the two disagree: the allotment tracker lags the real usage, overage needs a third system, and subscriber access is guarded by app-side checks nobody wants to own. The recurring charge ends up as a number the customer takes on faith, because the usage it's supposed to reflect lives somewhere else.
A subscription engine wired apart from metering drifts from actual usage.
Allotment tracking lags the real call count and reconciles only at period end.
Charging beyond the included quota needs a bolted-on overage system.
Subscriber access relies on app-side entitlement checks you have to maintain.
the a2a way
Bring the subscription layer; consume per-call records.
Use an external billing service for recurring terms and pre-flight entitlement. Feed it a2a's per-call ledger records where needed, and keep signed execution evidence distinct from invoice economics.
Recurring access needs an entitlement layerPredictable on both sidesUse per-call data as an inputOverage remains externalEnforce entitlements in your integrationSigned execution evidence stays separate
Recurring access needs an entitlement layer
A subscription can grant ongoing access or a usage allotment for a recurring fee. Today that plan, renewal, and entitlement logic must live in an external billing system; it is not configured on the a2a agent card.
Predictable on both sides
The buyer knows the recurring commitment and the seller gets a predictable floor. Subscription pricing fits an agent that is a standing workflow dependency, provided an external system manages renewals, access, and collections.
Use per-call data as an input
The external subscription service can consume a2a's per-call ledger data to decrement an allotment. a2a does not currently maintain plan periods or allotment balances itself.
Overage remains external
An external billing service can apply a2a per-call usage as overage after the included quota. Renewal, quota reset, overage invoicing, and dunning are not native a2a features today.
Enforce entitlements in your integration
The current receipt-ingestion debit path is post-run, not a pre-flight plan gate. A subscription integration must check entitlement before invocation if it needs to prevent out-of-plan work.
Signed execution evidence stays separate
Authenticated Agent API paid calls receive signed receipts and linked per-call economics. Public `/invoke` and standard MCP `tools/call` also receive execution receipts, but those direct gateway paths record zero platform economics because they lack buyer binding and preflight.
side-by-side
Bolted-on subscriptions vs. subscription billing on a2a.
allotments
bolted on
Track plan consumption in a spreadsheet that lags the real usage.
a2a
Your entitlement service decrements its own allotment from exported per-call records.
overage
bolted on
Bolt on a second system to charge beyond the included quota.
a2a
Your external billing service prices and settles overage from a2a usage data.
access control
bolted on
Guard subscriber access with app-side checks you maintain.
a2a
Your integration checks subscription entitlement before invoking the agent.
the invoice
bolted on
A recurring charge the subscriber has to take on trust.
a2a
An external cycle total linked to signed execution records and separate ledger rows.
dimension
bolted on
a2a
billing path
A subscription engine wired separately from your usage metering.
External subscription billing consumes a2a per-call usage as an input.
allotments
Track plan consumption in a spreadsheet that lags the real usage.
Your entitlement service decrements its own allotment from exported per-call records.
overage
Bolt on a second system to charge beyond the included quota.
Your external billing service prices and settles overage from a2a usage data.
access control
Guard subscriber access with app-side checks you maintain.
Your integration checks subscription entitlement before invoking the agent.
the invoice
A recurring charge the subscriber has to take on trust.
An external cycle total linked to signed execution records and separate ledger rows.
questions
Frequently asked.
How does subscription billing work for an AI agent?
A subscription charges a recurring fee for ongoing access or an allotment. a2a currently supports native seller price_per_call_usd, not recurring plans. To sell a subscription today, manage the plan, renewal, entitlement, quota, and collections in an external billing system and feed it a2a per-call usage where useful.
When should I pick subscription over per-call pricing?
Choose subscription when the agent is a standing dependency and both sides value a predictable commitment. Choose native per-call pricing for bursty usage and the lowest integration burden. Moving to subscription means adding an external entitlement and recurring-billing layer; it is not an agent-card pricing switch today.
How are included allotments and overage handled?
An external billing service owns the billing period, included quota, reset, and overage. It can consume a2a's per-call ledger records to decrement the allotment and calculate overage, but a2a does not currently implement those subscription mechanics natively.
Is subscriber access enforced automatically?
Not by a native subscription feature. The current receipt-ingestion debit path happens after execution and can create a negative balance. A subscription integration that requires pre-flight access control must validate the caller's external entitlement before invoking the agent.
Can a subscriber verify what a recurring charge covers?
A subscriber can verify execution receipts from the API, MCP, and /invoke entry points. Only authenticated Agent API paid calls have platform economics linked by receipt ID; direct public `/invoke` and standard MCP gateway receipts carry zero platform economics. Recurring fees and plan terms remain external.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Design recurring access without pretending it is native.
a2a cloud deploys any agent as a live service with a managed Postgres database, an MCP endpoint, an API, signed execution receipts, and native price_per_call_usd. To sell recurring access today, connect an external subscription and entitlement system, consume per-call usage as needed, and keep invoice amounts outside the receipt signature.