LLM Bots on VBWD: Ship an AI Assistant Grounded in Your Own Content

Build an AI assistant on VBWD that answers from your own catalogue and CMS, rides a privacy-blocked search seam and a shared LLM connection manager, and is metered by the token system.

An AI assistant is only useful if it answers from your content and can’t leak private data; VBWD’s LLM bots are built on two seams that guarantee both.

Your support inbox already has the answers. Your bot doesn’t.

Most “AI assistant” bolt-ons answer from the open web or a generic model. They hallucinate your pricing, invent product names, and quote policies you never wrote. The fix isn’t a bigger model — it’s grounding the model in your own catalogue and CMS content, with a hard boundary around the data it must never read.

VBWD ships an LLM bot as a plugin that does exactly this. It answers from your data, meters what it spends, and never touches user records or invoices. Here’s how it’s built and where it stops.

What an LLM bot on VBWD actually is

VBWD is a self-hosted, source-available platform — Python/Flask, PostgreSQL, Redis, and a Vue 3/TypeScript frontend, all in Docker. The core is intentionally agnostic: it knows nothing about tarot, pharma, or your specific catalogue. Every domain behaviour, including AI, arrives as a plugin that you add without editing the core.

The AI story is a small family of plugins that share machinery. There’s a chat plugin (meinchat) that gives you the conversational UI, a bot variant that adds automated responses, and an LLM-bot variant that wires a real language model into the loop. They aren’t three separate integrations — they ride the same two seams underneath.

The two seams it rides

Every AI feature on VBWD stands on two shared pieces of infrastructure. Understanding them is the difference between a bot you trust in production and one you quietly disable after the first data-leak scare.

1. The search-provider registry. This is how plugins expose readable, searchable slices of your content to anything that needs to read them — the bot included. Your catalogue plugin registers its products; your CMS registers its posts and category pages. When the bot needs context, it queries the registry, not the raw database.

The important part is what the registry refuses to surface. Privacy-sensitive slices — user records, invoices, billing data — are blocked at the seam itself. The block lives in the shared infrastructure, not in each plugin’s good intentions, so a new AI plugin can’t accidentally read customer PII just by forgetting to add a filter. If it isn’t offered through the registry, the bot never sees it. This is the agnostic-core architecture doing load-bearing work: the privacy boundary is structural.

2. The LLM connection manager. This centralises provider selection, credentials, and model configuration in one place. You configure your LLM connection once — which provider, which key, which model — and every AI feature on the platform uses that configuration. Swap providers or rotate a key in a single spot rather than hunting through five plugins. The chat UI, the bot, and the LLM-bot all read the same connection.

How it’s grounded and how it’s metered

Grounding is the whole point. The LLM bot is grounded by reading your catalogue and CMS content through the search seam. When a visitor asks a question, the bot retrieves the relevant products and pages from the registry and answers from that material — from your own data, not from whatever the base model absorbed during training. If a product isn’t in your catalogue, the bot has nothing to invent from, which is the behaviour you want.

Metering is what makes it safe to leave running. AI calls cost money per token, and an ungoverned bot is an open-ended bill. VBWD routes AI usage through its token/credit system, so spend is bounded and billable. You can cap consumption, and because the same system already handles subscriptions and invoicing, AI usage sits inside the accounting you already run rather than in a separate provider dashboard you forget to check.

Those two properties — grounded answers and bounded spend — are what separate a demo from something you put in front of paying customers.

A worked example

Say you run a shop on VBWD and want a bot that answers pre-sales questions on the product pages. The moving parts:

Your shop plugin already registers products with the search-provider registry. No new work — the catalogue is readable through the seam by design.
You configure the LLM connection manager once with your provider and model.
You enable the LLM-bot plugin. It reads product data through the registry, so a question like “does the mid-tier plan include priority support?” is answered from your actual plan definitions.
You set a token/credit budget so a scripted abuse loop can’t run up a five-figure bill overnight.

Then you put it where customers are. The bot embeds as a widget on your pages, so the assistant lives on the product page rather than behind a separate app. When a conversation turns into a qualified lead, you route it out with an outbound webhook — the bot fires the lead into your CRM, Slack, or a spreadsheet without any custom integration code. A visitor’s “how do I get a demo?” becomes a row in your pipeline before your sales team logs in.

Conceptually the wiring is small because the platform did the heavy lifting:

1. shop plugin        -> registers products with the search registry
2. connection manager -> LLM provider + model, configured once
3. llm-bot plugin      -> reads catalogue/CMS via the registry, answers grounded
4. token/credit system -> caps and bills AI spend
5. widget + webhook    -> embed on pages, route qualified leads out

None of these steps involved touching the agnostic core. You added capabilities by enabling and configuring plugins, which is the point of the platform being agnostic in the first place.

Honest limits

A grounded bot is not a correct bot. Retrieval narrows what the model draws on; it does not guarantee the model reads it right. If your CMS content is wrong, contradictory, or stale, the bot will confidently repeat the mistake. Grounding moves the failure mode from “invents facts” to “faithfully reproduces your bad copy” — better, but it makes content quality your responsibility, not the model’s.

The privacy block is a floor, not a strategy. The seam keeps user records and invoices out of reach, which prevents the worst leaks. It does not decide whether a given public product page should be exposed, or whether a draft post is safe to surface. Deciding what belongs in the searchable slice is still your call, plugin by plugin.

Metering bounds cost; it does not tune quality. A tight token budget can truncate context and produce worse answers. You are trading spend against answer richness, and that trade-off is yours to set, not something the platform decides for you.

And the model is still a general LLM. It has the usual failure modes — occasional confident nonsense, sensitivity to how a question is phrased, no genuine understanding of your business. Grounding and metering make it useful and affordable; they do not make it a domain expert. Treat it as a fast first responder that hands off to a human, not as the last word.

Takeaway

An LLM bot on VBWD is not a feature you buy; it’s a plugin you enable on top of two seams that already exist. The search-provider registry decides what the bot can read and structurally blocks what it can’t. The LLM connection manager centralises the model config so every AI feature shares one setup. Grounding comes from your own catalogue and CMS; cost control comes from the token/credit system; distribution comes from the widget and outbound webhooks.

Because it’s all plugins on an agnostic core, you get an assistant grounded in your content without forking the platform or waiting on a vendor’s roadmap — and because it’s source-available under BSL 1.1 (free until 6.7 BTC/yr of attributable sales, then converting to Apache-2.0), you can read exactly how the privacy boundary is enforced before you trust it. The plugin and seam documentation is the place to start when you’re ready to wire your own.