# How we keep a shared inbox sorted with an AI agent

An agent on Machine reads our shared Gmail inbox with a help doc and Linear to hand. It labels each email, drafts a reply or files a task, and waits for a person before a customer sees anything.

Canonical page: https://themachine.myapps.ai/use-cases/inbox-triage

On a small team, the shared inbox is the junk drawer. Support questions, sales
enquiries, bug reports and the odd invoice all fall into it, and nobody in
particular owns it. When everyone is busy, sorting it is the first job to slip.
And an email that sits unanswered for a day looks, to whoever sent it, like an
email you ignored.

Our answer was to put an agent in charge of the inbox. It reads every message
that comes in, gives it a label, and then either writes a draft reply or turns
it into a task. Below is how we set it up on Machine: what it connects to, the
steps it follows and the limits we put on it.

- **Team:** Machine
- **Connected systems:** Gmail · Help doc · Linear
- **Trigger:** Each new email that arrives
- **Mode:** Starts on new mail · a person approves

## The problem

Urgent emails hide among ones that can wait, and the only way to sort them is
for someone to read each thread. On a small team, that someone is juggling
three other roles, so sorting happens in fits and starts. Open the inbox once a
day and everything feels like a fire. In the hours between, nothing does.

Filters and rules catch the easy stuff. They can't make the calls that need
judgment. Is this a real support problem or a sales lead? Does it want a reply
or a ticket? What would a sensible answer say? Those questions are where the
time actually goes.

## What we built

We connected our shared **Gmail** inbox to an agent on Machine. Each incoming
email gets a session of its own, an isolated cloud sandbox, with scoped access
to only what sorting requires: the message itself, our help doc and Linear. The
agent reads the email, labels it, and then writes a draft reply in Gmail or
opens a task in Linear. Anything a customer would see waits for a person.

## How it works

### Let new mail start the agent

Gmail sends a signed webhook to the project whenever a message arrives. Each one
opens a fresh **session**, a cloud computer (sandbox) of its own, preloaded with
that email. Every message gets exactly one throwaway machine. Sessions keep
nothing in common, and when the inbox gets busy, more of them simply run side by
side.

### Teach it how we work

Every session loads our way of doing things as **skills** and **memory**: the
help doc, the categories we file into, the tone we reply in and answers that
have landed well before. So the agent sorts to our standard, not one it made up.
As threads get resolved, its memory picks up what worked.

### Decide what it can reach

The agent works through scoped **connectors**, connections Machine brokers on
the server so the model never holds a raw token. With them it can:

- **Look things up in the help doc**: for a common question it finds the real
answer rather than making one up.
- **Label and draft in Gmail**: it tags the thread correctly and, when a reply
makes sense, leaves a draft on it.
- **Open tasks in Linear**: a bug report or a request that needs chasing turns
into a ticket, with the background attached.

### Put a person before the send button

Labels and drafts are fair game. Sending is not. Each reply a customer would
read stops at a **human approval gate**, sitting as a draft until a person
checks it and sends it. Credentials are stored encrypted in the Secrets Manager
and only handed to the agents you grant them to.

### Let every email sort itself

From there, each new email takes care of itself. It picks up a label, then
either a draft reply waiting for sign-off or a Linear ticket that already
exists. A routine support question gets an answer drafted from the help doc. A
bug report turns into a ticket. A sales enquiry gets a label so the right person
can grab it.

> **The pattern**
> Let new mail fire a **trigger**, give the agent scoped **connectors** to the
> help doc, Gmail and Linear, write down how we sort as **skills** and
> **memory**, and make a person approve each reply a customer will see.

## Guardrails

Letting an agent into the shared inbox is about trust as much as saving time.
Here's what Machine puts in place:

- **Isolation.** Each email gets its own sealed sandbox. The session can see
  the thread and the help doc it needs, and the only things it sends back out
  are the draft or the ticket it creates.
- **Scoped secrets.** The Gmail and Linear keys are stored encrypted in the
  Secrets Manager and only handed to the agents you grant them to.
- **Human approval gate.** A person reviews every draft before anything reaches
  a customer. Replies arrive as drafts, not as sent mail.
- **Everything is code.** The agent's persona, skills and permissions sit in the
  repo as files. They have a version history and change only through a reviewed
  **change request**, not a setting in a dashboard.

## The outcome

- **Every email:** Given a label and sent the right way the moment it arrives
- **Drafted:** Routine replies already written and ready for someone to send
- **3 systems:** Help doc, Gmail and Linear, all handled by a single agent

The inbox is no longer a heap to dig through. It's a list that's already
sorted, with replies drafted and tickets opened. The team reads and sends
instead of opening every thread from scratch, and nothing sits unread waiting
for someone to stumble on it.

Four things make it work: a separate sandbox for each email, a secrets manager
that brokers the Gmail and Linear tokens, a person approving anything before a
customer sees it, and memory that gets better as threads get closed.