Part 3 of 5. Part 2 covered how to let an agent read your catalogue without leaking customer records. Now the harder half: the agent doesn’t just want to look — it wants a price it can trust and, eventually, an action it can take. Both are where quiet, expensive mistakes live.

The price an agent sees must be the price a human would pay

When a customer browses your site, the price they see is computed live: base price, the customer’s currency, any active promotion, tax rules for their region, tier or subscription discounts. That computation is your pricing engine, and it is the source of truth. The moment an AI agent enters the picture, there is a tempting shortcut — export a flat price list, a nightly feed, a cached JSON blob — and hand that to the machine consumers. Resist it. A separate feed is a separate source of truth, and two sources of truth for the same number will diverge. It is not a question of if but when.

Consider what a divergent feed actually does. An agent reads €49 from a stale export. Your checkout, running the real engine, computes €59 because a promotion ended at midnight. Now you have three bad outcomes and no good one: you honour the €49 and eat the margin at scale; you charge €59 and the agent — acting for a customer who was quoted €49 — experiences it as a bait-and-switch; or the transaction fails mid-flight and the agent abandons you for a competitor whose numbers reconcile. Multiply that by the volume an automated channel can generate and a “small” feed lag becomes a systematic pricing incident. Worse, it is silent: no human is watching the agent’s screen to notice the mismatch.

The architectural fix is boring and correct: the catalogue an agent reads is priced by the same pricing engine that runs human checkout. One code path, one place where currency, tax, and promotion logic live. The agent’s read and the customer’s checkout ask the same engine the same question and get the same answer, because there is no second answer to get. This is how VBWD is built — the machine-readable catalogue an agent consumes over the native MCP endpoint is priced by the checkout engine itself, so the price an agent sees is the real, authoritative price rather than a snapshot of what it used to be.

A practical test for your own stack: if you can point at the line of code that prices a product for an agent and it is not the same line that prices it for a human, you have a divergence waiting to happen. Collapse the two.

Reads are cheap to get wrong; actions are expensive

Part 2’s search seam already draws one line — what an agent may read. This part is about the second, sharper line: what an agent may do. Reading a stale price costs you a reconciliation headache. Letting an agent perform an action you didn’t intend — cancel a subscription, issue a refund, mutate an order, change an address — costs you real money or a real incident. Every action you expose to a machine is a security surface, and it should be treated exactly as you’d treat a public API endpoint with no human in the loop.

The discipline is ordinary role-based access control, applied with unusual rigour because the caller is autonomous. Access levels scope what an agent may invoke; you grant only the specific actions you intend, and you default to none. “Read the catalogue and check availability” is a very different grant from “create an order,” which is different again from “refund an order.” Bundle them together under one broad permission and you have handed an automated caller the keys to operations you never meant it to reach.

# Least-privilege by default: an agent principal grants nothing until you say so.
agent_role = Role("storefront-agent")
agent_role.allow("catalogue.read")        # browse products
agent_role.allow("availability.read")     # check stock / booking slots
agent_role.allow("order.create")          # place an order on a customer's behalf
# NOT granted — and therefore refused:
#   order.refund, subscription.cancel, customer.read, invoice.read
# Anything not explicitly allowed is denied. Silence means no.

The default-deny posture is the whole game. A least-privilege model means a capability you forgot to think about is simply unavailable to the agent, rather than quietly reachable. When you later decide agents should be able to, say, reschedule a booking, you add exactly that one grant — deliberately, reviewably — instead of discovering after the fact that a broad role already permitted it. Because VBWD’s capabilities toggle as plugins over an agnostic core, an action doesn’t exist as an agent surface at all until you enable the plugin and scope the role; the safe state is the starting state.

The honest limits

Two caveats worth stating plainly. First, a single authoritative pricing engine is the right design, but it does not absolve you of testing: a bug in that one engine now reaches humans and agents alike, so the blast radius of a pricing error is wider even as the risk of divergence disappears. Consolidation trades many small drift risks for one shared correctness responsibility — a good trade, but not a free one. Second, agent-driven commerce is still an early, growing channel, not the bulk of anyone’s revenue today, and the standards around agent actions are maturing month by month. Scope conservatively now; you can always widen a grant, but you cannot un-charge a customer or un-issue a refund an over-broad role allowed. Least privilege is not caution for its own sake — it is the cheapest insurance you will buy. The native-MCP design notes go deeper on where these seams sit. Part 4 turns to the last mile: how the money actually settles once a scoped agent places a real order.

Building toward an agent-callable stack and want a concrete read on your own setup? Request a free assessment and we’ll look at what making your catalogue agent-callable — with one authoritative price and least-privilege actions — would take.