Admin configuration
The code you write — the embedded widget, your MCP servers, and the bind endpoint — connects DioscHub to your systems. Admin configuration is where you decide what the assistant actually is: what it knows, which tools it can reach, which model runs the conversation, and what it must ask permission to do. You do this in the admin portal (or over the admin API), not in code.
Assistants & Roles An Assistant is the conversation your users see; its Roles decide, per user, which tools and knowledge that conversation can reach.
MCP servers & Toolsets Register your MCP servers, then group their tools into Toolsets so the assistant can load a large catalog by area of work.
Models Register your LLM providers once, then choose which model — and how it reasons — each Assistant runs on.
Knowledge bases Give an Assistant documents to search, so it answers from your content instead of guessing.
Approval policies Choose which tools the assistant must stop and ask about before it runs them.
Model routing (Pro) Route each turn across a set of models, with a resilience fallback when one fails.
Next: Assistants & Roles.