Most "AI sales assistants" are a scripted chatbot in a corner of the page. They can answer, sometimes; they cannot sell, because they cannot touch the order. On VBWD you can build the other thing: an LLM sales manager that knows your catalogue, answers like a person who has read every product page, and can actually place, change, and add to the order — because it acts through MCP against the same invoice your checkout writes to. The salesperson is an agent with write access, not a decorative widget.

Diagram of an e-commerce site with an AI sales manager: shop and cms feeding RAG, bot_meinchat_llm answering in meinchat, mcp giving the agent write access to the invoice, payments settling.

The catalogue it sells from is real, not a prompt

Start with the store. The shop plugin owns products, variants, stock, and orders; the cms plugin owns the surrounding content — guides, comparisons, FAQs, care instructions. Together they are the ground truth. The AISales layer is bot_meinchat_llm, an LLM consultant that runs RAG over exactly that content, delivered inside the meinchat chat surface on your site. When a shopper asks "which of these is fine for sensitive skin and in stock in medium?", the agent is not hallucinating from training data. It is retrieving from your live shop and CMS, so the answer reflects your catalogue and this moment's stock.

Behind the consultant sits VBWD's LLM connection layer, so the model provider is a configured dependency, not something hard-wired into your product. That matters for cost and for control: you can point the RAG at your content without rebuilding the retrieval every time you swap or upgrade a model.

The part everyone else skips: it can act

Answering is table stakes. The non-trivial move is letting the agent do things, safely. VBWD ships mcp — an MCP-native capability server. Capabilities on your platform are discoverable and invocable by an agent, and crucially, the point of truth is the invoice line item. So the sales agent does not need a bespoke, brittle integration to "add item to cart." It invokes a capability that writes a line item to the invoice — the same interface every other plugin uses. Add a product, apply the size the shopper just confirmed, attach a warranty add-on, remove something they changed their mind on: each is a capability call landing on the one invoice that is the source of truth.

This is the sentence that changes the economics of a store: the conversation and the transaction are the same object. There is no "the bot suggested it, now click over to the cart to actually do it" seam where you lose half the shoppers. The agent that persuaded is the agent that transacts.

Guardrails are the whole game

Write access is powerful, which is exactly why the boundaries matter, and VBWD gives you real ones. The core is RBAC-aware and event-driven with native signed webhooks. You decide which capabilities the agent may invoke and which it may not — it can add a line item but you can withhold, say, the capability to issue a refund or override a price floor. Every action the agent takes is an event, so it is observable and auditable rather than a black box. You are composing a constrained set of powers, not handing a language model the keys to the ledger.

Because plugins toggle on and off without a restart, you can pilot the AI sales manager on one product category, watch the invoices and events it generates, and expand only when you trust it — no redeploy, no downtime to dial it back.

Why this constellation is hard to buy

You can bolt a chatbot onto almost any store in an afternoon. What you cannot easily assemble is: RAG grounded in the same database that holds your stock; an agent that transacts through the identical invoice interface as your human checkout; a permission model that scopes what the agent may do; and a payment core that settles whatever the agent built — all in one self-hosted backend that also serves web, iOS, and Android from the same core. The pieces exist elsewhere as four separate vendors you would have to integrate and reconcile. Here they are one substrate, and the invoice is the shared spine that makes the agent's actions real instead of advisory.

The honest boundary

An LLM sales manager is only as good as the content you feed it and the safety model you impose. VBWD gives you the RAG plumbing, the MCP write path, the RBAC scoping, and the audit trail — it does not give you a trustworthy agent for free. You own the prompt design, the escalation-to-human rules, the refusal behaviour, and the monitoring for the day the model says something you would never sign off on. Retrieval grounds the model, but grounding is a reduction of risk, not its elimination; you still test, still watch the events, still keep a human in the loop for the high-stakes actions. VBWD removes the integration burden. It does not remove your responsibility for what your agent says and does to customers.

The public SDK is at github.com/VBWD-platform/vbwd-sdk-public, the MCP and plugin docs are at vbwd.cc/docs, and the team is at vbwd.cc/contact. If an agent that can genuinely close the sale — not just chat about it — is the store you want to build, the write path already exists.

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.