Skip to main content

Email Assistant

Make your assistant the recipient

The simplest "advanced" pattern doesn't involve any code: put your Deck assistant address into the To: field wherever a system asks you for an email. Mailing lists, GitHub notifications, calendar invites, status pages, billing alerts — anything that sends mail can send it directly to Deck.

No cron job. No webhook. The system you're already using does the sending; Deck reads, files, and answers.

When to reach for this​

You're already gettingPut Deck's address where the email goes
Newsletter and email-list digestsSubscribe with your assistant address.
GitHub notificationsAdd Deck's address to your watched repos / Custom routing settings.
Calendly / Cal.com confirmationsAdd Deck as a guest, or set up a confirmation copy.
Sentry / Datadog / PagerDuty alertsAdd Deck as an extra notification recipient.
Stripe receipts, Linear digests, Vercel deploy notices, AWS billing alertsAdd Deck to the notification list.
Investor updates, board emails, customer-feedback inboxesCC Deck or add it as a regular recipient.

Anything you'd file by hand once a week can file itself in real time.

How to set it up​

Use the address Deck gave you, exactly as-is — one address per assistant, no variants:

your-name@agent.hellodeck.ai

Paste it into the To: or notification-recipient field of whatever system is doing the sending. Deck reads the message and routes it to the right project based on the subject, body, and sender.

A few worked examples​

Mailing lists and newsletters​

Subscribe to Stratechery, Lenny's Newsletter, The Information, or any internal company list with your assistant address. Each issue lands in Deck on its own. Ask later: "summarize the last two weeks of Stratechery" or "anything in this morning's newsletters about Anthropic?".

GitHub notifications​

In GitHub → Settings → Notifications → Custom routing, add your assistant address. Issues, PRs, and review requests flow into Deck. Now "what PRs are waiting on me?" is something you can ask, and a weekly scheduled task can produce a digest from the same stream.

Status and incident alerts​

Add Deck to your Sentry alert recipients, PagerDuty notification policy, or Datadog monitor. When something breaks, the email shows up in Deck against the right project — and the next person who asks Deck "any new incidents this week?" gets a current answer.

Calendar invites and confirmations​

Add Deck as a guest on internal meetings, or BCC your assistant address on Calendly / Cal.com confirmations. Deck picks up the invite, the description, and the attendee list — useful when you later ask "who am I meeting Friday and what was that about?".

Investor and customer threads​

Put Deck on the To/CC line of long-running threads with investors, customers, or partners. Deck reads each message as it comes, builds context, and is ready when you want a recap, a draft, or a sanity check — see CC the assistant.

Routing without subject prefixes​

You don't get the Brain — … / Pipeline — … subject prefix when the system is composing the email — it writes whatever subject it writes. That's fine. Deck reads the body and the sender to figure out the right project. One thing helps:

  • Give the project an obvious name that matches the sender (a project called Stripe will collect Stripe receipts naturally).

If something consistently lands in the wrong place, set up a simple forwarding filter on your inbox that re-routes the noisy source, or add a one-line rule in Settings → Email Assistant.

What this is not good for​

  • Anything you wouldn't want in a project at all. Be deliberate — if you don't want every Vercel deploy in Deck, don't subscribe Deck to Vercel deploys.
  • High-volume, no-signal traffic. Hundreds of identical alerts a day will bury more useful context. Route only what you'd actually want to ask about.
  • Two-way conversations the assistant should send to. Deck replies only to you. Use a different inbox if you need outbound automated replies.

Combining with cron and webhooks​

This pattern composes well with the Advanced ingestion patterns:

  • Use direct delivery for streams you can't control the schedule of (newsletters, GitHub events, alerts).
  • Use scheduled snapshots for state you want a fresh copy of (your calendar, your CRM).
  • Use webhooks when you want Deck to react with two emails (file + prep).

Most setups end up with a mix of all three. Direct delivery is just the cheapest one to start with — five minutes of clicking, no code.

Next​