What is available, in beta and planned

Capabilities below carry one of three statuses, and a row that needs more than one word says so.

Available means finished and supported.
Beta means a feature that is still new and still being worked on. It may change based on feedback, and any note about what has not yet been proven stays beside it. Some beta features are switched off by default or given on request, and their row says which. Tell your MITHUNAI contact before relying on a beta feature for a high-traffic launch.
Planned means it is not built, and nothing here describes a planned feature as though it were available.

Knowledge sources

Capability	Status
Website crawl, sitemap and GitHub repository sources	Available
PDF, Word, Markdown and text file uploads	Available
OpenAPI and Swagger schemas, and custom answers you write yourself	Available
Public Zendesk help centres and public Discourse forums	Available
GitHub issues and pull requests	Available
GitHub discussions	Beta
Editing, renaming, pausing and resuming a source	Available
Background ingestion with progress and cancellation	Available
Secret redaction and bounded fetching	Available
Scheduled automatic re-sync	Beta. A deployment setting, off by default. One interval for every source; no per-source schedule, and not set from the console. Ask your MITHUNAI contact whether it is on
Saved connections: your organisation’s own token for GitHub, Confluence or Notion, stored encrypted and shown to nobody	Available
Private GitHub repositories, read with a saved connection	Beta. Not yet run against a real private repository
Confluence Cloud and Notion, read with a saved connection	Beta. Tested against scripted responses written from each service’s documentation, not yet against a real site or workspace. Confluence Cloud only: no Data Center or custom domain
Jira Cloud issues, Jira Service Management requests and Zendesk solved tickets, read with a saved connection	Beta. Built against recorded responses, not yet run against a real account. Only public replies are read from service-desk requests and tickets; Jira attachments, work logs, history and links are not read
Source permissions: answer each person only from what they can read in the source	Beta. Built, not yet available: needs a database change that has not been released. GitHub repositories only. See Source permissions
Other sources that need a sign-in: Slack, Discord, S3, Google Drive, Salesforce, private help centres and forums	Planned
YouTube as a source	Planned

Answers and assistants

Capability	Status
Grounded answers with citations	Available
Abstention when content does not support an answer	Available
Streaming answers	Available
Conversations that keep their history across turns	Available
Hybrid retrieval: semantic search combined with keyword matching of exact terms	Available
Multiple assistants per organisation, each with its own knowledge, model and guidance	Available
Copying an answer, rating it helpful or not, and suggested follow-up questions in the Playground	Available
Tools that let an assistant act in other systems	Planned

Deploy

Capability	Status
Console	Available
HTTP API, with API keys that each hold a role	Available
Website widget, installed with one line	Available
The three-step Add Ask AI to your website setup, with Check my website	Available
Widget host-page API and events, a conversation kept within the tab, copying and rating answers	Available
Widget greeting, example questions and colours stored per embed, and follow-up suggestions in the widget	Planned
MCP server (three read-only tools)	Beta
Answering in Slack: mention the bot or message it, and it replies in the thread with numbered sources	Beta. Available once your deployment’s operator registers the Slack app; not yet run against a real Slack workspace
Answering in Microsoft Teams: a personal chat or a mention, and it replies with numbered sources	Beta. Access on request. Available once your deployment’s operator registers the bot; not yet run against a real Teams tenant
Deciding an AI employee’s approval from a card in Slack or Teams, as the person the account is linked to	Beta, switched off by default. Access on request. Not yet run against a real workspace or tenant
Storing an embed’s presentation, chat bubble or docked sidebar, for pages whose snippet sets no mode	Beta, switched off by default. Access on request
Connecting MITHUNAI to external MCP servers	Planned
Webhooks	Planned

Analyze

Capability	Status
Usage report on the Dashboard	Available
Conversations, read-only	Available
Coverage gaps: declined questions and answers rated unhelpful	Available
Proposed answers: a coverage gap drafted as an answer from your own sources, which a person reviews and publishes	Beta
Grouping similar coverage gaps, by meaning and by wording	Beta. The match between questions is not yet checked against production embedding models. Falls back to wording, and says so, when grouping by meaning is unavailable
Source analytics, with CSV export	Available
Answer quality evals: score an assistant against a question set, in the console or in CI	Beta. Scored by comparing text with the cited passages, never by a model
Kept eval sets and runs, with each run’s pass rate	Beta, switched off by default. Access on request
Top questions: what people ask most, never who asked, with CSV export	Beta. A question is listed only once three different people have asked it
AI search visibility	Beta, switched off by default. Built and tested, not yet run against a real AI search engine
AI search visibility: propose a fix for a gap, as a GitHub pull request or a WordPress draft a person approves	Beta, switched off by default. Built and tested, not yet run against a real repository or site
Per-user analytics: what one person asked	Not offered
Cost reporting	Planned

Administration

Capability	Status
Organisations, roles and data isolation	Available
Listing members, changing a member’s role and removing a member	Available. Changes need a signed-in console session, not an API key
Inviting a colleague by email	Beta. Needs your deployment to send email, which is off until its operator sets up a mail provider. A test message has arrived in a real inbox; the invitation message itself has not yet been tried with a real address
Resetting a forgotten password from the sign-in screen	Beta. Needs email, as above; until then the operator sets passwords
Organisation branding and white-label, for the console and the widget	Available
Support access you control: off by default, read-only, time-limited	Available
Transferring ownership of an organisation to another member	Available. The Owner does it; it needs a signed-in session, never an API key
Requesting access for a new company, approved by MITHUNAI	Beta. A test message has arrived in a real inbox; the emails this flow sends have not yet been tried with a real address
Self-service sign-up, and changing your password while signed in	Planned
Signing in with your own identity provider (Okta, Entra ID, SAML), and SCIM	Planned
A monthly answer allowance per organisation, shown on the Dashboard	Available
Spend caps, plans and billing	Planned
Customer-facing audit log export, as CSV or JSON Lines	Beta. Owners and admins, in Settings → Audit log

Other MITHUNAI products

MITHUNAI RAG is the product most of this page describes. The other MITHUNAI products share its account and organisation, and their statuses differ in ways worth planning around.

Capability	Status
Chat, with your knowledge available in every thread	Available
Model Gateway: one endpoint in front of your provider accounts, routing, failover	Available
The platform AI gateway behind answers (not the Model Gateway): budgets, redaction, fallbacks, an answer cache and a policy for one organisation	Each control is switched off by default and applies once your deployment turns it on; the policy for one organisation is Beta. Access on request
Agents: work that acts instead of answering	Beta. Access on request. The surface runs behind sign-in, with sign-up closed; ask your MITHUNAI contact
Team: AI employees for support, IT service desk, DevOps, marketing, sales and finance, which ask a person before they act	Beta, switched off by default. An Owner or Administrator can connect Zendesk, Freshdesk, Intercom, Jira, Jira Service Management, GitHub, Grafana Cloud, Datadog, Sentry, PagerDuty, HubSpot, WordPress, X, LinkedIn, Google Search Console, Slack, Stripe, QuickBooks Online, Xero, Ramp, Expensify, Okta, Google Workspace, Microsoft Entra ID, Gmail and Microsoft Outlook with a token or their own app; none of those has yet been run against a real account, and a rollback or restart is never sent. Any other tool says Not available yet, and nothing is sent, published or changed there. Answers from your knowledge and reading web pages are real
Team approvals: Allow once, Always allow or Deny; rules that need two people; a card from work that arrived by itself expires after a day	Beta, rules off by default. Money, deleting, publishing and access changes can never be always allowed
Team Support: testing on past solved tickets, with a confidence threshold below which a reply becomes a hand-off with a summary	Beta. Never yet run against a real Zendesk, Freshdesk or Intercom account
Team DevOps: investigating with Sentry, PagerDuty and Datadog with a stated confidence, their signed alerts, and postmortem drafts	Beta. Never yet run against a real account; a rollback or restart is never sent
Team Marketer: posts to X and LinkedIn once approved, and the pages that lost search clicks in Google Search Console	Beta. Every post waits for a person; never yet run against a real account
Team IT service desk: access, password, MFA, onboarding, offboarding and access reviews in Okta, Google Workspace or Microsoft Entra ID	Beta. Every change waits for a person; never yet run against a real account
One sign-in and one sign-out across every MITHUNAI product	Beta. Chat signs in only through MITHUNAI; Agents and the Gateway also still show a form of their own until your deployment updates. After the update, one sign-out ends every session on every device, and Chat at its next sign-in renewal. See Sign in once
MITHUNAI RAG at its own address, `rag.mithunai.com`	Beta. The widget, HTTP API and MCP addresses do not change

What has been run end to end

Every capability above has automated tests. Separately, in October 2026 the whole path a new customer takes was run end to end, in an automated Chromium browser, against the MITHUNAI server, database, ingestion worker and web server exactly as they ship: signing in, connecting a website and uploading a file, a cited answer and a declined one in the Playground, the three-step website setup, the widget loaded on a second website and answering there with a citation, a visitor’s thumbs-down reaching Coverage gaps, the analytics screens, and an API key used over the HTTP API and MCP. It was run again after the monthly answer allowance was added. It found one defect, fixed the same day: a declined answer read back after a reload told the website visitor to connect a source. What that run did not cover, and so what is not yet proven in the same way:

A hosted model provider. The run used a stand-in that speaks the provider’s wire format. Answer quality has been measured separately with a local open-weight model; see Grounding benchmarks. On 2 November 2026 the hosted service’s own check of its provider passed, for chat and for embeddings; that check is not a customer’s question.
A real website over HTTPS, a running production deployment, and browsers other than Chromium.
Email. No email provider was set up for that run, so invitations and password reset were not part of it. On 2 November 2026 a test message from the hosted service arrived in a real inbox; the invitation, reset and access-request messages themselves have not yet been tried with a real address.
Confluence, Notion, private GitHub, Jira, Jira Service Management and Zendesk tickets, which have not yet been run against real accounts.
MITHUNAI Team, which has not been recorded running for a customer, and none of whose tool connections has been run against a real account. A tool nobody connected reaches nothing.

Planned items have no committed dates. If one matters to your evaluation, tell your MITHUNAI contact. Demand shapes the order. When a capability moves between these columns, the move is recorded in the changelog. What the platform does with your data, and what it will not do, is set out in Security; the questions evaluators ask most are collected in the FAQ.

Get started

Resources

What is available, in beta and planned

Knowledge sources

Answers and assistants

Deploy

Analyze

Administration

Other MITHUNAI products

What has been run end to end

​Knowledge sources

​Answers and assistants

​Deploy

​Analyze

​Administration

​Other MITHUNAI products

​What has been run end to end

Knowledge sources

Answers and assistants

Deploy

Analyze

Administration

Other MITHUNAI products

What has been run end to end