Thematic research email assistant.
The Zapier router in front of the firm's email-assistant agent. One inbox catches both newsletter subscriptions and teammate forwards-with-instructions — this filter checks the sender, drops the newsletter traffic (other workflows handle that), and fires the Claude routine for everything the team actually sent.
Prompts used
The exact LLM prompts this automation calls — system instructions and user messages, in execution order, with the model each step uses.
- Forwarded Email Router →1 prompts
Agent routine that fires whenever a teammate forwards an email to a dedicated AI inbox. Reads the forwarded message plus any free-form instructions the sender added in the forward body, decides where the content belongs across the firm's systems of record (CRM, document store, knowledge base), files the email and any attachments under the right record/folder, optionally creates a follow-up task, and DMs the sender a summary of what it did. Tool-agnostic: connectors are named generically so any firm can swap in their own CRM, file store, knowledge base, and chat tool.
Reference build
The firm has one email-assistant inbox. Teammates forward into it when they want the agent to file something — and the same address is subscribed to newsletters the team reads. Both kinds of mail show up in the same place. This Zap is the router that decides which messages are actually for the agent and fires the routine; the newsletter traffic gets handled by other workflows entirely.
The router is the plumbing. The brain — the decision tree that decides where the forwarded email belongs, what to do with attachments, and how to DM the sender back — lives in the Forwarded Email Router prompt. Read this page for the trigger and the filter; read the prompt page for what the agent actually does once it's fired.
Why the sender filter exists
The assistant mailbox is dual-use on purpose: one address keeps newsletter subscriptions and team-forwards in the same place so the rest of the firm's automations (newsletter archive, TLDR generator) can fan out from a single inbox. The cost is that this Zap has to do the splitting.
- • Sender is on the team allow-list:
- – sj@gen…
- – da@gen…
- – md@gen…
- – dl@gen…
- – nh@gen…
- – ar@gen…
- – bc@gen…
- – ausritter1@gmail
- • Email is treated as a teammate forward with instructions
- • Newsletters the team subscribed to
- • External marketing / vendor email
- • Anything the team didn't send themselves
- → picked up by the newsletter archive and TLDR workflows instead.
Routine payload
One string field — `text` — packing every piece of context the agent will need. The agent's system prompt knows to wait ~5 seconds for this payload before acting (see the prompt page).
Gotchas
- 01One inbox, two traffic types. The shared assistant mailbox catches both (a) emails teammates forward in with an instruction ("file this under Acme", "add to KB") and (b) newsletters / subscription emails the team subscribed to from the same address. Only the first kind should hit the agent — the rest is handled by other workflows (TLDR, newsletter archive). The sender filter is what enforces that split.
- 02Sender allow-list IS the routing logic. The Zap doesn't try to detect intent from the body. If the message comes from a teammate's address, it's a forward-with-instructions; if it doesn't, it's noise to this workflow. Cheap, robust, and trivial to update — adding a new teammate is one new OR row.
- 03Multi-OR, not multi-AND. Each filter row is its own group with `action: continue` — Zapier treats independent groups as OR. That means any one teammate match passes the email through. A single AND group would require the email to be from every teammate at once, which is impossible.
- 04HTML strip happens BEFORE the agent call. Outlook bodies are HTML by default; passing raw HTML into the agent burns tokens and confuses the routing. `string.strip_html` gives the model the plain words it actually needs to reason about.
- 05The agent is fired by webhook, not by a chat completion. The Zap calls Anthropic's experimental `claude_code/routines/{id}/fire` endpoint with an OAuth bearer token and the `anthropic-beta: experimental-cc-routine-2026-04-01` header. The payload includes the sender, the clean email, and attachments. From there the routine takes over — Zapier's job is done.
- 06Attachments travel inline. The webhook payload carries `hasAttachments`, file types, file names, and the actual file content under separate keys. The agent needs all four to decide what to upload where (the file picker tool wants names + types; the upload tool wants the body). If attachments break, check the Outlook step — Outlook truncates large attachments by default.
- 07Pairs with — and gates — the prompt. This Zap is the cheap router that gets a message in front of the agent. The actual decision tree (CRM vs doc store vs KB vs chat-back) lives in the routine's system prompt. Read them together: this page is the plumbing, the prompt page is the brain.
- 08Single inbox, single agent ID. The Zap is hardcoded to one routine ID. To run a different agent against the same inbox, fork the Zap and change the URL — don't try to multiplex from one Zap.