Imagine an office manager asking an AI assistant, from a phone between meetings, to send flowers to a client. Something cheerful, delivered before noon on Friday, with a handwritten note. Keep the whole order under $90.

The florist's website looks wonderful. There are peonies spilling out of ceramic pitchers, photographs of happy recipients, and a very tasteful animation. The assistant still needs to know whether Friday delivery is available, whether the client is inside the delivery area, what the final price will be, and where to put the note.

If it cannot confirm delivery, total price, and the note, the order can go to another florist. That is the practical test of AI agent readiness: can an assistant get a trustworthy answer and help the customer take the next step?

The questions hiding behind a bouquet

Humans are remarkably good at filling gaps in websites. We recognize that a little truck means delivery. We guess that “local” probably includes our neighborhood. We call when the checkout says one thing and the product description says another.

An assistant needs a dependable way to resolve those questions. A delivery boundary should have actual places or postal codes behind it. A price should have a currency and a clear treatment of fees. A product that can be ordered should be distinguishable from a photograph in last year's wedding gallery.

The harder questions involve information that changes. Friday's delivery capacity, the last available appointment, and the stock remaining in a particular size belong in the systems that manage them. Repeating yesterday's availability on another page creates another place for the answer to be wrong.

For our florist, the assistant needs to check the address and date, get the current options, and carry the selected arrangement into checkout. There is more than one way to do that.

Using the browser or calling the service

An AI can operate a browser on the customer's computer or in a separate browser session. It opens the florist's website, reads the page, selects the bouquet, fills in the address, and works through the checkout. Depending on the tool, it uses screenshots and mouse clicks, the page's underlying controls, or both. Computer and browser use tools support this kind of interaction.

That route uses the website people already use. It can work without a special agent API. Clear labels, understandable delivery choices, and a checkout that recovers sensibly from errors help the assistant navigate it. It still has to handle the screens, sign-in steps, and interruptions it encounters.

A direct service connection takes another route. Instead of finding the delivery-date selector on a page, the assistant sends a structured request to a supported API or tool. The service returns available dates or a specific reason it cannot deliver. The assistant can use that answer without interpreting the screen layout.

Both routes can lead to a real order. Both need the customer's authority and a reliable confirmation from the store. A browser agent may handle most of the shopping and use a connected tool for one step.

But building the future of AI commerce around clicking through websites would carry a lot of yesterday's friction into tomorrow's shopping. An assistant using your computer can occupy the browser while you need it for something else. A remote browser can keep your screen free, but it still has to work through pages, sessions, and interruptions built around a person sitting at a screen.

The phone makes the case especially clear. Our office manager has made the request while heading to the next meeting. There is no desktop session to hand over, and opening a laptop should not be a condition of getting the flowers sent. A direct connection lets a compatible assistant ask the florist's service for delivery options and bring the decision back to the conversation on the phone. A hosted browser can offer another route, but the request should not depend on taking control of the customer's device.

Direct transactability is where businesses should be preparing to go. A customer's assistant should be able to request delivery options, receive current terms, and carry out an approved order through the services that actually run the business. The customer can set the task and make the decisions that need a person. The florist can serve the request without requiring a guided tour of its checkout screens.

That takes preparation on the business side. The offer has to be understandable, the relevant service has to be reachable, and the permitted action has to produce a result the customer can rely on. A shop that has spent years perfecting its website for people now has another kind of customer interaction to support.

Where MCP, OpenAPI, and agent cards fit

The florist needs current answers from the systems that run delivery and checkout. The three terms you'll hear around that connection do different jobs.

If the delivery service has an HTTP API, software needs to know how to use it. What goes in the address field? How is the date supplied? What comes back when delivery is full? An OpenAPI description lays out those operations, inputs, and responses in a shared format. It describes a working service. The OpenAPI specification defines the format.

The florist could also offer a tool that checks delivery coverage through an MCP server. A compatible AI application can discover that tool and request its use; the server connects the request to the business's delivery system. MCP gives the application a standard way to work with tools and information outside itself. The Model Context Protocol documentation explains how that connection works.

Suppose the florist goes further and runs its own agent to handle order enquiries. An A2A agent card can describe what that agent does, how to reach it, and what authentication it requires. Another agent then has the information it needs to start working with it. The card belongs to an actual agent service; a business profile saved as JSON serves a different purpose. The A2A discovery documentation describes what the card contains.

A small business does not need to collect all three names before it can make progress. Its existing commerce or scheduling provider may already supply the relevant connection. A custom service might benefit from a small API or MCP tool. An A2A agent card makes sense when there is a service agent worth discovering.

Choose the connection around the customer task. Otherwise, a perfectly respectable bouquet becomes an infrastructure project.

Start with the service you already run

Before commissioning anything, find out what your current platform supports. Ask which AI clients or commerce channels it works with and what your account must enable. Have the provider show an assistant handling a real version of your customer's request: the right item, a current delivery slot, the full price, and a customer-approved checkout. Then check whether the order appears in your own system with a usable reference.

There is a meaningful difference between finding a checkout link and completing that sequence. Both can be useful. Knowing where the path ends tells you what to fix next.

For some businesses, the useful improvement will be surprisingly modest: consistent service descriptions, a correct booking destination, or a product catalog that contains the information customers actually compare. Others will need a provider setting changed or a carefully scoped integration. The work should follow the obstacle.

A useful failure is part of the service

Return to the flowers. Suppose delivery before noon is full. A helpful service would return that fact with the available alternatives: delivery after two, collection from the shop, or the next morning. The customer can decide whether any of those still solves the problem.

Now suppose the connection drops after the order is submitted. The next request should be able to establish what happened. Charging again because the first response went missing would be an expensive way to discover that your new visitor is very persistent.

An agent connection needs the same commercial care as any other sales channel: current information, appropriate access, customer approval where required, clear confirmation, and a way to recover. Software makes the questions arrive faster. The business still owns the answers.

Why getting ready is business work

The office manager cares whether the flowers will arrive on Friday. The florist cares about earning the order and fulfilling it. Neither should need to become an expert in agent protocols to get there.

This is the work businesses need help with as AI transactability develops: finding out what their current platforms support, making the offer clear to an assistant, and addressing the gaps between a recommendation and a completed customer task. At AI Promo Services, that is the purpose of Transact. We examine what an assistant can learn about your business, where it can send the customer, and what stands in the way of acting through your own services.

We make our own public AIPS information available through a REST API, an OpenAPI description, and four read-only MCP tools. A compatible client can request our product descriptions, integration requirements, and methodology directly through our public developer interface.

Our public tools do not expose your calendar, stock, or checkout. An assistant may work through your existing website today; connecting those services directly requires the appropriate provider support and authorization. Finding that next workable connection is part of getting your business ready. It is worth doing before a customer asks an assistant to buy and discovers that the conversation has nowhere to go.

Start with one customer request you would hate to lose. Try asking an assistant about it, follow the links it finds, and notice which facts it has to guess. That gives you something specific to improve.

Then run the free AI Visibility Audit to see how clearly your website explains your offer and where it sends a customer ready to book, buy, or get in touch. It costs $0 and needs no card.