It reads every message that arrived in your shared inbox since the last time it ran, works out what each one is — a bug, a billing question, a cancellation, a bounce — and writes one drafted reply per thread. In the morning you get a queue of cards instead of a wall of unread mail. Nothing has been sent.

No, and there is no setting that turns that on. Every draft is written to a review queue, and the only code path that reaches the mail rail is the one that runs against replies a human already approved. Approving does not send either — it stages the reply behind a kill window you can use.

No. Your system of record stays Microsoft 365 or Gmail. Replies go out from your own address, land in your own Sent folder, and thread inside the customer's own conversation. If you turned TriageDesk off tomorrow your inbox would be exactly where you left it.

Nothing gets drafted. Complaints, legal threats and cancellations are routed to a human undrafted — that is a branch in the code, not a confidence threshold, so it cannot be tuned away by a model having a good day.

Every classification and every draft writes a ledger row carrying the evidence it acted on, and the evidence is verbatim spans of the customer's own message. A quote the message does not literally contain is dropped before it is ever shown, so a receipt in the ledger is something you can check without opening the original.

It is not allowed to. A drafted reply may only commit to something already present in the thread or in the answers your team has saved — a refund, a credit, a discount, a guarantee or a date that appears in neither is rejected outright and the thread goes to a human instead.

Two things per message: what it is — a bug, a billing question, a sales enquiry, an onboarding request, a feature ask, a complaint, a legal matter, a cancellation, an auto-reply or a cold pitch — and how urgent it is. Everything after that follows from those two answers.

Urgent means production is down, money is moving wrongly, a deadline is today, or the sender is escalating. It is a judgement on the message rather than on the sender, so a polite customer with a real outage outranks an impatient one asking about an invoice.

One prepared reply per conversation, using your team's name, your sign-off and the tone you set. Where the answer is not in the thread or in your saved answers it says plainly that it is checking and will come back — it is instructed never to fill the gap with a guess.

Three things catch it before you ever see it, and a fourth after. A draft carrying a bracketed placeholder is thrown away. A draft that commits to something the thread never mentioned is thrown away. A draft it cannot parse at all is thrown away. And the one that survives is still just a card in a queue with a Kill button on it.

Up to a cap, and then it stops for good. A thread the agent has already answered 3 times is, by definition, not a thread it is solving — every further message in it goes to a human and stays with them.

Records them and stops. They are classified like everything else so your counts stay honest, and then they are done — no card, no draft, no notification. A morning queue full of postmaster notices is not a queue.

Microsoft 365 and Gmail. Both connect by OAuth against your own account; there is no forwarding address, no IMAP password, and no copy of your inbox living somewhere else as the system of record.

On Microsoft 365, Mail.ReadWrite and Mail.Send — write access because an approved reply goes out through Graph's createReply, which threads it inside the customer's own conversation. On Gmail, one scope: gmail.modify, which covers reading, sending and marking read, and cannot permanently delete a thread.

It is built not to. The overnight pass resumes from a watermark and asks the provider once for a bounded window of unread mail rather than polling, the dispatcher moves at most 20 due replies per tick so the queue drains over minutes rather than as one burst, and the daily send cap sits far below the ceilings Microsoft and Google publish for a single mailbox. Those published ceilings are on this page, with their sources.

Your address. They go out as the connected mailbox, land in your own Sent folder, and thread inside the conversation the customer started — so a reply looks like a reply, not like a ticket notification from a third party.

Reading and sending stop immediately, and the loop reports that the mailbox is gone rather than failing quietly. Your inbox is untouched: every message it read is still exactly where it was, because it was never moved anywhere.

The tokens are encrypted at rest and never reach a browser — the integrations row is read server-side and only the account label and its connection state are sent to the page. The message bodies are stored so the queue can show you what you are replying to, and they are readable only by your own account.