> ## Documentation Index > Fetch the complete documentation index at: https://conto.finance/docs/llms.txt > Use this file to discover all available pages before exploring further. # Using the Assistant > Operate the hosted Conto Pay agent with natural language prompts for profiles, checkout links, requests, activity inbox review, approvals, receipts, and payment execution. # Using the Conto Pay Assistant Conto Pay is meant to feel like an agent, not just a wallet screen. The assistant is the main way to operate the hosted workspace: it keeps track of wallet readiness, the current payment draft, recipient controls, approval routing, and payment execution state. ## Activation And Live Mode When a user asks whether Conto Pay is ready, the assistant should check the workspace status or profile. Those tools expose the current activation status, whether live payments are enabled, and the latest live-review request state. Treat `livePaymentsEnabled` as the source of truth: if it is false, guide the user through sandbox testing, launch evidence, or the Activation card live-review request instead of describing the workspace as live-money ready. For launch review prep, in-product agents can call `get_conto_pay_launch_evidence`, and authenticated external agents can fetch `GET /api/conto-pay/launch-evidence`. Both return the same `{ launchEvidence }` packet as the Activation card copy action and intentionally omit SDK key prefixes and support-only review metadata. Use `launchEvidence.liveReview.rolloutPolicy` to explain no-review-yet, controlled rollout, open rollout, or paused approvals in customer-safe language. Use `launchEvidence.publicRolloutEvidence` to show missing public-rollout evidence labels and counts without exposing owner names, funding details, or internal reviewer metadata. `get_conto_pay_profile` also returns compact `rolloutReadiness` and sanitized `publicRolloutEvidence` summaries for ordinary setup/profile questions, while launch evidence remains the complete customer-safe handoff packet. ## Common Tasks | Goal | Example prompt | | --------------------------- | ----------------------------------------------------------------------------------------------------- | | Check workspace status | `Show me my Conto Pay workspace and payment draft.` | | Show my profile | `Show my Conto Pay handle, profile URL, and setup checklist.` | | Name my account | `Name my Conto Pay account Vendor AP and add search aliases for Accounts Payable and Vendor Billing.` | | Check wallet readiness | `Check why the Conto Pay wallet is not ready yet and what needs attention.` | | Refresh balance | `Refresh my Conto Pay wallet balance and tell me if it is ready to send.` | | Request sandbox funds | `Request Tempo testnet pathUSD for the Conto Pay wallet.` | | Review hosted controls | `Show me the current Conto Pay wallet limits and approval threshold.` | | Copy launch evidence | `Show my Conto Pay launch evidence and support packet for live review.` | | Fetch launch evidence tool | `Get my Conto Pay launch evidence packet for the live-review handoff.` | | Search the directory | `Search Conto Pay for Vendor Org and show the best matches.` | | Create a checkout link | `Create a Conto Pay request link for 250 pathUSD with memo "Invoice INV-100".` | | Cancel a checkout link | `Cancel the active checkout link for invoice INV-100.` | | Review contacts | `List my Conto Pay contacts and show which ones are saved.` | | Rename a contact | `Rename @vendor-org/accounts-payable to Vendor AP in my Conto Pay contacts.` | | Favorite a contact | `Add @vendor-org/accounts-payable to my favorite Conto Pay contacts.` | | Set contact defaults | `Set payment defaults for @vendor-org/accounts-payable to 250 pathUSD for June settlement.` | | Set contact limits | `Limit @vendor-org/accounts-payable to 500 pathUSD per Conto Pay payment.` | | Review contact trust | `Review and trust the current Conto Pay profile for @vendor-org/accounts-payable.` | | Pay with saved defaults | `Pay @vendor-org/accounts-payable using its saved Conto Pay defaults.` | | Add a recipient | `Add Acme Labs as a Conto Pay recipient at 0x1234...` | | Resolve a network payee | `Resolve @vendor-org/accounts-payable and show me the target wallet and chain.` | | Add a network recipient | `Add @vendor-org/accounts-payable as a Conto Pay network recipient and make it my default recipient.` | | Create a payment request | `Request 250 dollars from @buyer-org/accounts-payable for June settlement.` | | Review payment requests | `List incoming and outgoing Conto Pay payment requests.` | | Prepare an incoming request | `Prepare the latest incoming Conto Pay payment request for payment.` | | Set the payment target | `Set the draft recipient to Acme Labs.` | | Set the amount | `Set the Conto Pay amount to 250 dollars.` | | Add a purpose | `Use "April data labeling invoice" as the payment purpose.` | | Authorize the request | `Authorize this Conto Pay payment.` | | Inspect payment state | `Inspect my latest Conto Pay payment and tell me whether it is ready, waiting, or needs retry.` | | Review the activity inbox | `Show my Conto Pay activity inbox and the next actions I should take.` | | Open the latest receipt | `Give me the latest Conto Pay receipt or status link.` | | Review approvals | `List pending Conto Pay approvals.` | | Approve a payment | `Approve the latest Conto Pay payment.` | | Deny a payment | `Deny that payment and explain why.` | | Cancel a request | `Cancel that Conto Pay payment.` | | Retry a failed request | `Retry the latest Conto Pay payment.` | | Send after approval | `Send the approved Conto Pay payment now.` | ## Payment Lifecycle ```mermaid theme={null} sequenceDiagram participant User participant Assistant participant Pay as "Conto Pay" participant Policies participant Chain User->>Assistant: Check wallet readiness Assistant->>Pay: Refresh wallet state / request sandbox funds User->>Assistant: Add recipient, amount, and purpose Assistant->>Pay: Update hosted draft User->>Assistant: Authorize payment Assistant->>Policies: Evaluate wallet and agent policies alt Approved immediately Policies->>Pay: Approved User->>Assistant: Inspect payment state User->>Assistant: Send payment Pay->>Chain: Execute transaction Chain->>Pay: Confirmed else Requires approval Policies->>Pay: Pending approval User->>Assistant: Approve or deny request Pay->>Chain: Execute only after approval else Execution failed Pay->>Assistant: Return diagnosis and next actions User->>Assistant: Retry or cancel request else Denied Policies->>Assistant: Return denial reason end ``` ## Paying Another Conto Pay Workspace To pay another organization already using Conto Pay, the assistant first resolves that hosted workspace and stores it as a verified network recipient in your normal allowlist. The target can be identified by: * a handle like `@vendor-org` or `@vendor-org/accounts-payable` * the account display name or public search aliases such as "Vendor AP" * organization slug or organization name * agent ID, agent slug, or agent name * hosted wallet address Directory matches include the hosted profile, Profile API, `paymentMode`, `agentReadiness`, `liveReview.rolloutPolicy`, and safe Pay/Request URL templates, so an agent can verify the JSON profile contract, rollout status, and action safety before saving, paying, or requesting from the payee. After the recipient is added, the payment lifecycle is the same as any other Conto Pay payment: draft the payment, authorize it against policies, wait for approval if needed, then send it from the hosted workspace. If the payer is using a saved contact and the saved trust snapshot no longer matches the current Profile API fingerprint, wallet, chain, currency, organization, or agent identity, Conto Pay blocks saved-contact payment preparation. The assistant should surface the trust warning, fetch or show the current Profile API details, and ask the operator to run `review_conto_pay_contact_trust` only after they accept the current public profile. ## Sharing Your Hosted Profile The assistant can also help operators start from the hosted Conto Pay identity rather than a raw wallet address. * ask for the current handle and hosted profile URL when you want another team to pay or find you * add public search aliases to the pay profile when counterparties know the account by team name, invoice desk, or internal vendor nickname * ask for Conto Pay contacts when you want saved payees or recent request counterparties before a broader directory search * rename saved contacts with personal aliases while keeping the verified Conto Pay handle visible * favorite saved contacts so repeat agent payees appear first in contact lists * review saved contact trust when the Profile API fingerprint, wallet, chain, or public name changes * set saved contact payment defaults for common amounts or purposes, then pay with those defaults * set saved contact limits for max per-payment amount, daily cap, approval requirement, or request permission * ask for contacts with trust warnings when a saved payee's public profile or hosted wallet may have changed * accept the current profile with `review_conto_pay_contact_trust` only after the user has reviewed the warning details * save a recent contact when you want future payments to use the verified network-recipient flow * use directory search when you know the organization or agent name but not the handle * use directory search when you know a public account alias but not the exact handle * start a payment or payment request from a directory result without opening the profile first * copy a hosted profile link from your profile card, contact row, or directory result * copy the Profile API link when another agent needs a JSON identity card for the same handle * use the hosted profile's payment-mode and readiness badges when a human operator is reviewing the payee in a browser * copy the Agent handoff packet when another operator or agent needs the handle, profile URL, Profile API URL, pay/request templates, activation state, public live-review state, `livePaymentsEnabled`, settlement details, compact `agentReadiness`, discovery aliases, instructions, and suggested prompts in one public-safe JSON object * use `get_conto_pay_profile` for ordinary setup/profile questions when the agent also needs compact `rolloutReadiness` and sanitized `publicRolloutEvidence` preview fields * fetch launch evidence when an operator or agent needs live-review prep plus public `paymentMode` and `agentReadiness.actions` in the same customer-safe packet * use the handoff packet `liveReview.status`, `liveReview.nextAction`, and Profile API URL to explain whether Conto live review is not requested, requested, in review, or completed * use `publicRolloutEvidence.status`, `missingFields`, and `nextAction` from launch evidence when the operator asks which public rollout approvals or owners still need to be captured * use `liveReview.rolloutPolicy` from launch evidence or the Profile API when the user or another agent asks why live payments are still guided, paused, or waiting on Conto rollout approval * use the hosted Pay and Request actions when a team shares a profile page directly; those actions also expose copyable deep links with the amount, memo, and invoice fields included * prefill a hosted profile link with `mode`, `amount`, `purpose`, and `invoiceId` when you want the recipient to open a ready-to-review pay or request form * ask the assistant to create a shareable payment link, request link, checkout link, or prefilled profile link; it uses `create_conto_pay_profile_checkout_link` and does not authorize or send money * use checkout link status, expiry, open count, last-opened time, and cancellation state to explain whether a shared link is still safe to use * when consuming another profile as an agent, fetch the Profile API and use the `actions.pay` or `actions.request` metadata for field schemas, URL templates, and the safe assistant prompt * when consuming another profile as an agent, also read `profile.discovery.aliases`, `profile.discovery.queryExamples`, and `profile.discovery.agentInstruction` before showing the payee name or suggesting how another agent should search for it * before presenting a profile as live-money ready, check `profile.activation.livePaymentsEnabled`; use `profile.liveReview.status` only to explain where Conto live review stands * use `profile.agentReadiness.actions` when deciding whether to verify, Pay, Request, or present live payments; `paymentMode.canPresentLivePayments` remains the source of truth for live-money claims * cache Profile API reads with the response `ETag` or `profile.integrity.fingerprint`, then refetch and compare the fingerprint before saving a payee, paying, or presenting live-money readiness * when listing saved contacts, use the saved trust snapshot `profileFingerprint` to explain whether the contact still matches the last reviewed Profile API identity * when consuming a tracked checkout link as an agent, keep the `intent` query parameter in the Profile API call so the response includes public checkout intent context This keeps discovery and payment setup inside the same hosted model as the rest of Conto Pay. ## Managing Checkout Links Checkout links are durable Conto Pay records, not throwaway URLs. The assistant and console can use them to hand a pay or request flow to another operator or agent while keeping the actual money movement gated by Conto Pay authorization. The assistant can: * create a Pay link or Request link for the current hosted profile * include amount, memo, and request-only invoice ID * return both the hosted profile URL and direct `/conto-pay` handoff URL * explain that opening the link only stages or prepares work; it does not send funds * report whether a link is active, expired, used, or cancelled * show the open count and last-opened timestamp for recent links * cancel an active checkout link when the amount, memo, invoice, or payer handoff is stale Agents should resolve the Profile API for a tracked checkout link before acting on it. If the Profile API response includes a `checkoutIntent` object with `CANCELLED` or `EXPIRED` status, the agent should ask for a fresh link instead of preparing a draft from the stale handoff. ## Requesting Payment From Another Workspace Hosted payment requests let a payee ask another Conto Pay workspace for payment before the payer starts drafting anything manually. The assistant can: * create a hosted request against a handle, organization, agent, or hosted wallet * include amount, purpose, invoice ID, due date, or expiration when needed * list incoming and outgoing requests * prepare an incoming request into the current payer draft without sending money When a payer prepares a request, Conto saves the requester as a verified network recipient and stages the amount and purpose, but the payer still authorizes and approves the payment through the normal hosted controls. Saved-contact trust warnings still apply when an operator asks to pay from a familiar alias or saved default. If `prepare_conto_pay_contact_payment` returns a trust block, do not call the lower-level network payment prep tool until the operator reviews and trusts the current profile. ## Example Network Prompts ```text theme={null} Resolve @vendor-org/accounts-payable and show me the target wallet and chain. Add that workspace as a Conto Pay network recipient. Set the draft recipient to Vendor Org Conto Pay. Set the Conto Pay amount to 250 dollars. Use "June settlement" as the payment purpose. Authorize this Conto Pay payment. Inspect my latest Conto Pay payment and tell me whether it is ready, waiting, or needs retry. Send the approved Conto Pay payment now. ``` ## Recommended Operator Flow 1. Start by asking for the current workspace and draft. 2. Confirm the hosted wallet is ready before you authorize a payment. 3. In sandbox, request Tempo testnet funds if the wallet is present but underfunded. 4. Add or confirm the recipient before setting the amount. For cross-org hosted payments, resolve the target workspace and add it as a network recipient first. 5. Resolve any saved-contact trust warning before staging a repeat payment from defaults. 6. Set a clear payment purpose so approval reviewers have context. 7. Authorize the payment before asking to send it. 8. If a request moves to review, approve or deny it from the same assistant thread. 9. If execution fails, inspect the payment state first, then retry or cancel deliberately. ## Using The Activity Inbox The assistant can inspect the same unified activity inbox shown in the hosted workspace. * contacts show saved and recent agent accounts with aliases, favorite status, handles, profile links, trust status, profile-change warnings, payment defaults, payee limits, and suggested Pay/Request/Save/Rename/Favorite/Defaults/Limits prompts * direct payments and hosted requests appear in one timeline * items can be filtered by kind, direction, status, or next action * the assistant can return the primary hosted URL for a request or receipt * operators can copy the same full hosted URL from the activity inbox, request page, or receipt page * the next step stays explicit, such as `view_receipt`, `check_status`, `prepare_payment`, or `review_request` This is useful when operators are juggling both payables and receivables in the same Conto Pay thread. ## What The Assistant Can Manage The Conto Pay assistant is not limited to drafting a payment. It can also manage the hosted control surface around that payment: * wallet readiness and balance refresh * Tempo sandbox funding for the hosted wallet * recipient allowlist management * Conto Pay network-recipient resolution and verification * Conto Pay contact lookup, aliases, favorite pins, and payment defaults for saved and recent agent accounts * contact trust warnings based on saved Profile API fingerprints, with payment prep blocked until the current profile is reviewed * hosted profile naming, directory listing controls, shareable identity links, and public Profile API lookup * checkout link creation, open tracking, status inspection, and cancellation * hosted payment-request creation and review * approval threshold visibility and updates * wallet spend-limit visibility and updates * payment inspection for ready, waiting, failed, cancelled, or blocked requests * activity inbox review across payments and requests * hosted receipt and status links for the current request * retry and cancellation workflows when a request does not complete cleanly This is useful because the same conversation can move from setup, to review, to execution, to recovery without forcing the operator into a different tool. ## Reading Payment State When you ask the assistant to inspect a payment, Conto Pay summarizes the current request and the next operator action: * `ready` means the request is approved and can be sent * `waiting` usually means approval is still pending * `needs retry` means execution failed or the request needs another operator action * `cancelled` means the request was stopped before execution * `blocked` means the request cannot move forward in its current state If a request failed, Conto Pay points you back to the likely next step: refresh the wallet, confirm policy and balance readiness, then retry only if the request is still valid. ## Sandbox And Live Money The default Conto Pay workspace is sandbox-first, but the operating model stays the same: * the assistant remains the primary interface * the hosted wallet still has to be ready before payments can move * the same Conto policies are evaluated * the same approval workflow is used * Conto Pay network recipients still go through the same hosted controls * the same hosted agent state tracks the draft and the request lifecycle What changes between sandbox and live is the funding and execution environment, not the way users operate the hosted agent. Live use is enabled through Conto's guided rollout after workspace readiness, controls, support ownership, launch scope, trust-report ownership, and deployment evidence are reviewed and recorded. ## Related Docs Learn what Conto Pay provisions and how it differs from self setup Learn how launch evidence, live review, and rollout gates affect assistant behavior Understand the review path for requests that need a decision