What you bring vs. what DioscHub provides

DioscHub is deliberately incomplete. It does not try to be your auth system, your model, or your business logic. It connects the ones you already have. That keeps the trust boundary small, and it gives the integration a clear list of things you own. Here is that list, so you can scope the work before you commit.

The responsibility split

You bring	DioscHub provides
Your frontend, the page or app that embeds the chat	The diosc-chat web component and the diosc() command API to drive it
Your backend + auth system, however your users sign in today	The bind contract that carries your auth opaquely to your tools; it holds no auth of its own
Your business systems, such as ticketing, CRM, billing, and internal tools	The MCP integration layer that registers, loads, and calls your MCP servers’ tools
Your MCP servers, thin wrappers you write around those systems	The contract those servers satisfy, plus auth-forwarding, consensus gating, and server-side file access
Your LLM provider + API key	The assistant runtime that orchestrates the model and tool calls; per-assistant model selection
Your content, documents for the assistant to answer from	Knowledge base management and retrieval-augmented answers
Your infrastructure, somewhere to run a container and a database	The published image, the admin portal, session/role management, token accounting and quotas

Optionally, for a client-side application, you also bring the client-side tools the assistant runs in the browser against your in-page data; DioscHub provides the channel that lets the model call them.

What this means in practice

The integration work is concentrated in two places:

1. Your frontend embeds the widget, and your backend exposes a bind endpoint. For a typical app this is a component plus one server-to-server endpoint that hands DioscHub the user’s identity and auth. See the embed quickstart and the Identity & auth guide. (A public, anonymous assistant can start without the bind and add it only when users sign in.)
2. Your MCP servers expose the tools the assistant may call and expect the forwarded auth. If you have never written an MCP server, the MCP tool quickstart is the shortest path; the Build pillar covers the full contract.

Everything else, including the assistant model, roles, sessions, approval flow, knowledge base, and admin portal, is configuration, not code. You set it up in the admin portal and through the deployment’s config, not by writing application logic.

Note

You also bring your secrets and hardening posture. DioscHub is self-hosted, so the operational security of the deployment, including database credentials, the credential master keys that encrypt provider keys at rest, and restricting where the widget may be embedded, is yours to set. The production hardening checklist states each requirement explicitly.

---

Next: The security model at the boundary, the credential’s path, and the systems DioscHub deliberately cannot reach.