When a platform grows an on-site chat bot, an LLM-powered assistant, and an MCP server for AI agents, the naive outcome is three separate integrations — each with its own way of reaching your data, its own LLM wiring, and its own security decisions to get wrong three times. VBWD builds all of them on the same two seams: one for reading your content safely, one for talking to language models. This post is about that design choice — why these features are the same problem wearing different interfaces, and what you get by refusing to solve it three times.
Look past the surface and a chat bot, an LLM assistant, and an MCP server want the same two things. They all need to read some slice of your application's content — to answer a question, an assistant has to find the relevant products, datasets, or pages. And they all need to call a language model — to turn that content and the user's question into a useful reply. A sales bot on your website, an autonomous agent connected over MCP, and an in-product AI helper differ in how the user reaches them, not in what they fundamentally do.
If those two needs are met by two shared seams, then each new AI feature is a thin adapter over solved problems. If they are not, each feature re-implements reading and LLM-calling, and every re-implementation is a fresh chance to leak private data or misconfigure a model. VBWD chose the first path deliberately.
The first seam is a neutral registry through which plugins expose readable and searchable slices of their data. A plugin that owns products, or datasets, or CMS pages registers a search provider; anything that needs to read across the platform queries the registry rather than reaching into individual models. Crucially, the seam is where privacy is enforced: sensitive slices — user records, invoices — are blocked at the registry, so a general read surface built on top of it cannot casually expose personal data.
This is the single most important reason to share the seam. Data-access safety is exactly the kind of thing you want to get right once, in one place, and then inherit everywhere. Every feature that reads through the registry gets the same privacy floor for free. If each bot queried models directly, each would need its own correct answer to "what am I allowed to expose?" — and the one that got it wrong would be a breach. Sharing the seam means there is one answer, and it is enforced structurally.
The second seam is the platform's LLM connection manager — the component that owns how the system talks to language-model providers: which provider, which credentials, which model, with what configuration. Any feature that needs a completion asks the connection manager rather than embedding its own provider client and API key handling.
The payoff mirrors the first seam. LLM configuration — provider choice, credentials, model selection — is centralised, so you configure it once and every AI feature uses it. Switch providers or rotate a key in one place and the bot, the assistant, and the MCP server's LLM tool all follow. Without this, each feature would carry its own provider wiring, and "we changed LLM provider" would be a three-file migration with three chances to leave a stale key behind.
With those two seams in place, the AI features become small:
Three different front doors — a website widget, an MCP endpoint for agents, an in-app helper — all opening onto the same two rooms. The differences between them are genuinely about the interface: who calls them and how. The substance — read safely, call the model — is shared.
This design is not a coincidence; it is what the platform's core discipline produces. The core does not know what a "sales bot" is — that would be domain knowledge, forbidden in an agnostic core. What the core provides is general mechanism: a registry for readable slices, a manager for LLM connections. The bots, the LLM assistant, and the MCP server are plugins that compose that mechanism into specific meaning. The core stays ignorant of every AI feature; the features reach the core only through the seams it published.
That is why adding the next AI feature is cheap. The seams already exist and already encode the hard parts — the privacy floor, the provider configuration. A new feature is an adapter, not a re-derivation. The core is untouched, so nothing about a new bot can destabilise the platform. The economics of "the second one is nearly free" come directly from having refused to let the first one embed its own reading and LLM-calling.
Beyond elegance, sharing the seams is what keeps operating these features sane. There is one place to reason about what AI features can read, and it enforces the privacy blocks uniformly — so a security review asks one question, not three. There is one place to configure and rotate LLM credentials, so a provider change or a leaked key is a single, contained action. And metering composes too: because model calls flow through the connection manager and the platform has a token system, you can bound and bill AI usage consistently rather than instrumenting each feature separately. Consolidation turns three ongoing operational burdens into one.
Shared seams are a strength and a constraint. The privacy floor at the search registry is exactly that — a floor: it blocks the obviously sensitive slices, but whether a specific configured tool over-exposes something for your data is still your review to do before enabling a bot or the MCP server. Centralising LLM configuration means a misconfiguration or an outage at the connection manager affects every AI feature at once — a single point worth monitoring precisely because everything depends on it. And sharing seams couples the features to the seams' capabilities: a feature that needs something the registry does not expose has to extend the seam (the disciplined path) rather than reach around it, which is more work up front than a quick direct query. That trade — a little more rigour at the seam in exchange for solving reading and LLM-calling once — is the whole bet.
A chat bot, an LLM assistant, and an MCP server look like three features but are one problem twice-disguised: read a slice of your content safely, and call a language model. VBWD meets both needs with two shared seams — a search-provider registry that enforces the privacy floor once, and an LLM connection manager that centralises provider configuration once. Every AI feature composes those seams instead of re-implementing them, which is why the privacy story is uniform, the LLM configuration is single-sourced, and the next AI feature is nearly free. It is the agnostic-core rule cashing out: general mechanism in core, specific meaning in plugins, and no hard problem solved more than once.
Configure the LLM connection once, confirm which slices your search providers expose, and every AI feature — bot, assistant, MCP — inherits both.