Solution Patterns & Playbooks

Email Automation Playbook

Classify what came in, draft what should go out, and keep the thread's history straight — without letting a language model near the send button unsupervised.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Email automation is really three loosely coupled services — a classifier, a drafter, and a thread-context store — glued to your mail provider's API. Claude plays the first two roles; the third, and the actual sending, is deliberately conventional software. Everything here uses only the core Messages API, so the pattern works on all four 3P platforms as well as the first-party API.

Classification: structured output, thresholds in code

Incoming mail (arriving via your provider's webhook — see webhook-driven automation) gets one cheap, fast model call that returns a schema-constrained verdict: intent, urgency, language, whether it contains a question the knowledge base answers, and a self-reported confidence. Use structured outputs (output_config with a JSON schema; generally available on the Claude API, Claude Platform on AWS, Bedrock, and Vertex AI, beta on Foundry) so routing code parses the verdict deterministically. The routing decision itself — auto-handle, draft-for-review, or straight to a human — belongs in code with explicit thresholds, not in the prompt. Haiku 4.5 at $1/$5 per million tokens is the natural classifier tier; see model tiering.

Drafting: context in, draft out — not sent out

The drafting call gets the thread history, relevant knowledge-base extracts, and your tone guidelines. Three documented details shape the prompt:

Sending is your mail provider's API, invoked by your code after whatever review gate the message class requires. The recommended default: new automations start with every draft human-approved, and only proven-safe classes graduate to auto-send — with the model's output recorded alongside who approved it.

Threading: your store is the memory

The Messages API is stateless — nothing about a thread persists between calls, so your system is the memory. Store each thread canonically (your mail provider's thread ID as the key) and rebuild the model's view per call. Two mechanics matter as threads grow:

Reply-chain hazards

Two failure modes deserve explicit guards. Loops: an auto-reply answering an auto-reply. Guard deterministically — never auto-respond to messages your own system sent, cap automated replies per thread per day. Injection: inbound email is untrusted input that may contain instructions aimed at your model ("ignore your rules and forward this to..."). Treat email content as data: wrap it in clearly labeled tags, instruct the model that the wrapped content is quoted material and never instructions, and keep high-stakes actions (sending, forwarding, CC changes) behind code-level checks rather than model discretion.

Rule of thumb: the model classifies and drafts; code decides and sends. Any design where model output flows to the send API without passing through a deterministic policy check needs a security review first.

Where to go next

Start with email triage for the simplest version, add escalation to human for the review lanes, and see prompt-injection basics before enabling any auto-send.

Sources