Part 5 of 5. Over four instalments we have built a backend an agent can actually use — a callable MCP surface, a safe machine-readable catalogue, authoritative pricing with scoped actions, and non-custodial settlement. This closing part is about the two things that decide whether any of it earns money: being found and chosen by AI assistants, and being trusted enough to switch on. Neither is a leap of faith. Both are testable.

Becoming discoverable to an assistant

An AI assistant does not browse your site the way a person does. It calls a machine interface, reads whatever structured services you expose, and reasons over the descriptions it finds. Discoverability, in this world, is not SEO — it is clarity of contract. If your catalogue entries, availability, and actions are well-named, unambiguous, and consistently structured, an assistant can map a user’s intent (“book me a 90-minute deep-tissue slot on Friday”) onto a concrete call. If they are vague or inconsistent, the assistant guesses, and a guessing agent is one that quietly routes the sale somewhere it understands better.

Practically, that means writing service and product descriptions for two readers at once: the human and the model. Say what a thing is, what it costs, and what an agent may do with it, in plain terms, with the same fields on every record. Because a VBWD platform exposes an MCP endpoint natively — a single server plugin at POST /api/v1/mcp that you toggle on without a restart — the discoverable surface is the same catalogue and pricing engine your human checkout uses. There is no separate “agent feed” to keep in sync, and therefore no drift between what the assistant is told and what it will actually be charged.

Testing an agent flow end to end

Before you expose anything publicly, simulate a full assistant transaction against your own stack and watch every hop. A realistic end-to-end test walks the same path an external agent would:

• Discover and read the catalogue. Query the MCP surface for services and availability. Confirm you get clean, structured results — and, just as important, confirm the search seam refuses the queries it should. Ask it for a customer account or an invoice and verify it returns nothing. The seam is designed to expose catalogue and availability while withholding user PII and financial records; you should be able to prove that refusal, not assume it.
• Price the selection. Fetch the price for a chosen item and reconcile it against a human checkout for the same item. They must match to the cent, because they come from one pricing engine. A mismatch here is a bug you want to find in a test, not in a dispute.
• Attempt a scoped action. Have the simulated agent try both a permitted action (create a booking you explicitly allowed) and a forbidden one (cancel someone else’s order, mutate a price). RBAC and access levels should let the first through and reject the second. Test the “no” as deliberately as the “yes”.
• Settle. Run the payment through to your merchant wallet via the non-custodial path and confirm funds arrive where they should, with the platform never holding them in between.

Keep this walkthrough as a repeatable test, not a one-off ceremony. It is the single most useful artefact you will own, because it exercises discoverability, safety, pricing truth, authorisation, and money movement in the exact order a real assistant will.

Honest limits

Be clear-eyed about what you are switching on. Agent-driven commerce is a real but early channel — for almost everyone it is a growing slice of revenue today, not the majority, and you should size the investment accordingly. The standards underneath it, MCP included, are still maturing; interfaces and conventions will shift, and you will revisit assumptions. And every capability you expose to an agent is a security surface: an interface designed to be called by software you do not control. VBWD’s defaults lean toward least exposure — the seam withholds sensitive records, actions are scoped by RBAC — but the responsibility to expose only what you intend stays with you. It is also fair to say VBWD is younger than 20-year incumbents; you are trading some accumulated edge-case maturity for a modern, auditable, self-hosted architecture. For many teams that is the better trade. For some it isn’t. Decide honestly.

Going live in stages

Do not flip everything on at once. Roll out in three phases and let each earn the next:

• Read-only first. Expose catalogue and availability through the MCP surface, nothing more. Let assistants discover and quote you while you monitor real traffic. The blast radius is essentially zero.
• Scoped actions next. Once reads are clean, enable a narrow set of actions — say, creating a booking — governed by access levels. Watch how agents use them and tighten scopes.
• Settlement last. Turn on the payment path only when reads and actions have proven stable, so money moves along a surface you already trust. Then expand deliberately, one capability at a time.

Because capabilities in VBWD toggle without a restart, this staging is a matter of configuration, not re-architecture — you widen the aperture as your confidence grows and narrow it instantly if something looks wrong. That reference implementation is open to inspect, and the native-MCP design is written up in more depth in this piece on making a platform agent-callable.

That is the arc of the series: a callable backend (Part 1), a safe catalogue (Part 2), authoritative pricing and scoped actions (Part 3), settlement to your own wallet (Part 4), and now discovery, testing, and a staged go-live. The next step is not more reading — it is running that end-to-end walkthrough against your own stack, read-only, and seeing what an assistant makes of your services.

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 — safely — would take.