Core concepts
This page relates the core pieces of DioscHub at the boundary. The glossary gives the one-line version of each term.
What runs where
Section titled “What runs where”DioscHub runs as two parts. A durable backend engine holds the conversation, calls your tools, and talks to your LLM provider. A short-lived browser counterpart, the chat widget, lives in the page, reads the context the user is in, and runs in-page actions such as navigation. The backend part outlives any one page; the browser part exists only while the page is open.
Assistant, Role, Session
Section titled “Assistant, Role, Session”- An Assistant is the configured AI entity a user talks to. You define it in the admin portal: its name, its knowledge base, its model configuration (provider, model, limits), and one or more Roles.
- A Role is a way of using an Assistant. It carries the tools the assistant may call, the system prompt, the model budget, and feature flags. The same Assistant behaves differently across Roles, so capability is sized to who is using it. Auth is not on the Role; it arrives per connection from your backend (see identity).
- A Session binds one user to one Assistant, within a domain, for the life of a conversation. The Session carries the user’s identity, so every tool call the assistant makes acts as that user.
Tools: MCP server, instance, tool, Toolset
Section titled “Tools: MCP server, instance, tool, Toolset”You connect a system by wrapping it as an MCP server, a thin adapter over an API you already run, speaking the Model Context Protocol. Registering and configuring that server inside DioscHub makes it an MCP instance. Each callable the server exposes is an MCP tool. A Toolset groups tools so an admin can assign them to Roles together. The assistant reaches your systems only through these tools; it holds no connection to your databases.
Identity and the credential path
Section titled “Identity and the credential path”DioscHub runs no auth system of its own; it carries yours. This is Bring Your Own Auth: your backend binds the signed-in user’s identity and auth artifact to the connection, and DioscHub forwards that artifact to your MCP servers unchanged, so each tool call is authorized as the real user. The artifact is forwarded around the model, never placed in its context. This is the Credential Blind guarantee. The security model traces the full path.
Consensus, the approval flow
Section titled “Consensus, the approval flow”A state-changing tool can be gated by an approval flow. When the assistant proposes a gated action, it pauses and shows the user the tool and the parameters; the user approves, edits the parameters, or rejects, and only an approved call runs. The gate is configured on the MCP instance, so it applies to every Role that can reach the tool. This is how the user stays responsible for actions taken in their name.
Knowledge base
Section titled “Knowledge base”A knowledge base is a set of documents you load so the assistant can answer from your content. The assistant retrieves the relevant passages when it needs them, rather than being handed whole files.
Anonymous sessions
Section titled “Anonymous sessions”A Session can start anonymous (no signed-in user) for a public assistant, with a limited, guarded surface. When the visitor signs in, the same Session is promoted in place: the conversation continues, now acting as the authenticated user.
Next: Glossary, every term above, in one line.