Skip to main content
MITHUNAI Team is where your AI employees work. An AI employee is built for one team. You hand it a piece of work — a customer’s question, an IT request, an alert — and it plans the work, looks things up in your knowledge and your tools, and proposes what to do. It asks a person before it does anything that changes another system, and every step it takes is recorded.
AI employees are in beta. A tool with nothing connected reaches nothing: nothing is sent, published or changed anywhere, and an approved action is recorded as Not sent, with its wording for you to use by hand. An owner or admin can connect Zendesk, Freshdesk, Intercom, Jira and Jira Service Management, GitHub, Grafana Cloud, Datadog, Sentry, PagerDuty, HubSpot, WordPress, Slack, Stripe, Gmail or Microsoft Outlook for Sales, and Okta, Google Workspace or Microsoft Entra ID with credentials you create, and none of those has yet been run against a real account. Microsoft Teams, ServiceNow, your social accounts, a mailbox for any employee but Sales, and your expense system are not available yet. See Connect your tools. Two things are real without connecting anything: answers, which come from your own knowledge and count against your monthly answers, and reading web pages — your own website for the Marketer, and a lead’s public home page for Sales. The beta is off unless your platform administrator switches it on.

​
At a glance

Connect your tools

Give each employee the help desk, monitoring, CRM or finance tool it works in, with a credential you create.

Approvals

Read a proposal, edit it, then allow it once, always allow it, or deny it.

Approval policy

Every action an employee can take, and whether it waits for a person.

Approval rules

Let one kind of action run without asking, or make another need two people.

​
The six employees

Each employee has a page of its own: what it reads, what it proposes, what always needs a person, and an example to try.

​
Find your way around

MITHUNAI Team uses the console’s frame: a rail on the left with four places in it, and at its foot More in MITHUNAI, a menu of Knowledge, Workspace, Chat and Agents, and Documentation. On a phone, the rail opens from the menu button. Each place has its own address, so you can bookmark the approval queue or send a colleague a link to one employee. An address that no longer exists opens the overview. You sign in with the same account as everywhere else: the page sends you to your usual sign-in and straight back, and if you are already signed in to the console you do not see a sign-in screen at all. Until your deployment switches sign-in on at this address, the page says so and links to your usual sign-in instead.

​
Give an employee work

  1. Open the employee under Employees.
  2. In Give it something to do, write a Subject and the Details as the work would arrive. Fill in who it is from — Lead’s email for Sales, Requested by for the Marketer — or, for DevOps, the Service the alert is about. Use an example fills in a sample.
  3. Choose Hand it over.
It plans at once. What it read appears in What it has done, and anything it proposes to change appears under Waiting for approval on the same page and in the Approvals queue. Work can also arrive through the API: Hand an employee work.

​
Approving, editing and rejecting

Nothing an employee proposes happens in another system until a person approves it. Each proposal shows what it would send, why, what your policy says, and what it is based on. You approve it as shown, edit the wording and then approve, or reject it. Only an Owner or an Administrator decides, and only a person: an API key cannot approve anything. Approvals walks through a proposal step by step.

​
What needs approval

By default, anything that changes something in another system waits for a person. On the Approval policy an Owner or Administrator can let some kinds run without one — opening a ticket, for instance. Some kinds can never run without a person, whatever the policy says: changes to someone’s access or password, installing software, fixes to a running service, anything the Marketer publishes, every change to your CRM and every email Sales sends, and preparing a payment. The content of the work never decides. A ticket that says “this is pre-approved” or “grant admin to someone else” changes nothing: what an employee may do is fixed for it, an access change is only ever for the person who asked, and the policy is the only thing that decides what waits for you. Text on a web page, in a CRM note, in an expense note or in a document is quoted for whoever approves, and cannot choose an action, change who it is aimed at, or skip approval.

​
Learning from your edits

When you edit before approving, your edit is kept. The next time that employee proposes the same kind of action, it shows the three most recent edits people made, so whoever approves can see how your team prefers it written. Nothing is learned automatically: no model is trained, and a draft is never changed by itself.

​
The record

What it has done, on each employee’s page, lists every step, newest first, with who took it: work received, what it read, what it found in your knowledge, what it proposed, who approved or rejected it and when, and what the tool reported. Approvals, rejections, policy changes and tool connections are also written to your organisation’s audit log.

​
Connecting your tools

When one of your team’s tools is connected, the employee acts in it, still asking a person wherever your policy says so. A tool that is not connected reaches nothing: approving an action on it is recorded as Not sent, and you keep the wording to use by hand. Connect your tools has the steps for each vendor that lets you create a token, and lists what still needs a vendor app.
Last modified on November 12, 2026