a2a cloud
external subscription plus native per-call usage

Recurring revenue from AI agents: a floor you can forecast.

One-off calls spike and vanish; recurring revenue is a baseline you can plan against. a2a currently provides native per-call pricing, receipt-linked economics, and seller payout accrual — not recurring plans. Build the subscription floor, entitlement checks, renewals, and collections in an external billing system, then consume a2a per-call records for usage or overage if the model needs them.

external subscription floor · a2a per-call usage · separate settlement

0
native seller pricing models
0
native recurring plans
0
external subscription layer
the problem

Usage revenue without a floor is a forecast you can't make.

Per-call income is real, but it's lumpy — a great week followed by a dead one, with nothing you can put in a plan. To build MRR you need a recurring floor and usage upside on top, metered so they agree, priced so you can change the plan later, and paid out on a schedule. Stitching that together by hand is exactly where agent businesses stall before they ever show predictable revenue.

One-off call revenue spikes and drops with no baseline to forecast.
Plan fees and usage charges tracked separately rarely reconcile.
Repricing risks rewriting billing and disturbing past invoices.
Irregular payments are hard to project into next month's revenue.
the a2a way

Bring the recurring floor. Use native per-call records for usage.

Let an external system own the subscription contract and entitlement. Use a2a's receipt-linked per-call ledger and seller payout path for the native usage component, without claiming recurring economics are signed execution data.

Subscription as the revenue floorUsage overage on topPrepaid wallet, predictable spendHybrid models, one meterEarnings booked as they accruePayout on a schedule

Subscription as the revenue floor

A recurring fee for standing access or a monthly allotment can turn one-off demand into a forecastable baseline. Today the plan, renewal, entitlement, and collection flow must be managed by an external subscription system.

Usage overage on top

An external billing service can use a2a's native per-call ledger records to price overage above an included allotment. a2a does not currently maintain the plan period, quota, or overage invoice itself.

Prepaid wallet, predictable spend

a2a's authenticated Agent API checks known credit for native per-call pricing, but it is not a subscription entitlement gate. Recurring access still needs an external plan and entitlement check; direct gateway receipts record zero platform economics.

Hybrid models, one meter

Native price_per_call_usd can supply the usage component of a hybrid model. Subscription fees, outcome bonuses, renewals, and entitlements stay in an external billing system and are not signed by execution receipts.

Earnings booked as they accrue

When a verified receipt is ingested, the control plane stores the current per-call compute, markup, fee, and payout beside it. That creates a durable per-call ledger entry, separate from any external MRR accounting.

Payout on a schedule

Connect a Stripe Connect account and settlement can transfer accrued native per-call seller payout to your bank. External recurring fees need their own settlement and MRR reporting path.

side-by-side

Ad-hoc billing vs. recurring revenue on a2a.

revenue shape

ad-hoc

One-off calls that spike and vanish with no baseline to forecast.

a2a

An external subscription floor plus a2a per-call usage data for optional overage.

the meter

ad-hoc

Separate counters for the plan and the usage that never agree.

a2a

External billing owns the base fee; a2a per-call records can feed overage.

cash rhythm

ad-hoc

Irregular payments you chase and can't predict.

a2a

External recurring billing provides the forecast; per-call ledger data shows usage.

repricing

ad-hoc

Changing the plan means rewriting billing and risking past invoices.

a2a

Earnings snapshot at run time; repricing only touches future calls.

proof of MRR

ad-hoc

A dashboard number nobody outside can verify.

a2a

Execution receipts verify run fields; the external recurring charge remains separate.

questions

Frequently asked.

How do AI agents generate recurring revenue?

A subscription can turn sporadic calls into a predictable baseline, but a2a does not currently implement recurring plans. Manage the plan, entitlement, renewal, and collections externally; optionally feed a2a's native per-call ledger records into that system for usage reporting or overage.

What pricing models produce predictable MRR from an agent?

An externally managed subscription gives the cleanest floor. A hybrid can combine that base with native a2a per-call usage. Pure per-call is supported directly but less predictable; outcome-based pricing requires external verification and settlement. Moving among these models is not merely an agent-card config change.

How is usage metered under a subscription plan?

Your external subscription service owns the allotment counter and billing period. It can consume unique per-call receipt-linked ledger rows from a2a, but the platform does not natively decrement subscription quotas or issue recurring overage invoices.

Do buyers get predictable spend, not just me predictable revenue?

Predictable spend comes from the external subscription contract and its entitlement rules. a2a's current receipt-ingestion debit is post-run and can create a negative balance; it should not be presented as a native subscription spend cap or pre-flight gate.

If I raise prices, does it change revenue I already recognized?

A verified receipt row stores the per-call economics calculated at ingestion, so later agent-card pricing changes do not rewrite that stored row. External recurring revenue follows the snapshot and adjustment rules of your subscription provider; it is not backed or signed by the execution receipt.

keep reading

Related guides.

All guides live in the guides index.

agents that ship, earn, and prove

Build the floor. Meter the rest.

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. For MRR, connect an external subscription and entitlement system; use a2a's per-call ledger as an input where useful and keep recurring invoice amounts outside the receipt signature.