Evaluate DioscHub
Maybe you have a product that already works, with a tested backend, correct permissions, and sensitive data, and adding an AI assistant is the next step. Maybe you’re building something new with an LLM from the start. Either way, you want the assistant to take real actions in your system, such as reading data, calling your APIs, or changing state, without becoming the weakest part of it or giving up the predictable behavior you depend on.
That is the problem DioscHub is built around. This section is one reading path through it, written for an architect or technical lead deciding whether DioscHub fits a specific deployment. Read it in order, in a single sitting of about 45 minutes. Each page describes a mechanism you can check at the boundary.
It is written for three kinds of reader, because DioscHub serves three shapes of deployment:
- An internal or enterprise tool, where the assistant acts as a signed-in user within their own permissions.
- A public assistant (a storefront or support bot) where visitors start anonymous and may sign in later.
- A client-side application, where much of the data and the actions live in the browser.
The path moves from what DioscHub is and why it exists to whether it belongs in your stack:
- What DioscHub is (and isn’t)
- DioscHub in your stack
- What you bring vs. what DioscHub provides
- The security model at the boundary
- A reference deployment
- Limits, and when DioscHub is the wrong choice
- Run a 30-minute proof-of-concept
If you are a developer who wants to start building immediately, skip to Get started instead.