DioscHub in your stack

DioscHub sits in the middle of things you already own: your frontend, your backend and auth, your business systems (wrapped as MCP servers), and your LLM provider. It owns the conversation and the tool-calling between them. It owns none of those.

Here is the whole picture at the boundary. Everything in this evaluation refers back to it.

DioscHub at the boundary of your stack. Your frontend (the <diosc-chat> web component with an embed key and diosc()) sends a connection id to your backend (your auth and session) and opens a WebSocket to DioscHub. Your backend makes a server-to-server bind, passing identity and auth artifacts. DioscHub — self-hosted and single-tenant, running Assistant, Role, Session, Knowledge base and Approval — calls your LLM provider (OpenAI, Anthropic, Azure) with your API key, and forwards the bound user's auth opaquely, per tool call, to your MCP servers. Each MCP server wraps one of your systems, such as your ticketing API and your billing API.

What crosses each line

Frontend → DioscHub. Your page loads the diosc-chat web component with a public embed key and opens a WebSocket; chat messages and events flow over it. The embed key identifies which Assistant to load, not who the user is. This is the browser twin: besides rendering the chat, it can read the context the user is in and run in-page actions (navigation, or client-side tools you define).
Frontend → your backend → DioscHub (the bind). Identity is not carried by the browser. The widget hands your backend a connection id; your backend, which already holds the user’s session, makes a server-to-server call to DioscHub binding that user’s identity and auth artifacts to the connection. From then on, the Session over that connection acts as the signed-in user. The user’s real credentials never pass through the page. (For a public assistant, the bind is anonymous until the user signs in, then promoted in place.)
DioscHub → your LLM provider. DioscHub calls the model with your provider API key, configured once in the admin portal. You bring the provider; DioscHub orchestrates the calls.
DioscHub → your MCP servers. When the assistant calls a tool, DioscHub forwards the bound user’s auth to the MCP server that owns that tool, opaquely and unchanged. The server authorizes the call against your own system, as that user. DioscHub does not interpret the credential; it carries it.
MCP server → your system. Your MCP server is a thin wrapper you write around an existing API. It is where your authorization lives. DioscHub never reaches your system directly.

The vocabulary, named once

These terms recur through the rest of the docs. They are defined in the glossary; here is the one-line version of each.

Assistant: the configured AI entity a user talks to. It has one or more Roles.
Role: carries the tools, system prompt, model budget, and feature flags for a way of using the Assistant. (Auth is not on the Role; it arrives per connection from your backend.)
Session: binds one user to one Assistant within a domain for the life of a conversation.
MCP server: your wrapper around a business system. MCP instance: a registered, configured MCP server inside DioscHub. MCP tool: one callable the server exposes.
Knowledge base: documents you load so the assistant can answer from your content.
Embed key: the public credential your frontend uses to load an Assistant.
Approval flow: the consensus step that gates a state-changing tool.

Next: What you bring vs. what DioscHub provides, drawing the responsibility line explicitly.