Your next wholesale customer will not have a face. It will be another company's procurement agent — software that discovers your catalogue, checks the price, places the order, and never once loads your product page. Most B2B suppliers are building for a human buyer who is quietly being replaced by a machine. On VBWD you can serve that machine directly: mcp exposes your catalogue as agent-callable tools, shop holds the products and stock, token_payment meters and bills the consumption, non-custodial crypto settles the money, and signed webhooks fire your restock and fulfilment. The whole transaction happens with no human in the loop, and it reconciles as cleanly as if a person had clicked "buy."

Constellation diagram: an MCP capability server over a shop catalogue, with token_payment metering, crypto settlement, and signed webhooks triggering restock and fulfilment for procurement agents

This is the constellation that sounds like next decade and is actually this stack. The reason it works is that VBWD's mcp plugin is not a chatbot bolted onto a store — it is an MCP-native capability server. Capabilities are discoverable and invocable by an agent, which means another company's software can find "check availability," "get price," and "place order" the same way a developer finds an API, and act on them autonomously.

The customer is another company's software

Start from the strange fact and let it reshape everything. In agent-native wholesale there is no cart abandonment, no checkout UX, no pretty product photography, because the buyer is a procurement agent optimizing on availability, price, and lead time. What it needs is a machine-readable contract: a reliable way to discover what you sell, learn the current price for its volume, and commit an order. The mcp plugin provides exactly that surface. It turns platform capabilities into tools an agent discovers and invokes, so a buyer's automation can integrate with your supply without a bespoke EDI project on either side.

The shop plugin sits behind it holding the real substance — products, variants, orders, stock, and shipping. The agent is not talking to a mock; it is transacting against live inventory. When it places an order through MCP, that order draws down real stock and produces a real invoice line item, the same point of truth every other VBWD transaction uses. There is no separate "agent order" ledger to reconcile against your human one, because there is only one ledger.

Metering and credits, because agents buy continuously

Human wholesale is lumpy — a purchase order now and then. Agent wholesale is continuous, high-frequency, and volume-sensitive, and that is where token_payment earns its place. It provides a token/credit economy with metered billing, which maps perfectly onto a buyer that consumes in a steady stream. A procurement agent tops up a credit balance, and every order meters against it; you can price by volume, by tier, or by usage without inventing a billing engine. Metered billing also gives you a natural throttle and a natural trust boundary: an agent can only spend the credits its owner funded, which is a simpler and safer control than trying to reason about an autonomous buyer's intentions.

Because credits and orders are both line items on the same invoice, the accounting stays legible. A finance team on either side can look at one invoice and see what was bought and what it drew down — no separate metering database drifting away from the order history.

Settlement that suits machine-speed trade

Money between companies is where B2B usually slows to a crawl — net-30 terms, wires, reconciliation by hand. VBWD's payment core is provider-agnostic, so you can settle agent-native orders through whatever fits, and non-custodial crypto/stablecoin settlement is a genuinely good match here: funds settle directly to your own merchant wallet, programmatically, without a custodian in the middle holding the float. For a supplier serving software buyers around the clock, settlement that clears at machine speed and lands in a wallet you control removes the human bottleneck that would otherwise defeat the point of automating the order. And if a particular buyer needs cards or a regional rail instead, that is another provider on the same core — adding a gateway is roughly 100× less code than on a classic platform.

Signed webhooks turn an order into an operation

An order the machine placed still has to move atoms in the real world, and this is where the event-driven core pays off. VBWD emits native signed webhooks, so the moment an agent's order lands, your systems react: trigger fulfilment at the warehouse, decrement and reorder stock when it crosses a threshold, notify a 3PL, update a dashboard. The signature matters — because the buyer is software and the trigger is software, you need cryptographic proof that a fulfilment event genuinely came from your platform and was not spoofed. Signed webhooks give downstream systems that assurance without you building an authentication scheme from scratch. The result is a supply chain where discovery, purchase, payment, and fulfilment are one unbroken automated flow, and every hop is an event you can audit.

The boundary: trust is your product, not a toggle

Here is the caveat, and in agent-native commerce it is the whole ballgame. VBWD gives you the discoverable catalogue, the metered billing, the settlement, and the signed events. It does not decide which agents you trust, how you authenticate the company behind an agent, or what limits you place on autonomous spend. When your customer is software, your trust-and-safety model — credential issuance, rate limits, anomaly detection, dispute handling for orders no human reviewed — is the differentiated product you must build. The platform makes each transaction verifiable and reconciled; it does not underwrite the counterparty. Get that model wrong and automation amplifies the mistake. Get it right and you have a supply channel that runs while you sleep.

You also still run the wholesale business itself: sourcing, pricing strategy, inventory, logistics, and the operations of self-hosting the deployment. VBWD is a substrate. It removes the plumbing between "we have inventory" and "another company's agent can buy it," not the work of being a good supplier.

Why it's credible today

Every component of this is a real, shipping capability rather than a roadmap promise. The mcp server is agent-callable now. shop runs live catalogues and stock. token_payment already does metered credit billing. Non-custodial crypto settlement and signed webhooks are part of the core. The platform has already carried verticals as varied as a pharmacy shop, dataset publishing, a dice-market game, and a tarot app — evidence that its seams hold under real load. Agent-native wholesale is not a different platform; it is these switches, aimed at a buyer made of code.

Pull the public SDK from github.com/VBWD-platform/vbwd-sdk-public, read the MCP and webhook guides at vbwd.cc/docs, and if you supply B2B and want to open an agent channel, reach us at vbwd.cc/contact.

VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.