Buyer agents: what does your software need to expose?

Exposing an offer to buyer agents is not the same as opening a product API. It means publishing the offer on the commercial surface in a format a machine reads without opening a browser. The path exists and has an address: the Universal Commerce Protocol, published on January 11, 2026, with its specification at ucp.dev. What stays open is the content of that path.

On October 16, 2026, Vercel shipped the pieces that make the path executable: Vercel Shop in general availability, an open source storefront template in Next.js for Shopify, and the rebuilt Hydrogen SDK, also in GA. That settles the infrastructure for anyone selling a physical product. It does not settle the plan with a term, the per-seat limit or the billing region. Publishing the offer as data and deciding who answers for an order assembled by a machine remains the software vendor's job.

What changed on October 16, 2026?

On October 16, 2026, Vercel moved Vercel Shop into general availability and put the rebuilt Hydrogen SDK into GA. Vercel Shop makes UCP capabilities discoverable on the merchant's own domain, where a buyer agent reads them.

UCP was published on January 11, 2026, co-developed by Shopify with Google, with the specification at ucp.dev. It covers five capabilities: Catalog, Cart, Checkout, Identity Linking and Order Management. Account linking uses OAuth 2.0. Autonomous completion depends on the AP2 mandate extension; without it, the specification requires the checkout to finish in a trusted interface with the buyer present. The requires_escalation state, with a mandatory continue_url, hands the transaction back to a person when data or authorization is missing. Profiles live at /.well-known/ucp, on the merchant's domain.

UCP changes the cost of integration per pair. A buyer agent that speaks UCP does not need a custom connector for every store. UCP defines the catalog, cart and checkout capabilities and rests the specification on REST and JSON-RPC transport, with built-in support for AP2, A2A and MCP. MCP for e-commerce is the tool-call layer: the agent calls a tool that speaks UCP, without browsing the site.

The announcement names AG1, Bombas and PAIGE as users of the stack. PAIGE, a retailer, recorded +22% revenue and +76% conversion between Black Friday and Cyber Monday, with no downtime, in the case Vercel published. That is retail data, supplied by the vendor, inside a promotional window, and it does not measure B2B software.

The announcement proves a standardized path to checkout exists. It does not prove the market buys through agents at scale.

What changes when the product is software, not a t-shirt?

Software inventory is not a shelf. A subscription plan carries a license, seats, billing region, usage limit, term and renewal condition, and each item decides whether that plan can be sold to that company, in that country, for that period.

When an agent reads availability on a retail storefront, it reads quantity. In your case the same word covers a different question: can the top tier plan be sold to a company in Mexico, in dollars, with 400 seats and an annual renewal? The answer lives in commercial policy, not in inventory.

The reading failure shows up quickly. The agent finds the public price, assembles the order, and the order reaches an entity that cannot be invoiced in that currency. Nobody made a mistake in the code. The page did not say what the company already knew.

The retail to B2B translation has a limit: Vercel's announcement is about stores selling physical product. Reading license, seat and term as equivalents of inventory is this piece's analysis, not a fact from the source.

What do buyer agents need to find on your commercial surface?

Five answers, in the order of the purchase: what the offer is, what is included, where and at what volume it is available, which term and tier options exist, and where the order closes. In software, each answer carries a commercial condition that retail settles with a SKU.

The right-hand column is a derived requirement. It is not a protocol feature.

In retail, the checkout link is the end of the path. In software, it opens an approval that lives with the buyer.

How does the same URL serve the person and the agent?

A product URL serves both readers: the person sees the page with price, availability and options, and the agent reads the same content in a structured format. They are two reading contracts. For an ISV, the plan page stops being marketing and becomes a data contract.

A stale price does not only generate a confused lead. It generates a wrong order, with a number and an owner.

A machine-readable catalog does not come from a new page. It comes from update discipline. The plan limit changed, a region opened: the change reaches the data before the announcement. The reading happens in an intermediate layer, where a record of the query has to exist, as described in the layer that centralizes agent access and logging.

The source does not claim that every merchant has to rewrite the site, nor that machine reading replaces the visual page.

What changes at checkout when the buyer is an agent?

In retail, cart and checkout link close the purchase. In B2B software, the cart carries intent and the closing carries commitment: term, volume, payment terms and who signs. The design point is where the checkout link stops and where the buyer's approval begins.

UCP takes the path as far as checkout and provides for escalation to a person when the transaction leaves what the agent can complete. A specification that reserves that state already says automation has a limit, and that the limit is part of the flow.

The human step does not disappear, it moves: proposal, legal review and signature become an order awaiting confirmation, and the effort shows up when someone says yes.

Reading a catalog and closing an order have different blast radii, and treating them with the same credential and spend per agent is the shortest route to an order nobody planned to pay for. In an MCP server that exposes catalog and checkout, the tool that checks price and the tool that closes the cart should be two, with their own credential and ceiling.

The protocol does not decide commercial policy: offerable price, commitment ceiling, allowed catalog, term, exceptions and who signs inside the buyer. It does not sign that.

Who authorizes the order, and what gets recorded?

Two decisions, and they belong to the company, not to the protocol. The first is the authority the agent receives: value ceiling, allowed catalog, term and exceptions. The second is what the vendor records in order to reconstruct the decision later, when someone asks why.

Commercial authority is written in numbers and lists. An agent that commits up to a ceiling per order, inside a named catalog, with a term of up to twelve months and no exception for a non-approved region is an agent an auditor can describe. A per-order ceiling without a per-period ceiling is a limit the second order has already broken.

The record mirrors that. The vendor needs to know which agent asked, on behalf of which company, with which credential, which price version was read and which one was honored at closing, and with which operation identifier.

The discussion here is the commercial authority of the seller and of the buyer, and the problem appears when the credential is shared across agents, in which case caller identity separated from the credential answers who asked. Account access control is a different topic.

What to do in the next 90 days

Start with the inventory, not the integration. The offer a B2B ISV keeps in a page, a PDF and a spreadsheet has to become a set of checkable fields, and purchasing authority has to be written down, with a ceiling and a scope, before the first automatic order.

1. Inventory the offer spread across a page, a PDF and a spreadsheet. The mistake avoided is discovering that the official price and the practiced price live in different files.
2. Separate what is publishable as data from what is negotiation. A volume discount, once published, creates a commitment nobody approved.
3. Define a per-order ceiling, a per-period ceiling and the scope of authority before switching checkout on. Without all three, a configuration mistake becomes a budget commitment.
4. Decide what to record before the first order. Agent, company, credential, price version and authorization are the minimum for an audit.
5. Test the reading with a real agent before announcing support. It reveals the missing field, the price in two currencies and the availability that lives in the CRM.

None of them promises a return within a deadline.

Where Nexforce Agents fits in this layer

The protocol takes the agent to checkout; by default, completion stays with a person in a trusted interface, with explicit escalation when the flow requires human approval. What remains after checkout is operational work, and it does not belong to the protocol.

Nexforce Agents takes on that work: the unit develops and implements agents in B2B operations, with Nexforce Work and Nexforce Code, and the approvals and permissions layer where the company records what each agent may do.

Nexforce Work is an agent workspace for business teams, with multi-workspace orchestration, sandboxed execution and MCP connectors. Nexforce Code is the runtime for developers, with headless execution for automation and CI. Both address what the specification leaves open: the agent that queries the commercial surface and the approvals and permissions layer with which the company limits what it can do.

The decision remains with the company.

In the Nexforce Marketplace, software procurement is in BRL and comes with a fiscal invoice. That does not define the agent's scope, does not authorize the purchase and does not assume the order it assembled.

Frequently asked questions

What is UCP, and what does it change for anyone selling software?

The Universal Commerce Protocol is a specification published on January 11, 2026, co-developed by Shopify with Google, available at ucp.dev. It defines a common path for catalog, cart, checkout, identity linking and order management. For anyone selling software, it changes the cost of being read: the offer depends on plan, limit, region and term published as data.

Does the site have to be rewritten for an agent to buy?

No. The same URL that serves the visual page can serve machine-readable content, with price, availability and options. The work is not rebuilding the site, it is keeping the data current, and in software it is larger than the technical part: deciding which fields are public, how often each one changes and who is accountable for each.

Does this apply to B2B software, or only to retail?

The standardized path was announced with stores selling physical product, and the published case comes from a retailer. The reading structure is not exclusive to retail: software also has a catalog and availability, even though in software availability means license and region. Anyone selling software translates the fields, and that translation is a product decision about what enters the catalog.

Who answers when an agent closes a wrong order?

Responsibility does not change owner because a machine assembled the order: the specification keeps the business as Merchant of Record, and commercial responsibility runs from the seller to the buyer, not through a legal regime of the protocol that splits fault between agent, seller and buyer. The record is what makes it possible to attribute the order: agent, company, credential, price version read and honored, operation identifier.

References

• Vercel, "Vercel and Shopify make agents first-class shoppers", October 16, 2026. https://vercel.com/blog/vercel-and-shopify-make-agents-first-class-shoppers (accessed on 2026-10-23)
• Universal Commerce Protocol, protocol announced on January 11, 2026; specification consulted in its current version (v2026-08-25). https://ucp.dev/latest/specification/overview/ (accessed on 2026-10-23)

The decision that cannot wait

The protocol already exists. The readable catalog does not. The question that decides the investment is not which specification to adopt, it is who signs the order the agent assembled.

Two actions, in this order: expose the offer as checkable data and define purchasing authority before switching checkout on. No public data says what share of B2B ISVs already publishes an offer that buyer agents read, and whoever waits for the number arrives after the first mistake.