How I Built a Multi-Agent AI Email Pipeline with Claude and Gmail API

Published 2026-07-01 · Updated 2026-07-22

Ten clients. Each with their own email marketing setup, brand voice, campaign calendar, and Klaviyo account. One person managing all of it. The only way that works is to automate the parts that are actually automatable. This is the system I built to do that.

The actual bottleneck is not writing

Writing emails is not that slow once you know what you are writing. The bottleneck is context switching.

Every time you shift from one client to another, you have to reload the brand guide, the tone rules, the current offer, the last three emails, the segmentation instructions. For ten clients, that overhead adds up to hours per week that produce no output.

The system does not write emails for me. It handles the context loading and first-draft generation so that my time goes into decisions and edits, not setup.

What the system does, step by step

Incoming brief arrives as a Gmail thread. It is tagged with a label that identifies the client.

n8n reads the labeled thread and pulls the relevant client context from a structured JSON store. That context includes brand voice rules, approved claims, product list, and recent campaign history.

The context and brief go into a Claude API call. Claude drafts the email.

The output goes back into Gmail as a draft, labeled with the client name and flagged for human review. Nothing gets near Klaviyo until a human has read and approved it.

The full technical stack

Gmail API handles reading incoming threads and writing draft replies. n8n orchestrates the pipeline, monitors labels, and manages the data flow between Gmail and Claude.

Claude API (claude-sonnet-4-5) generates the draft. The prompt includes structured brand context pulled per client, the campaign brief, and the output format spec.

The brand context store is a set of JSON files, one per client. Each file contains tone rules, product data, approved claims, and recent send history. The n8n workflow reads the right file based on the Gmail label.

Total infrastructure: Gmail API, n8n self-hosted, Claude API, JSON files on a private server. No database. No custom frontend. The whole thing is maintainable in an afternoon.

The multi-agent architecture

A single Claude API call that takes a brief and returns a draft is not multi-agent. Multi-agent means coordinated agents with distinct responsibilities.

This pipeline uses three agents. The Strategy agent reads the brief and outputs a structured breakdown: the main hook, supporting points, and CTA direction. It does not write prose. It outputs structure.

The Draft agent takes that structure and writes the full email. It has access to the brand context and recent send history so it does not repeat hooks or subject line formats used in recent campaigns.

The Review agent checks the output against the brand rules file. It flags any approved claim violations, off-tone language, or structural issues before the draft reaches Gmail.

Three agents, one pipeline. The output quality is higher than a single-pass call, and the review step catches problems before they become revision requests.

Building the brand context store

The hardest part of this build was not the code. It was the context.

Each client needs a document that captures their voice with enough precision that Claude can use it. Generic instructions like 'write in a friendly tone' produce generic output. Specific instructions like 'use short sentences, avoid passive voice, reference real numbers where available, never use the word journey' produce usable drafts.

Building the context store took two to three hours per client on initial setup. Each file has been updated maybe twice since then. That is the total ongoing maintenance cost per client.

What it handles every month

100+ email drafts per month across ten client accounts. Average time from brief to draft in Gmail: under four minutes.

Around 70% of drafts go to Klaviyo with minor edits. The other 30% need structural changes but the raw material is usable. Either way, starting from a draft is faster than starting from a blank document.

Time saved on first drafts: around three hours per week. The larger gain is that adding a new client does not add linear time overhead. The context store scales. The context switching does not.

What the system does not do

It does not make strategy decisions. Which campaign to run, which segment to target, what offer to lead with: those are still human calls.

It does not have access to real-time performance data. I have to feed campaign results back into the context store manually. The system does not learn from sends automatically.

It does not know when a client's offer changes unless I update the JSON file. If a product goes out of stock and the context store still references it, the draft will still reference it. Garbage in, garbage out.

Should you build something like this?

If you are managing email production for more than two or three brands, the context-switching overhead is real and it compounds as you add clients.

The setup is not trivial. Expect two to three weeks to build the pipeline, test it against real briefs, and tune the brand context for each client until the output is consistently usable.

Once it is running, the maintenance is low. The payoff is being able to handle more accounts without proportionally more time. That is the point.

The alternative is a dedicated writer per account. That is also a valid choice. This one is faster to start and cheaper at low volumes. At some scale, the writer makes more sense. Know which side of that line you are on.