Skip to main content
Teams use MITHUNAI where people repeatedly ask questions that existing documentation, runbooks or code already answer, and where a wrong answer costs more than no answer. Three setups cover most of it: an assistant on a public documentation site, an assistant inside a support workflow, and an internal assistant for engineers. Each uses the same pieces, a source, an assistant over it and a channel to reach it, and each gets the same grounding: cited answers, and an abstention when the content does not cover the question.

​
Developer documentation

Put an assistant on your documentation site so developers get answers with links to the exact section. Keyword matching finds exact identifiers such as error codes and configuration keys, which is what developers often paste in. See Sources, Website widget and Analytics.

​
Customer support

Answer repeat questions from your help content, and learn which questions it does not cover.
  • Your help content: connect a public Zendesk Help Center or a public Discourse forum as a source, and write custom answers for the few replies whose wording matters, such as a refund policy. If your help content lives in Confluence, Notion or Zendesk solved tickets, connect it with a saved connection (beta). Help centres and forums that need signing in cannot be connected.
  • Self-service: the widget on your help centre answers visitors directly, with citations they can open.
  • Inside your own tools: your support platform’s backend calls the HTTP API and shows the cited answer, or the abstention, to an agent or a customer. MITHUNAI does not integrate with ticketing systems itself; hand-off to a person is your application’s decision, and abstained on the answer is the signal to act on.
  • Content gaps: Coverage gaps lists what was asked and declined, and the answers a visitor rated unhelpful, so your writers know what to add. Top questions shows what customers ask most, so you know which answers matter most to get right.

​
Internal engineering knowledge

Give engineers one place to ask about runbooks, architecture notes and repositories.
  • Connect repositories with GitHub sources, for their files and again for their issues and pull requests, where the reasoning often lives, and upload exported runbooks and design documents as PDF, Word or Markdown files.
  • Keep internal and public content in separate collections, and create a separate assistant for each audience.
  • Engineers ask in the console, or from Claude Code, Cursor or VS Code through the read-only MCP server.
  • New starters can ask why something is built the way it is. When no document explains it, the assistant says so rather than guessing, and the question appears under Coverage gaps.

​
When MITHUNAI is not the right tool

  • The answer is not written down anywhere you can connect. MITHUNAI answers only from your content and will abstain.
  • You need something to act, such as filing a ticket or changing a system. An assistant answers questions and changes nothing; work that acts belongs to the Agents surface, which is in beta, with access on request. See Assistants and agents.
  • Your content lives only in a system MITHUNAI cannot read, such as a wiki or a ticketing tool. Export it to files, or publish it as a site. See Connectors.
Last modified on November 7, 2026