When the Buyer Is an Agent, Your Order Policy Becomes an API

B2B ordering has always assumed a human on the other end. A buyer reads your terms, a sales rep explains the exception, a customer service call smooths over the edge case nobody wrote down. The rules live partly in your systems and partly in the judgment of whoever is looking at the screen.

That assumption is starting to break, and it’s breaking from a specific, dateable event rather than a vague industry mood.

The Counterparty You Didn’t Configure

Two recent pieces on this blog have already covered agents calling tools through the Model Context Protocol. One looked at what happens when your own agents call each other and the combined outcome ends up with no single accountable party. Another looked at the fact that an agent with 650,000 possible actions across Dynamics 365 needs someone actively deciding what it’s allowed to call, not just a count of what’s technically available.

Both of those posts share an assumption this one doesn’t: that you configured the agent. You built it, scoped it, and can change what it’s allowed to do tomorrow if today’s version causes a problem.

The agent calling your storefront through the new Dynamics 365 Commerce MCP server isn’t yours. It belongs to your customer. You don’t write its instructions, you don’t see its reasoning, and you can’t patch its judgment. What you can control is what it’s allowed to call and what happens when it calls it — and that shifts the entire question from “what should our agent be allowed to do” to “what does our interface promise, and does it actually keep that promise.”

From Product Search to Pay-by-Link, One Call at a Time

Microsoft unveiled the Dynamics 365 Commerce MCP server at NRF 2026, with the full preview detailed in a June 29, 2026 announcement. It’s currently in preview, running on Commerce Scale Unit 10.0.48 or later. It’s cloud-hosted only, and it has to be turned on deliberately through Lifecycle Services — one Commerce Scale Unit per environment at a time. This isn’t quietly live for every Dynamics 365 Commerce customer; someone has to decide to switch it on.

Once it is on, an agent authenticated through Microsoft Entra ID can search your catalog, pull full product detail, build a cart, add and adjust line items, check delivery options, apply a coupon code, and generate a Pay-by-Link checkout the buyer completes on their own. It can look up an order and pull order history. Signed-in access unlocks the parts that matter most for B2B: saved addresses, order history, and pricing tied to that specific customer, through a delegated Entra ID token rather than an anonymous one.

The tool set also covers store inventory search, sortable by distance, and saved delivery addresses for a one-tap repeat order. None of that is exotic e-commerce plumbing dressed up as something new. Pay-by-Link runs on the same Adyen connector Dynamics 365 already uses elsewhere. The interesting part isn’t any single tool call. It’s what those calls have to be built on top of.

There’s a real technical seam here, too: an agent can’t add a master or parent product straight to a cart. It has to resolve the request to a specific sellable variant first, by pulling full product detail before it adds a line. That’s a minor mechanical detail on its own, but it says something useful — the agent doesn’t get to be vague the way a phone call with a sales rep allows a buyer to be. Every request has to resolve to something exact before the system will act on it.

Same Engine, Different Caller

Here’s the detail that does the real work in this post: quantity-break discounts, mix-and-match pricing, payment-method offers, and shipping-method pricing don’t get invoked by the agent at all. They fire automatically, inside the same cart engine that’s always priced every order, whether the caller is a browser, a point-of-sale terminal, or an MCP tool call. Coupon codes are the one promotion type the agent has to actively apply.

That’s what “order policy becomes an API” actually means in a checkable sense, and it’s a stronger claim than it sounds. The Commerce MCP server doesn’t introduce new pricing logic, new entitlement rules, or a separate contract-pricing feature built for agents. It exposes the same trade agreements, the same customer-specific pricing, and the same promotion rules that already govern every cart in the system — through an interface a piece of software can call directly, with no screen for a human to read and no rep to ask when something looks off.

For a buyer’s agent, that’s the entire relationship. It doesn’t experience your order policy as a PDF or a paragraph in a contract. It experiences it as whatever the API actually returns.

The Edge Case a Human Would Have Caught

Picture a distributor with a negotiated contract: a twelve percent discount on one product line, a minimum order quantity of fifty units, and an exception for one specific SKU that ships in cases of twenty-five instead. A human buyer who’s ordered from this account for three years knows the exception by habit. A new hire on their team would call and ask.

An agent calling the Commerce MCP server does neither. It reads whatever get_cart returns, submits an order that matches what the system told it was valid, and moves on. If the case-of-twenty-five exception was ever configured as a side note in someone’s memory rather than a rule in the pricing and quantity engine, the agent will never discover it, never ask about it, and never notice that the order it just placed doesn’t match the deal both companies believe they have.

Nothing about this requires the agent to misbehave. It requires only that one piece of your order policy was true in practice but not true in the system — a gap that survived for years because a person was always there to paper over it. An agent doesn’t paper over anything. It calls the tool, reads the response, and acts on exactly what came back.

Two Real Signals, Neither One a Finished Story

Microsoft’s own announcement names Michael Hill, a longstanding Dynamics 365 Commerce customer, as a retailer “exploring the potential” of the Commerce MCP server — exploratory language, not a completed deployment with results attached. There’s no case study yet with a measured outcome, and it would be dishonest to imply otherwise.

The more directly relevant signal is a partner product: Evenica’s B2B Licensee Product Request Agent, a Copilot Studio-based assistant Microsoft featured in the same announcement, built for B2B product discovery and intake requests using conversational AI and image recognition. It’s a real, named example aimed squarely at the B2B buying motion this post is about — a Copilot Studio agent Microsoft chose to highlight alongside the Commerce MCP news, not a claim that it runs on the Commerce MCP server itself.

Read both for what they are: early, genuine movement toward agents transacting in a B2B context, not proof that the trust problem above has already been solved by someone else.

The ERP Side of the Same Announcement

Microsoft has also been running a separate Dynamics 365 ERP MCP server since late 2025, and it’s now generally available — its earlier, more limited predecessor retires on October 1, 2026. In the same June 2026 announcement that introduced the Commerce MCP server, Microsoft describes the two working together: pricing agents reading trade agreements and cost structures from the ERP side, and post-purchase agents reconciling fulfillment and payments across both systems.

That’s a real claim, taken directly from Microsoft’s own announcement. As far as the published technical documentation goes, it’s a stated architectural direction rather than a documented integration spec — Microsoft’s framing of where things are headed, not a neutral, independently verified guarantee about how pricing, allocation, and reconciliation actually reconcile today in every deployment. Treat it as the roadmap it’s presented as.

One Layer Among Several, Not the Whole Trend

The Commerce MCP server is enterprise ordering infrastructure — a way for a business’s agent to transact with another business’s storefront. That’s a distinct layer from the consumer-facing payment protocols making similar-sounding announcements this year: Google’s AP2, Visa’s Trusted Agent Protocol, and Mastercard’s Agent Pay have all launched within roughly the same twelve months, each still in early pilot stages.

The industry’s track record so far is mixed, and a B2B ordering rollout should account for that rather than assume every agentic initiative survives contact with the market. OpenAI and Stripe’s Agentic Commerce Protocol, launched as Instant Checkout inside ChatGPT, was effectively wound down by March 2026 after only a handful of merchants integrated it.

Turning a Policy Document Into Something That Can Be Tested

Your order policy probably doesn’t need to be rewritten. The parts of it that only ever lived in a person’s judgment need to move into the system before an agent goes looking for them, because an agent will only ever find what the system can actually return.

That’s a different kind of project than most Commerce Scale Unit upgrades. It starts with going through your negotiated contracts, your standing exceptions, and your informal workarounds, and asking a specific question about each one: is this rule enforced by Dynamics 365 today, or does it only work because a person remembers it? Every answer in the second category is a rule an agent will silently get wrong, not because the agent failed, but because the rule was never actually a rule.

It also means treating the two authentication modes as a policy decision, not just a technical setting. Anonymous access is fine for a prospect browsing a catalog. A returning B2B account placing a repeat order under contract terms needs the delegated, signed-in mode — the one that actually pulls customer-specific pricing and history rather than a generic list price. Getting that assignment wrong in either direction either exposes negotiated pricing to the wrong caller or quietly denies a legitimate customer’s agent the terms they’re actually owed.

Could you say today, with confidence, that every contract exception your best accounts rely on is configured in the system rather than remembered by a person? Most operations and sales leaders we talk to can name the big pricing tiers without hesitation. Far fewer can account for every quiet exception layered on top over the years — and those are exactly the ones an agent has no way to discover on its own.

Finding those quiet exceptions before a customer’s agent does is the specific work DAX Software Solutions does with Dynamics 365 Commerce and Supply Chain teams. Walk us through your order policy and we’ll show you where it would and wouldn’t hold up as an API.