Axiom

Returns the card on file for the authenticated user. Only the brand and last 4 digits are returned. Use this before make_purchase so the user can confirm which card will be charged.

Polls a browser purchase started by make_purchase and blocks until the next parked or terminal status change, then returns it. Axiom waits up to 30 seconds for the next parked or terminal status change. If the purchase is still running, call get_purchase_status again with the same browserPurchaseSessionID. Returns the final receipt once the purchase completes, an approvalLink if the user must approve a spending-rule check, or a keep-polling response when the fixed 30-second wait elapses while work is still in progress. Do not tell the user that the purchase succeeded unless this tool returns status="completed" and safeToTellUserComplete=true. Intermediate transaction states, payment authorization, card issuance, audit trail entries, and progress labels are not completion signals. Call this in a loop while status="running". If status="awaiting_approval", stop polling, send the approvalLink to the user, and call get_purchase_status again only after the user says they approved. If status="awaiting_user_input", ask the userInputRequest question and resume with submit_purchase_clarification.

Returns the details of a transaction including status, merchant, amount, approval state, receipt, audit trail, and browser purchase finality. Do not treat transaction status, audit trail, payment authorization, or card issuance as purchase success unless safeToTellUserComplete is true.

Lists the authenticated user's recent transactions, most recent first. For browser purchases, safeToTellUserComplete is only true when the related browser purchase completed with a final receipt; raw transaction states like CARD_ISSUED or AUTHORIZED are not completion signals.

Validates the agent's intent against Axiom's mandate classifier and starts an end-to-end agentic checkout in one call, completing the purchase through the merchant's own external checkout. Field semantics — read carefully, sufficient calls depend on this: - `userCommand` is the user's original words (audit-grade). Quote near-verbatim. The classifier uses it to detect intent mismatches against your resolved fields, so don't paraphrase it into something the user didn't say. - `merchant.merchantName`, `merchant.merchantURL`, and `itemName` are the AGENT'S RESOLVED specifics. The user often won't supply these literally — they may say "my dog food" or "the new iPhone". Your job is to resolve those into a concrete product + merchant when you have the context to do so faithfully (prior conversation turns, user profile, persistent memory). - `intentContext` is optional context for terse or elliptical commands. Use it when the literal userCommand is something like "same one", "try again", "buy that", or "can you get that one?", and your conversation context clearly points to one concrete purchase. Provide an audit-safe summary and concrete evidence; do not include hidden chain-of-thought. - `itemSubtotal` is an optional spend cap the user has explicitly approved; omit when the user did not state a budget. Resolution rules (this is what determines whether Axiom can start the purchase): 1. Pass the most SPECIFIC resolved item + merchant you can defend. "Acana Adult Recipe 25lb" beats "dog food". A merchant URL pointing at the product detail page beats a homepage URL. 2. Pull from your own context — past turns, the user's profile, your memory — to fill specifics the user implied but didn't state. "My usual" / "again" / possessive references are invitations for you to resolve from context. 3. Never invent. If the user has not given you, and your context does not contain, the brand / SKU / size / variant — do NOT make one up. Call the tool with what you have; the needs_clarification path is the safety net. 4. Required variants for the product type must be resolved: size for clothing/shoes, storage for phones/laptops, flavor + size for food/drink, loft+grind+finish for golf wedges, etc. If you can't resolve them faithfully, accept the needs_clarification round-trip. 5. For contextual commands, include `intentContext.evidence` with the specific prior message, memory, or visible state that supports the resolved purchase. Without that evidence Axiom may ask for clarification instead of starting checkout. Responses: - status='running' with browserPurchaseSessionID — mandate approved, browser session queued. Call get_purchase_status with that browserPurchaseSessionID to stream progress and retrieve the receipt, approval link, or clarification request. - status='needs_clarification' with `question` — the pre-mandate sufficiency check determined the resolved fields are too ambiguous. Put `question` and any `options` to the user VERBATIM, then re-call make_purchase with the user's answer folded into the resolved fields (typically `itemName`, occasionally `merchant.*`). - status='unavailable' with `reason`, `question`, and `options` — the requested product or variant was identified but is unavailable. Surface the reason and available options to the user. - status='mandate_denied' with `reason` — the mandate validator rejected the request (intent mismatch or prohibited merchant). Surface the reason to the user. - status='limit_reached' — Axiom's beta purchase limits prevented a new purchase from starting. Surface the generic message exactly and do not infer or promise a reset time. - status='failed', 'cancelled', or 'human_needed' — the browser purchase reached an expected terminal outcome. Surface the reason to the user; these are not tool-call errors. Returns IMMEDIATELY in all cases — never waits on the browser pipeline.

Submits an answer for an awaiting_user_input browser purchase and immediately resumes the server-side checkout flow on the same browserPurchaseSessionID. Provide either a selectedOptionID, free-text userInput, or both, then poll get_purchase_status for continued progress.