Can an AI assistant buy from your business yet?

An AI assistant may help a buyer find your business, request a service or complete a purchase. Those are different capabilities. A working checkout requires a defined offer, a supported transaction path and authority from the buyer. Being mentioned in an answer establishes none of them.

The useful starting question is: what should the buyer be able to complete, and what commitment would that create? The answer depends on the specific offer. Selling products or services does not settle it on its own.

Separate research, requests and purchases

An assistant that finds a calendar has not booked a meeting. A submitted request is not necessarily an accepted booking. An order confirmation and a payment confirmation may also be separate events. Show the actual state instead of a generic “done”.

Public information can often be read without connecting a new tool. Customer-specific status and documents require appropriate access controls even when no record changes. The agent-callable guide covers those permissions.

For services, decide whether the offer is ready to buy

A fixed service with clear terms may be suitable for online purchase. A custom engagement whose scope, inputs and responsibilities are unresolved needs agreement first. A price band is not a final quote.

Our free 30-minute growth consultation, two-week paid AI Opportunity Audit and scoped pilot build are distinct engagements. The pilot covers an agreed workflow with acceptance and stop criteria. Clear names help people and assistants compare the work without confusing a consultation with a paid project. Reading an offer does not select a workflow or create a signed scope. Confirm the work and its acceptance criteria in writing before authorizing a purchase.

For a hypothetical consultancy, a useful assistant journey might be: read the scope, identify the missing inputs, prepare an enquiry, show it to the buyer and submit only after approval. The response should say “request received” if the business still needs to accept it. It should not invent a confirmed start date.

You can improve that journey through clear pages and a working form. Commission a new integration only when a specific task needs it. Agent-led growth explains how to test discovery and accurate descriptions separately.

Choose a protocol for the transaction you need

These sources were checked on 9 October 2026. Confirm the target platform’s current merchant eligibility, countries, supported offers and onboarding before budgeting an implementation. An open specification and access to a particular platform are different things.

• Universal Commerce Protocol (UCP) covers commerce interactions from discovery through checkout and orders. Check the separate Google integration guide for participation requirements.
• Agentic Commerce Protocol (ACP) supports agent-mediated checkout; implementing it does not automatically list a merchant on an AI platform.
• x402 supports payment associated with HTTP requests, including paid API access. It does not define your service scope or delivery process.

UCP and ACP address overlapping commerce needs. Neither is synonymous with an app directory, and a checkout implementation is not a promise of recommendations. Ask an implementer to name the actual buyer surface, supported version, payment provider and failure behaviour. You do not need every protocol to answer one customer need.

Test one purchase path before exposing it

Choose one eligible offer and a test environment. Use test accounts and the payment provider’s test facilities, without charging a real customer. Include the work after payment: confirmation, fulfilment, support and reconciliation.

For a hypothetical retailer, start with one product variant, quantity, destination and currency. Confirm the final amount, fees and delivery terms on the server and show them to the buyer before approval. If a material term changes, request fresh confirmation. Do not let the assistant invent a substitute or silently accept a higher total.

Keep the request identifier, approval, authoritative order state and payment reference connected. Avoid putting full payment details or unnecessary personal data in logs. Test what the buyer sees when the assistant disconnects and how a staff member resolves an uncertain transaction.

Google’s UCP FAQ leaves real-time inventory and delivery-address validation with the merchant. A protocol does not remove those operating responsibilities.

Decide from a completed journey

Before approving development, write down the offer, target platform, permitted actions, confirmation point, owner, support route, implementation cost and ongoing fees. Budget catalogue maintenance, testing, exception handling and payment reconciliation as well as the connector.

After launch, distinguish assistant-originated requests, accepted orders, successful payments, fulfilment, cancellations and refunds. Use transaction records to avoid double-counting. Revenue before fees and refunds is not profit, and one completed test order does not establish demand.

If the obstacle is inaccurate or missing information, start with the page and generative engine optimization. If the obstacle is a specific transaction your customers need, compare product configuration and custom work using the build-versus-buy guide. The deliverable should be a dependable customer journey with a named operator.