An agent can find the right product, compare prices, and explain its choice, then spend the next several minutes failing to buy it. The address won't validate. The shipping options haven't loaded. The payment form sits inside a separate frame. After a timeout, nobody is sure whether the order went through.
Completing the purchase is one of the hardest problems in agentic commerce. A frontier model on a modern storefront can make it look straightforward. The harder test is what happens with a less capable model, fewer instructions, or a merchant whose checkout has accumulated a decade of exceptions.
What a checkout harness has to do
A checkout harness is the software around the model that manages the purchase. It gives the model browser tools, keeps track of progress, applies rules, and decides how to handle failures. Building that software is a substantial part of making agentic commerce work today.
Some of its responsibilities are ordinary automation: wait for a field to become usable, fill it, submit the form, inspect the result. Others require an understanding of the transaction:
- Keep the requested product, variant, quantity, and purchase frequency intact as the cart changes.
- Recheck the final total after shipping, taxes, discounts, and address corrections.
- Enforce spending limits and approval requirements before committing the purchase.
- Distinguish an action that can safely be retried from one that might place a second order.
- Preserve evidence of the outcome so the system can explain what was bought or where it stopped.
Code can enforce a spending cap and compare quantities. A model can interpret an unfamiliar page or help identify why a form was rejected. A known sequence can be reused while its assumptions still hold, with fresh inspection when the page no longer matches.
Browser automation frameworks can break a task into individual actions and replay known steps without asking a model to interpret each one again. Hosted browser agents and cloud browser infrastructure also give developers ways to run those interactions without managing the entire browser environment themselves.
The purchase still needs its own logic. If an address correction clears the shipping selection, the system has to notice and choose again. If a discount requires a subscription, it has to preserve the buyer's request for a one-time purchase. If the merchant changes its checkout, the saved flow needs a way to detect that its assumptions no longer hold.
Faster decisions still need a workflow
A capable reasoning model can interpret unfamiliar screens and revise its plan when something goes wrong. Using that level of reasoning for every small decision, though, adds time and cost to the purchase.
Specialized decision models offer another way to handle routine steps. Given the current state and a narrow question, they can return a structured answer that code can act on. The developer defines the choices and builds the surrounding flow, keeping each decision small enough to check.
For checkout, that suggests a useful division of work: identify whether the page is asking for an address correction, classify an error, or select a relevant control from known options. A developer could use those decisions inside a defined flow and reserve more capable reasoning for cases the flow doesn't cover.
That makes the design of the workflow more consequential. Someone has to supply the right state, define the possible actions, decide when confidence is insufficient, and check what happened. A structured answer can still be wrong; its type and confidence don't establish that an order was placed correctly.
This applies more broadly to smaller models and models running with less reasoning. They have a better-defined job when rules and checkout flows already exist. Hand them an unfamiliar older storefront without that support and they have to infer the procedure, interpret errors, and recover on their own. Saving inference time only helps if the purchase still completes reliably.
WebMCP and merchant adoption
WebMCP gives websites a way to make that job easier. It is a proposed browser standard through which a page can expose structured tools to an agent, using JavaScript or annotated HTML forms. A merchant could declare actions for selecting a variant or updating a cart, with defined inputs, so the agent has less to infer from buttons and page layout.
WebMCP works within the browser and the page's current session. Chrome currently offers it through an origin trial, and its documentation describes it primarily as a way to support browser workflows with a person involved.
Commerce protocols address another part of the interaction. The Universal Commerce Protocol's checkout specification defines states for a checkout that needs more information, is ready to complete, is still processing, or has produced an order. Those explicit states can remove uncertainty that a browser agent otherwise has to resolve from the page.
Both approaches depend on someone doing the integration. The merchant or its commerce platform has to expose useful tools, maintain them, and support the steps a buyer actually needs. A store can make its catalog easy for agents to search while leaving checkout untouched.
For the stores that haven't made those changes, the browser remains the available interface. That includes older sites with custom forms, inconsistent labels, and checkout behavior a regular customer has learned to work around. Better tools reduce the effort of supporting those sites, but merchant adoption and browser execution remain separate constraints. A purchase system has to account for both.
What counts as a completed purchase
A click on the order button is an attempt. A payment authorization can exist before there is a confirmed order. A timeout can leave a purchase unresolved even when the merchant has accepted it.
The system needs evidence that the merchant created the intended order, such as an order number and confirmation details that match the requested items and total. When that evidence is missing, the honest result is an unresolved purchase that needs checking. Retrying payment immediately can make the situation worse.
That is the standard to evaluate these tools against: confirmed, correct orders, with the time, cost, and human intervention required to get there. Test across models, reasoning budgets, and merchants. Faster individual actions matter when they improve that whole result.
What we're building at Axiom
We build Axiom around the purchase itself: an agent receives a request, a checkout has to be completed within the user's rules, and the outcome has to come back clearly. Payment controls and checkout execution belong in that same process. An approved way to pay is only useful if the system can reach and verify the right order.
Structured site interfaces, specialized decision models, and browser automation tools give developers more to work with. The work is choosing where each belongs, building the checkout flow around it, and handling the merchants that haven't changed anything. That is the part of agentic commerce we're focused on: getting a requested purchase through to a verified order on the web people already use.
