How AI agents share one refund limit, and why a new session does not reset it

Use a shared limit on the operation's impact, reserved before the external call. A per-agent token budget cannot cap refunds. A per-call approval threshold cannot cap the sum of many approved refunds. Agents acting in the same scope need to draw from the same allowance.

Anlyon's impact limits implement this for governed actions: those with an adapter or a declaration. A limit can count money or any unit you declare, such as emails. This guide walks through the mechanism with a Stripe test key and with a declared unit.

Three budgets that should not be confused

Control	What it counts	What it covers
Model-provider spend limit	Model usage under the provider's contract	Spend on model calls
Anlyon per-key budget	Metered Anlyon operations	The Anlyon operations one API key performs in a month
Anlyon impact limit	Money, resource mutations or a declared unit from governed actions in one environment and configured scope	What every agent, session and key in that environment changes through governed actions

Configure a shared refund allowance

After creating a governed refund action, here with a Stripe test key, an operator with impact-limits:write can create a daily limit. Do not grant that permission to the agent being constrained.

// operator is a Client configured with an operator key in the test environment.
await operator.impactLimits.create({
  name: 'Daily test refunds',
  dimension: 'money',
  currency: 'usd',
  period: 'day',
  amount: 50_000, // $500.00 in minor units
});

Without action or resource filters, applicable governed actions in that environment share the limit. A new key, child agent or session draws from the same capacity. A limit counts one currency, so create one limit per currency. A day period is the UTC day.

Count a unit you declare

A limit does not have to be money. An action on any HTTPS API can declare how much one call changes, in a unit you name. Every agent, session and key in the environment then draws from the same limit.

// ops holds an operator key. anlyon holds the agent key.
await ops.actions.declare('send-email', {
  // Counted before dispatch. `emails` is a unit this workspace declares.
  impact: { dimension: 'emails', amount: 'count(input.to)', bound: 'exact' },
  // A GET on the action's own host, issued after the write.
  verify: {
    url: 'https://api.example.com/v1/emails/{{response.id}}',
    status: 200,
    match: [{ path: 'status', equals: 'sent' }],
  },
});

// One cap shared by every agent, session and key.
await ops.impactLimits.create({ name: 'Daily emails', dimension: 'emails', period: 'day', amount: 500 });

const { data } = await anlyon.actions.invoke('send-email', { to: ['a@example.com'] });
console.log(data!.grade); // 'confirmed' when the read-back matched

impact.dimension is money, resource_mutations or a unit of lowercase letters, digits and underscores. impact.amount is an integer, input.<path> or count(input.<path>), with one optional * <integer>. impact.bound is exact or upper_bound. Either impact or verify makes the action governed, and so does governed: true.

How a declared limit behaves:

• The amount is the expression you wrote. For an API you declare, you write what the action counts, and Anlyon enforces it before dispatch. Set an upper_bound at the most one call can change.
• An amount needs its input. An amount that reads an input the caller left out is refused under an applicable limit.
• The host is fixed. A governed action calls an https URL whose host comes from the definition.

The resend.email_send adapter counts emails for you, one per recipient across to, cc and bcc.

Why reserve before dispatch?

Suppose $40 remains and two agents concurrently ask for $30 refunds. Checking the balance and decrementing later lets both pass. Anlyon reserves applicable impact limits together in a transaction before dispatch. If a required limit cannot cover the request, nothing is sent and the receipt grades refused.

The quantity comes from the adapter or the declared amount, applied to the normalized request. It is not a cost estimate supplied by the model. Availability is checked again at dispatch, after approval.

A lost response must not restore the allowance

A lost response is graded unknown. Anlyon does not send the request again. The outcome stays unknown until a read-back finds the operation, a replay inside the provider's idempotency window returns the original response, or an operator settles it.

Confirmed impact settles once. Capacity is released for impact known not to have happened, and for nothing else. Pending or unknown outcomes, including possibly partial failures, retain exposure until evidence or operator resolution settles them.

available = limit - consumed - reserved. unknownExposure is included in reserved, so do not subtract it twice. Reservations settle into their original period even when the result arrives after the period boundary.

Read the full impact-limit contract and recovery rules. Repeated submission with one operation key returns the existing operation. Different keys can represent separate refunds, so operation identity alone is not a shared spending limit. The execution guide lists every receipt grade.

Try it in a test environment

In a test environment, try concurrent operations near the cap, a new agent key in the same environment, an unknown provider result, and an approval that completes after capacity is consumed. Check the effect evidence and the allowance as well as the response shown to the model.

Start with test payments · Current terms · Execution architecture