Control how much outside agents can consume
Outside agents can generate bursts of requests and sustained model usage. Wildo treats them separately: an owner-based throttle controls request bursts, while an optional tenant budget checks accumulated A2A token consumption.
The application chooses the allowance; the transport checks it before admitting another turn.
Example — Share a budget across several integrations
Two organization-owned agent clients share the organization’s token allowance and its blanket burst window. Adding another client does not give that organization another burst allowance.
For engineers
The token-budget feature already exists in Wildo. Grant an allowance on an existing organization or user plan instead of declaring the feature again. This adapted excerpt belongs in that plan’s ProductDefinition in the application’s shared product catalog; preserve its other grants and pricing fields:
import {
A2A_TOKEN_BUDGET_FEATURE_ID,
LimitGrantMode,
} from '@wildo-ai/saas-models';
// Within the existing ProductDefinition:
grantedLimits: {
[A2A_TOKEN_BUDGET_FEATURE_ID]: { value: 100_000, mode: LimitGrantMode.SET },
},
This example grants 100,000 tokens for the tenant’s UTC calendar month. The amount is an illustrative application decision, not Wildo’s default. The plan must be active for the tenant through the normal product/billing configuration. Other applicable grants, profiles and overrides participate in feature resolution, so inspect the tenant’s effective limit when verifying the result. Application scope uses a feature profile or manual override because it has no plan billing rail.
Understand when admission is checked
The service resolves the live allowance and reads accumulated consumption before a turn. After consumption is known, it records those tokens against the tenant’s UTC calendar month. This selected gate is the comparison, not a precharge:
if (consumedTokens >= allowanceTokens) {
return { kind: 'over_budget', reason: A2ATokenBudgetDenialReason.ALLOWANCE_EXHAUSTED, allowanceTokens, consumedTokens };
}
return { kind: 'ok' };
An exhausted budget refuses further turns. Already-running turns can complete and add usage beyond the threshold; this is not an exact dollar ceiling or a single-turn maximum overrun.
Distinguish the three counting rules
| Control | Who shares the counter | What it limits |
|---|---|---|
| Blanket agent throttle | Verified user, otherwise organization, otherwise application | Request attempts within each transport’s burst window |
| An operation’s declared MCP rate policy | Machine credential first; otherwise delegated user or owning scope | Calls under that operation’s authored policy |
| A2A token allowance | The resolved budget owner | Accumulated model tokens in the UTC calendar month |
The blanket throttle uses server-verified identity, not an identifier supplied in a prompt. A delegated user has a user bucket; organization-owned machine clients share the organization bucket. A separately declared operation policy can distinguish those machine credentials, while the blanket owner throttle still applies.
Keep the failure policies distinct
| Situation | Policy |
|---|---|
| No allowance configured | No token cap |
| Allowance exhausted | Refuse another turn |
| Configured allowance, unreadable consumption | Refuse because remaining capacity cannot be established |
| Allowance resolution fails | Refuse the turn because the allowance cannot be established; failure is logged |
The owner-based burst throttle allows requests through if its limiter storage fails. It complements the budget but does not reserve future tokens. Use model-call telemetry to observe actual consumption and investigate metering failures.