Fund temporary multi-call workflows without recurring billing or unlimited access.
A research agent may need search, extraction, and verification for the next 12 minutes. Charging a separate onchain payment before every call adds friction. Selling a monthly subscription creates a recurring relationship for a task that ends today. A temporary session can sit between those models.
AI agent session payments create a bounded entitlement for a workflow. A safe session names permitted services, maximum spend, usage prices, start and end conditions, idle timeout, payment backing, and close behavior. It does not renew automatically, and one opening payment does not grant unlimited access.
Use a Session Only for a Bounded Multi-Call Workflow
A session fits when one agent expects several related calls to the same merchant or coordinated service set, individual calls are low value, exact usage is uncertain, and the workflow has a natural end. Interactive research, temporary tool access, an image-editing sequence, or a short data-processing job can fit.
Per-request payment is simpler when calls are independent, infrequent, or high value. A prepaid account is practical when the agent repeatedly uses one platform and accepts stored credit. A subscription fits predictable recurring use and a continuing account relationship. A session is useful when access should be temporary and usage should remain metered.
Do not create a session merely to avoid displaying a payment requirement. The server still needs pricing, authorization, usage evidence, settlement, and failure recovery. Bundling those events changes when payment occurs; it does not remove economic control.
The merchant should state whether one session covers one agent, one task, one device or runtime, one merchant, or a named group of services. A transferable session token can become general purchasing power if scope is vague.
Compare Four Payment Models Before Building One
Model | Best fit | Buyer exposure | Seller exposure | End condition |
|---|---|---|---|---|
Per-request payment | Independent calls | One call | One call | Request completes |
Session payment | Temporary multi-call workflow | Session cap or prefunding | Bounded usage, depending on backing | Close, expiry, exhaustion, or cancellation |
Prepaid credit | Repeated use on one platform | Stored balance | Low after funding | Balance exhausted or refunded |
Subscription | Predictable recurring access | Recurring charge or commitment | Usage above plan assumptions | Cancellation or plan end |
The models can coexist. A merchant may offer per-request x402 access to occasional agents, session pricing to intensive short workflows, prepaid credits to frequent platform users, and subscriptions to human-managed accounts.
The key difference is renewal. A session ends under conditions defined at opening. Extending time or budget should require a renewal event that checks policy. A subscription commonly creates recurring access and billing until cancellation or term completion.
Define the Session as an Entitlement Object
Create the session before first use and bind it to one purchase intent. Identity and scope fields include session ID, principal and agent reference, merchant, and permitted resources or actions. Economic and lifecycle fields include price schedule, maximum total charge, accepted assets and networks, backing model, terms digest, absolute expiry, idle timeout, maximum call count or units, delegation rule, and unused-capacity treatment.
Mutable state includes available budget, reserved budget, captured usage, call count, last activity, active calls, payment attempts, settlement state, and close reason. Each mutation needs a version or transaction boundary so concurrent calls cannot spend the same remaining capacity.
A session token should be short lived, audience bound, and limited to the named services. It should not contain a reusable wallet key. The service validates token, session state, resource scope, price version, and remaining capacity before admitting a call.
Define states such as proposed, opening, active, closing, reconciling, closed, expired, and disputed. Closing stops new calls and lets existing work finish under its prior authorization. Reconciling holds unused capacity until payment and delivery outcomes are terminal.
Walk a 12-Minute, $0.50 Research Session
An agent opens session s-204 for search, extraction, and verification. The absolute lifetime is 12 minutes, idle timeout is two minutes, and spend ceiling is $0.50. Search costs $0.02 per call, extraction $0.05 per document, and verification $0.04 per claim set.
The payment layer authorizes or commits up to $0.50 according to the selected model. That might be prefunding, a capped authorization, a batch commitment, or merchant-approved credit. The session ledger records the exact backing and does not call every model escrow.
The agent issues three search calls for $0.06, extracts four documents for $0.20, and verifies two claim sets for $0.08. Captured usage is $0.34. It starts another extraction call, reserving $0.05. Available session capacity becomes $0.11 until that call captures or releases its reservation.
At minute nine, the agent finishes and requests close. The session enters closing, rejects new calls, waits for the active extraction, then captures its $0.05. Final usage is $0.39. The remaining $0.11 is released, refunded, or simply left uncaptured according to the backing model.
The close receipt lists opening authorization, usage items, reservations, captured total, released amount, settlement or refund references, close reason, and delivery evidence. The agent can use it in task accounting without maintaining a monthly billing account.
Meter Calls Before Execution and After Delivery
Each call needs a usage item with session ID, item ID, resource, quantity, unit price, maximum amount, request digest, and idempotency key. Admission reserves maximum expected capacity. Completion captures actual price and releases any remainder.
For fixed-price calls, reservation and capture may use the same amount. Variable-cost model inference can reserve an upper bound and capture measured tokens. Outcome-priced work may need a delivery predicate before capture. The session pricing contract must state the meter and evidence source.
Concurrent calls require atomic accounting. The valid admission condition is not wallet balance >= call price; it is session available capacity >= call ceiling after subtracting active reservations. Use transactional updates or versioned optimistic writes.
Retries reuse the item. If a call times out after service execution, the client queries item status or requests redelivery. It does not create a second charge. Duplicate usage reports and merchant webhooks return the existing capture result.
Meter disputes need item-level evidence. A final session total without call records is hard to verify and refund. Retain the price version, measured units, service result reference, and reason for any adjustment.
Close on Idle, Expiry, Exhaustion, or Explicit Request
These triggers are not equivalent.
An explicit close reflects agent intent. Stop new calls and finish or cancel active work under terms. An idle timeout detects abandonment; it may enter a grace period because network interruption is not a deliberate close. Absolute expiry is a hard authority boundary. Budget exhaustion stops paid admission even if time remains. Cancellation may be a principal or risk action with immediate restrictions.
Client disconnect should not close the session immediately. The agent can reconnect, a tool call may still execute, or a payment callback may arrive. Use idle timeout and resumable session credentials. A merchant can shorten grace for high-risk or scarce resources.
Renewal is a new authorization decision. Extending idle timeout for an active call can preserve the same budget. Increasing the ceiling, broadening service scope, changing terms, or moving beyond absolute expiry creates new exposure and should pass policy again.
Once closing starts, admission must be monotonic: no new work. Otherwise, one worker can close and release capacity while another admits a late call against the same funds.
Reconcile Payment, Usage, Delivery, and Unused Capacity
Closing requires four ledgers to agree: what the agent authorized, what payment infrastructure committed or settled, what usage the merchant captured, and what service was delivered. A session is not terminal because the browser, client, or agent process disappeared.
For a capped authorization, capture final usage and release unused capacity. For prefunding, settle merchant usage and return or preserve unused value under disclosed rules. For credit, invoice or redeem accumulated items and close remaining credit. For direct per-call payments inside a logical session, ensure each item is terminal and the session itself moves no extra value.
Ambiguous payments hold capacity. If a settlement or refund times out, mark the session reconciling. Do not return the same budget to the parent wallet until the outcome is known. A failed refund remains an open financial item even when service access has ended.
Late delivery also matters. If an active tool finishes after expiry, the terms should state whether it can capture its prior reservation. New work cannot begin, but already authorized execution may complete during a bounded grace period.
Generate one close receipt idempotently. Repeated close requests return the same session result or current reconciling state. They must not issue multiple refunds.
FAQ
Is an AI agent session payment a subscription?
No. A session has a bounded scope, budget, and end condition and should not renew automatically. A subscription usually creates recurring access or billing over repeated periods.
Does opening a session require paying the full maximum upfront?
Not always. Backing can use prefunding, capped authorization, batch commitment, bounded credit, or per-call settlement. The contract must state custody, exposure, and unused-value treatment.
Can a session work without a user account?
Yes. A scoped wallet or agent identity, signed session token, payment intent, and merchant order can support temporary access. Some services may still require identity, compliance, support, or persistent account controls.
What happens to unused session budget?
It depends on backing. It may be released from an authorization, returned from prefunding, remain in a prepaid balance, or simply remain unbilled under credit. The rule must be disclosed before opening.
Can an agent extend a session automatically?
Only inside preauthorized renewal rules. More time, budget, service scope, or changed terms can increase exposure and should trigger the relevant policy or principal approval.
Map x402 and GOAT to the Session Lifecycle
x402 can communicate per-resource payment requirements and supports schemes that may help with exact, capped, or batched payment patterns. It does not automatically define an application’s full session object, idle timeout, multi-tool scope, usage ledger, or close semantics.
GOAT Flow’s payment-intent, order, proof, and fulfillment correlation is relevant to opening and closing evidence. AgentKit runtime policy and idempotency controls can constrain networks, actions, writes, and retries during a session. Developers must verify the current SDK, schemes, assets, and networks used by their implementation.
The merchant application owns resource pricing, session token validation, metering, concurrency control, close triggers, delivery evidence, unused-value policy, and support. GOAT can contribute payment and execution infrastructure without being represented as a complete generic session-billing product.
Require One Terminal Session Invariant
Fault-test duplicate open, two concurrent calls consuming the final capacity, client disconnect, idle timeout during execution, absolute expiry, explicit close racing a call, late payment confirmation, duplicate usage report, failed refund, and repeated close.
The session passes when no new call starts after closing, every admitted item is captured, released, cancelled, or reconciling, and every unit of budget is available, reserved, captured, refunded, or held for an ambiguous outcome exactly once. Only then can the parent workflow reuse remaining capacity.
A session improves agent commerce when it reduces repetitive payment negotiation without weakening limits. Its value comes from temporary continuity under explicit boundaries, followed by a clean, reproducible end.
