> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mithunai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Work that arrives by itself

> Have the Support AI employee prepare each new helpdesk ticket, and the DevOps employee each alert from your monitoring, for a person to approve.

An AI employee can pick up work with nobody handing it over. What it prepares waits for a person: it
never changes anything in another system by itself, whatever your approval policy says.

> [!WARNING]
>
> AI employees are in **beta**, and this needs a second switch on your deployment, off by default,
> so you will not see it unless your deployment has turned it on. **It has never run against a real
> Zendesk, Freshdesk or Intercom account, and no real Grafana has sent it an alert.** See [AI
> employees](https://docs.mithunai.com/team/overview.md).

## Pick up new helpdesk tickets

First [connect Zendesk, Freshdesk or Intercom](https://docs.mithunai.com/team/connect-your-tools.md) to the Support inbox. Then an Owner or Administrator
opens the [Support employee](https://docs.mithunai.com/team/support.md), finds **New tickets**, and turns on **Pick up new tickets**.

* It looks about every five minutes.
* It picks up tickets created **after you turn it on** that are still new when it looks. One your team
  has already opened stays with your team.
* Each ticket becomes one piece of work, once. If a check fails, the ticket is read again at the next.
* What it prepares goes on that ticket, once a person approves it.

The page shows when it last looked and what it picked up. If something stopped it, it says what.

## Who it acts as

Each check acts as the person who turned it on. If they leave, or stop being an Owner or Administrator,
it stops and the page says so. Turn it off and on again as someone who can run it. If your organisation
is suspended or its trial ends, it stops, and picks up again when you are back.

## What a ticket can and cannot do

Anyone can write a ticket, so its text is treated as coming from a stranger. It fills in the subject and
the message and nothing else. It cannot choose what the employee does, which tool it uses or where
anything goes. It can ask for a person, which sends it to your team rather than drafting a reply: either
way a person decides.

## Limits

A check tries up to 10 tickets, and an organisation files up to 50 a day by default. Past that it stops
and says so. Tickets past the limit stay in your helpdesk, and are picked up the next day if they are still new.
In Freshdesk a new ticket is one with the status *Open*; in Intercom, an open conversation. If you
switch to another helpdesk, turn picking up on again for it: it starts from that moment.
Each ticket may spend one answer from your monthly allowance.

## Send alerts to the DevOps employee

Your monitoring can hand the [DevOps employee](https://docs.mithunai.com/team/devops.md) an alert. Create an API key with the
Editor role (the least it takes), then send alerts to the address on the employee's page under
**Alerts**. The page has an example.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
curl -X POST "$ADDRESS" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"service":"checkout-api","title":"High error rate","severity":"critical"}'
```

From Grafana, add a webhook contact point with that address, and put the key in its authorization
header credentials. Give each rule an `alertname` and a `service`, `service_name`, `app` or `job` label.

The employee reads your logs, metrics and deploys if monitoring is [connected](https://docs.mithunai.com/team/connect-your-tools.md),
and prepares a triage summary. It may propose a fix. A person decides, and **a fix is never run from here**.

* The same service and title within an hour is one piece of work.
* An alert that has recovered files nothing.
* Up to 10 alerts per request, and up to 50 a day by default. Past that it files nothing and says so.
* There is no way to send one without a key.

### From Sentry and PagerDuty

Sentry and PagerDuty cannot send an API key, so each has its own address, shown beside its
connection on the DevOps page. A request there is read only if it carries that vendor's valid
signature, under the secret you saved with the connection, and it acts as the person who attached
the connection. A resolved PagerDuty incident becomes a postmortem draft. See
[Connect your tools](https://docs.mithunai.com/team/connect-your-tools.md#sentry-devops-errors) and
[DevOps](https://docs.mithunai.com/team/devops.md#postmortems).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.