Part 1 of 5 — a technical series on building agentic commerce on a self-hosted stack.

The buyer who never sees your homepage

For twenty years, “the storefront” meant a rendered page: a human opened a browser, scanned a grid of products, clicked, and paid. Every optimisation we learned — hero images, above-the-fold copy, funnel analytics — assumed a person looking at pixels. That assumption is quietly breaking. A growing share of purchases now begins with an AI agent acting on someone’s behalf. The agent never renders your frontend. It does not see your hero image or your carefully tuned checkout flow. It calls a machine interface, reads structured data, decides, and — increasingly — acts.

This is not a prediction about a distant future so much as a description of an early, real, and expanding channel. When a buyer asks an assistant to “find me a booking for four next Friday under this budget and reserve it,” the assistant does not browse. It looks for a callable surface it can query. If your platform exposes one, you are a candidate. If it doesn’t, you are invisible to that buyer — not because your product lost, but because your product was never legible to the thing making the decision.

What “agent-callable” actually means

Being agent-callable is more specific than “having an API.” A REST API built for your own frontend is shaped around your screens; it leaks internal assumptions and often requires a human-mediated auth dance. An agent-callable surface is one an autonomous client can discover, understand, and use safely without a person in the loop for every step. In practice that means three things: a described interface the agent can introspect (what can I ask? what can I do?), reads that return clean structured data rather than markup, and actions that are explicitly scoped so the agent can only do what you intended to allow.

The emerging lingua franca for this is MCP — the Model Context Protocol — a way to expose tools and data to an AI client through one predictable endpoint. Instead of writing a bespoke integration for every assistant, you expose one MCP surface and any compliant agent can call it. That is why the MCP surface is starting to look less like a developer convenience and more like a sales channel: it is the doorway through which agent-originated demand arrives. Treating it as an afterthought is the modern equivalent of having no mobile site in 2010.

The architecture this series builds

Exposing a backend to autonomous callers sounds alarming, and it should — done carelessly, it is a data-leak and fraud surface waiting to happen. The rest of this series is about doing it deliberately. The reference implementation throughout is VBWD, a self-hosted, source-available full-stack SDK: one Python core with Vue/TypeScript web plus native iOS and Android, all served from a single backend. Its core is intentionally agnostic; capabilities — payments, subscriptions, catalogue, CMS, booking, chat, and MCP itself — are plugins that toggle on and off without a restart. MCP is native to the core: enabling the server plugin exposes an endpoint at POST /api/v1/mcp, and a platform built on it becomes agent-callable out of the box. You can read the design rationale in MCP is native to VBWD and the channel argument in In the agent era, MCP is your sales channel.

Four pillars carry the weight, and each gets its own instalment. First, a safe, machine-readable catalogue: agent reads ride a core “search seam” — a search-provider registry designed to refuse to expose sensitive records, so catalogue and availability are readable while customer accounts and invoices are not. Part 2 covers modelling data for machine consumers with least-exposure as the default. Second, authoritative pricing: the price an agent sees is produced by the same pricing engine as human checkout, not a stale side-feed — the subject of Part 3, alongside how access levels and RBAC scope what an agent may do versus merely read. Third, settlement: Part 4 looks at provider-agnostic payment adapters and non-custodial crypto/stablecoin settlement, where funds land in the merchant’s own wallet via a watch-only xpub and the platform never custodies money. Finally, Part 5 turns to discoverability, end-to-end testing, and a staged rollout — being found and chosen by assistants without betting the business on an immature channel.

An honest word on limits

Agent-driven commerce is a growing channel, not the majority of anyone’s revenue today. The standards around MCP and agent interoperability are still maturing, and they will move under your feet for a while yet. VBWD itself is younger than the twenty-year incumbents; it trades their accumulated edge-case maturity for a modern, auditable, sovereign architecture — for many builders the better trade, for some not. And every surface you open to an agent is a security surface. The correct posture is not enthusiasm but discipline: expose the minimum, default to least exposure, and treat “an agent can do this” as a decision you make explicitly rather than a side effect. The rest of this series is essentially an argument for building that discipline into the architecture instead of bolting it on later.

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.