The MITHUNAI platform
One AI platform, its products, and one account under them
MITHUNAI is an AI platform with named products on one account and one organisation boundary. RAG, Chat and the Gateway are live, and three more are in beta. They share the knowledge you connect, the people you invite and the keys you issue.
Last updated
Every MITHUNAI product, on one account
MITHUNAI is a family of products on one platform: one account, one organisation boundary and one body of knowledge underneath all of them. They are not equally far along, and each one says where it stands. Signing in once and signing out once across every product is in beta.
MITHUNAI RAG
Live
For support, documentation and developer teams
app.mithunai.comConnect your documentation, repositories, help centres and files, and answer questions from them with citations, or a plain "I don't know" when the sources do not support an answer. Put it on your site with the Ask AI widget, call it over the HTTP API, or reach it from your editor through read-only MCP tools. Coverage gaps, Top questions and source analytics show what people ask and what is missing.
Limit: It is also at its own address, rag.mithunai.com, in Beta.
MITHUNAI Chat
Live
For everyone in your organisation who wants to ask, draft and summarise
chat.mithunai.comA chat workspace with threads, saved prompts, bookmarks and file attachments. Every thread can search your knowledge and ask your assistants for a cited answer, and its model calls go through MITHUNAI Gateway.
MITHUNAI Gateway
Live
For platform teams that manage model providers
gateway.mithunai.comOne OpenAI-compatible endpoint in front of your model providers, with provider keys in an encrypted vault, routing and failover, and per-key usage and budgets for the traffic that goes through it. Chat sends its model calls through it; the RAG answer engine and Agents call providers with their own credentials.
Limit: It admits platform administrators, and an organisation’s owners and administrators where a deployment allows it.
MITHUNAI AI search visibility
Beta. Not yet run against a real AI search engine.
For marketing teams
Asks AI search engines the questions your buyers ask, with their own web search, and records whether they name you or a competitor and which pages they cite.
Limit: Off by default; no provider key is configured for any deployment yet.
MITHUNAI Agents
Beta. Access on request.
For teams that want work done over several steps
agents.mithunai.comAgents that plan over several steps and call tools. It runs behind sign-in, in beta, with access on request.
MITHUNAI Team
Beta. Access on request.
For support, IT, DevOps, marketing, sales and finance teams
AI employees for Support, IT service desk, DevOps, Marketer, Sales and Finance work. Each one proposes what to do, a person approves, edits or rejects it, and every step is recorded.
Limit: Beta. Access on request. It is built and tested against stand-ins, the tool connections it would use have not yet been tried against a real account, and its address will be team.mithunai.com.
The MITHUNAI platform
Underneath every product
For the administrators who run your organisation
One account works across the products. Invite colleagues, change a member’s role, remove a member or hand over ownership, and see your organisation’s monthly answer allowance as “X of Y answers used this month”. Each customer’s data stays inside its own organisation.
Limit: Signing in once and signing out once across every product is in beta; e-mailed invitations are in beta: a real invitation has not yet been tried.
What an AI Knowledge Engine should be.
MITHUNAI covers the path from your sources to a cited answer: ingestion of your documentation, retrieval, grounded answers that say when they do not know, and one customer’s data never reaching another.
Checkable Citations with Honest Abstention
Every answer produced by MITHUNAI is constructed directly from retrieved knowledge passages. If evidence is absent, the engine honestly declines to answer rather than hallucinating plausible text.
MITHUNAI streaming runnerOrganizationScope. Requests that cross or cannot name their organisation are refused rather than run broadly.One Model Layer for Completions and Embeddings
Every model call the answer engine makes goes through one model layer, which talks directly to Anthropic, OpenAI and Gemini with the credentials your deployment configures. Each assistant picks its model from the deployment's catalogue.
Connect GitHub, Websites, Sitemaps and Files
Connect a GitHub repository, crawl a website on its own origin, follow a sitemap, or upload files. Ingestion runs as a background job, and you re-sync a source by hand or on a schedule your operator sets.
Model Context Protocol (MCP) and REST APIs
Connect your IDE to your knowledge base through the remote MCP server, in beta, or call the HTTP API from any language. Both authenticate with the same API key.
{
"mcpServers": {
"mithunai": {
"url": "https://app.mithunai.com/mithunai/api/v1/mcp",
"headers": {
"Authorization": "Bearer mithunai_sk_..."
}
}
}
}Authenticated Perimeter & Strict Multi-Tenancy
Tenant isolation is not an optional filter. It is an enforced query-time invariant. Every vector query requires a signed-in caller whose organisation is known, and is refused closed if omitted.
Embed Grounded Chat with Zero Code Forking
Embed an intelligent chat assistant on your marketing site or authenticated portal. Enforce domain origin allowlists so only authorized websites can load your assistant.
<!-- Paste before </body> -->
<script>
window.mithunaiWidget = {
apiBaseUrl: "https://app.mithunai.com/mithunai/api/v1",
widgetKey: "mithunai_wk_...",
}
</script>
<script src="https://app.mithunai.com/widget/mithunai-widget.js" defer></script>mithunai-core // product-architecture-explorerOne OpenAI-compatible endpoint in front of the providers you register. Provider keys sit in an encrypted vault, a failed call falls back to another configured model, and usage is attributed to the key that spent it.
A client sends a completion request with one gateway key
Reads the provider key from the vault and checks the calling key’s budget
Sends the call to the model asked for, and to another configured one if it fails
Records prompt and completion tokens against the key that made the call
POST https://gateway.mithunai.com/v1/chat/completions
Authorization: Bearer $GATEWAY_API_KEY
Content-Type: application/json
{
"model": "$MODEL",
"messages": [{"role": "user", "content": "Summarise this change log."}],
"stream": true
}
// $MODEL is a model your gateway lists at GET /v1/models.
// 200 OK, streamed as OpenAI-format chunks:
data: {"choices":[{"delta":{"content":"..."}}]}GitHub, websites, sitemaps, and document files.
Self-hosted deployments send no telemetry by default.
Per-tenant names, logos and colours without forks.
Website widget, HTTP API, and read-only MCP.
Organisations, people and keys
Underneath the assistant is the part that makes it operable by a company rather than by one person: organisations, the people and services in them, what each may do, and what it has been used for.
One organisation, many members
A deployment carries many organisations. The one a request acts in is derived from the authenticated principal. An organisation identifier supplied by a caller is never the basis for a decision.
Signing in grants nothing on its own
Knowing who someone is and deciding what they may do are separate steps, and the second one happens where the action does, never in the interface alone.
Roles carry permissions, requests carry scope
Permissions come from the role held in an organisation, and ownership of the specific resource is checked alongside them, not instead of them.
API keys are principals, not bypasses
A key authenticates as a service principal with its own membership and role. Only a hash is stored, the secret is shown once, and revoking a key takes effect on its next request.
Every caller is a principal, human or not
A person, a service key and a widget visitor are all principals with a type, and whether the actor was human is recorded rather than guessed from a missing user id.
Colleagues join by invitation
An administrator invites a colleague by e-mail with a single-use link that expires after seven days, and anyone can reset a forgotten password with a link that lasts thirty minutes and ends every session when it is used.
Limit: In beta: a test e-mail has arrived, and a real invitation has not yet been tried.
Change a role, remove a member, or hand over ownership
Raise or lower a member’s role, or remove them. Removal ends their sessions and revokes the API keys they created and the invitations they sent. Nobody can act on their own seat or on someone senior to them, and the owner’s seat moves only when the owner hands it to an active member, who becomes owner as the previous one becomes an administrator.
A monthly answer allowance
Each organisation has a monthly allowance of answers, counted the same way on the console, the widget, the API and MCP. The Dashboard shows it as “X of Y answers used this month”, and a question past the allowance is refused before any model is called.
Limit: It caps answers, not spend, and nothing bills for usage yet.
See what it is being used for
Volume and answer-quality counts for your own organisation, broken down by model and by channel, and filterable to a single assistant. Counts only: no shape in the package can carry message content.
Top questions, and the gaps behind them
Top questions lists what people ask most and never who asked: a question appears only once three different people have asked it. Coverage gaps groups the questions an assistant declined by meaning as well as by wording, so the paraphrases of one question count together.
Limit: The similarity threshold for grouping by meaning is not yet tuned on live questions, and Top questions reads the newest 2,000 questions of a period.
Boundaries that are enforced, not documented
The platform is built as layered modules with a dependency rule that a linter checks on every change. The foundation layer imports nothing from the layers above it, so the platform core cannot come to depend on the features built on top of it.
The module dependency rule
Each layer may depend only on those listed beside it. The foundation depends on nothing.
experiencedepends onplatform, knowledge, ai, agents, workflowworkflowdepends onplatform, ai, knowledge, agentsagentsdepends onplatform, ai, knowledgeknowledgedepends onplatform, aiaidepends onplatformplatformdepends onnothing
Checked by a linter
The import rule is machine-enforced in continuous integration, not left to review.
Every capability has an API
Each capability is reachable by a client other than our own interface, so the platform is integrable rather than a closed application.
The transport holds no logic
The HTTP layer parses, calls the module that owns the capability, and serialises. There is no behaviour in it that a reviewer would have to find twice.
Deployable where your data has to live
The platform runs as a containerised deployment, so it can be operated in an environment you control rather than only as a hosted service.
Questions about the platform
Grounded answers from your own knowledge, a chat workspace for your team and one model gateway, on one account.
A 30-minute walkthrough on your own use case: connect a source, ask it questions, check the citations and see what it does when the answer is not there. Or ask the public playground now, with no account.