Build a Personal Assistant Inbox Agent

What is a personal assistant inbox agent?

A personal assistant inbox agent is an AI that works a delegated overflow inbox the way a human assistant would: it reads what comes in, sorts the noise from the things that need a reply, and prepares responses for the person to approve. Built on an agent account, the assistant has its own address that the person forwards or copies overflow to, and it drafts replies without ever sending on its own.

The design that makes this safe is the review queue. The assistant doesn't send — it drafts, and the drafts sit in a queue the person skims and approves. That keeps the assistant useful for the tedious part (reading and typing) while the person keeps the part that needs judgment (deciding what actually goes out). It's the human-in-the-loop pattern, built on the inbox's native drafts instead of a custom queue.

Why run the assistant on a dedicated agent account?

Delegating to an assistant means giving it an inbox, and that inbox should be its own — not a second login to the person's real mailbox. On an agent account the assistant has a dedicated address to forward overflow to, its drafts live in its own queue, and revoking the assistant is deleting one grant rather than untangling shared mailbox access.

It also draws a clean line around what the assistant can touch. The assistant works only the mail forwarded to its address, not the person's entire inbox, and because it drafts rather than sends, even a misread message becomes a draft to discard, not an email already gone. The boundary is the delegation: the person decides what reaches the assistant, and the assistant decides nothing that leaves.

How do I set up the assistant inbox?

Create the assistant's identity with one command, then route overflow to it. The nylas agent account create call returns a working inbox in under 2 seconds:

nylas agent account create assistant@yourapp.nylas.email

Route overflow to the assistant by forwarding a label or filter from the person's real mailbox to this address, or by copying the assistant on threads that can be delegated. Either way, the assistant only ever sees what's deliberately sent to it — the delegation is explicit, not a standing grant over the whole inbox.

How does the assistant triage the overflow?

The assistant reads new mail with nylas email list --unread --json and a model sorts each message: needs a reply, just FYI, or noise. Only the "needs a reply" messages get a draft; the rest are summarized for the daily brief. Projecting the fields the classifier needs with jq keeps the model's job small:

nylas email list --unread --json \
  | jq '.[] | {id, from: .from[0].email, subject, snippet}'

The classification is the model's judgment; what happens to each category is your code. A message tagged "needs a reply" flows to the drafting step, an "FYI" goes into the brief, and noise is left unread or archived. This is the same triage spine as the support and lead agents, tuned for a single person's overflow rather than a queue of customers.

How does the assistant draft replies for approval?

For each message that needs a reply, the assistant writes a draft with nylas email drafts create. The --reply-to flag threads the draft onto the original message, so the reply is in context when the person reviews it. The draft is created, not sent — it lands in the queue and waits:

nylas email drafts create \
  --to sender@example.com \
  --reply-to "$msg_id" \
  --subject "Re: your question" \
  --body "Thanks for reaching out — yes, Thursday works. I'll send an invite."

The model writes the body; the assistant never calls send. Because the draft is threaded and addressed, approving it later is a single action with no editing required for the ones the model got right. The draft is a proposal, and the queue is where the person accepts or rejects each one.

How does the person approve and send?

The person reviews the queue with nylas email drafts list --json, reads the drafts the assistant prepared, and sends the good ones with nylas email drafts send. A draft that needs a tweak is edited first; one that shouldn't go is deleted. Nothing leaves without this step:

# Review the queue the assistant prepared
nylas email drafts list --json | jq -r '.[] | "\(.id)  →  \(.subject)"'

# Send an approved draft by id
nylas email drafts send draft_abc123

The drafts queue is the approval gate, and it's native — no custom database, no approval UI to build. The assistant fills the queue; the person empties it. For an approval workflow with explicit logging and routing, see Build a Human-in-the-Loop Email Agent.

How does the assistant send a daily brief?

Beyond replies, the assistant earns its keep with a daily brief: one email summarizing everything that came in — what it drafted, what's FYI, what it ignored. The assistant builds the summary from the day's triage and sends it to the person with nylas email send:

nylas email send \
  --to you@yourcompany.com \
  --subject "Daily brief — 4 drafts ready, 6 FYIs" \
  --body "$brief"

The brief is the one message the assistant sends without approval, because it goes only to the person it works for — a summary to yourself, not a reply to a third party. It turns a morning of inbox triage into a 30-second read: the drafts to approve, the things to know, and nothing else. For threading multiple messages into a summary, see summarizing email threads with AI.

Keeping the assistant safe

The assistant reads mail forwarded from outside parties, so it sits on the lethal trifecta of private data, untrusted content, and the ability to send. The drafts-only design already removes the dangerous leg — the assistant can't send to a third party — but defense in depth still applies. An outbound rule on the workspace blocks any send the assistant attempts to a recipient outside an expected set, so even a bug or an injection can't turn a draft into an autonomous send. The full containment pattern is in Stop Your AI Agent From Going Rogue, and the daily brief's fixed recipient — yourself — is the same hard-coded-recipient control used by the invoice and support agents.

Next steps

• Build a Human-in-the-Loop Email Agent — an approval workflow with explicit logging and routing
• Manage Email Drafts from the CLI — create, list, edit, and send drafts in depth
• Getting Started with Agent Accounts — the architecture behind the assistant's inbox
• Summarize Email Threads with AI — build the daily brief from threaded conversations
• Stop Your AI Agent From Going Rogue — contain the assistant's outbound beyond the drafts gate
• Full command reference — every nylas email drafts and nylas agent flag
• Nylas v3 API documentation — the drafts and messages API behind these commands