What is authorization-time context?
Authorization-time context is part of the context gap vocabulary Tacnode uses in its writing on agent payments. It names the payments case of decision context: the state a decision reads, including what earlier decisions committed.
Card payments have always depended on it: an issuer reads available credit, recent activity and its rules before it answers. Agent payments add decisions. The agent platform decides whether to sign or submit, the merchant whether to accept the checkout, and the network or issuer whether to authorize. Each reads the state its own party holds.
The protocols are explicit about which part each party holds. Mastercard's Verifiable Intent specification separates constraints that can be checked from the purchase alone from network-enforced ones, such as a total budget, that "cannot be verified by a stateless verifier." In x402, a facilitator verifying an exact payment confirms that "the client has sufficient balance of the asset" (x402 scheme spec), and has no field for the team budget that wallet belongs to. Payments signed but not settled, budgets that span mandates or users, and platform policy sit with whoever runs the agents.
How authorization-time context works
It has four parts, and each goes stale in its own way:
| Part | Example | How it goes stale |
|---|
| Mandate status | Active, revoked, expired | A cancellation not yet seen by every worker |
| Remaining budget | Cap minus settled spend minus open reservations | A counter rebuilt from settlements on a schedule |
| Limits and policy | Per-agent cap, paused merchants, policy version | A change that reaches some agents later than others |
| Recent activity | Purchases by this agent in the last ten minutes | A velocity feature refreshed by a separate job |
Reading them in one transaction, and recording the decision in it, closes most of the seams:
sql
BEGIN;
-- Lock the mandate and reserve only if it is active and has room after in-flight spend.
UPDATE mandates
SET reserved = reserved + :amount
WHERE mandate_id = :mandate_id
AND status = 'active'
AND spent + reserved + :amount <= cap
RETURNING policy_version; -- zero rows: do not submit; ROLLBACK
-- Recent activity for this agent, counting purchases still in flight.
SELECT count(*) AS purchases_10m, coalesce(sum(amount), 0) AS spend_10m
FROM purchase_intents
WHERE agent_id = :agent_id
AND status IN ('reserved', 'authorized', 'settled')
AND created_at > now() - interval '10 minutes';
-- application: ROLLBACK if the velocity rule fails
INSERT INTO purchase_intents (intent_id, mandate_id, agent_id, amount, policy_version, status, created_at)
VALUES (:intent_id, :mandate_id, :agent_id, :amount, :policy_version, 'reserved', now());
COMMIT;
Under PostgreSQL's READ COMMITTED, a second reservation against the same mandate waits for the first to commit and re-checks its WHERE clause against the updated row. The velocity count has no such lock: two purchases by one agent under different mandates can both pass it unless a per-agent row is locked too. A reservation counts against the budget from the moment it commits; it becomes spend on authorization and is released on a decline or when the signed payment expires.
Why authorization-time context matters in real-time systems
Each party's check is only as good as the state behind it, and only the agent platform's check sees purchases in flight, cross-mandate budgets and its own policy. If that context lags, two failures follow. On a budget the network also tracks, the network declines the overspend after the agent has built the cart and told the user. On a budget only the platform holds, nothing declines it. Many agents spending at once widens both: a context gap with money attached.
What can be guaranteed follows where the state lives. For a network's, issuer's, chain's or merchant's ledger, Tacnode enforces nothing; it gives the authorization decision accurate context, with results such as authorizations and settlements arriving by change data capture. For mandates, reservations, per-agent limits and decision records held in the Tacnode Context Lake™, writes are transactional, so two agents reserving against one cap cannot both commit past it, and derived context such as spend per agent in the last ten minutes is computed on demand against the latest committed data. The steps where a shopping agent depends on current state are walked through in how shopping agents buy.
