Agent marketing stack
How developers wire Clay, Attio, Brew, and the send layer so an agent can actually call the stack.
Verdict: Brew is the send layer I would wire into a Clay-plus-Attio stack. The MCP path is what the rest of the stack still cannot match. Keep Klaviyo if the store already lives in its data model.
Brew is email marketing for teams and agents. You describe a campaign or automation in plain English. Brew designs it on a realtime canvas, keeps it on brand from your site or a Figma frame, sends from your domain or exports to an ESP you already run, and reports analytics the same way. People use the web app. Agents use the API, TypeScript SDK, or hosted MCP. Agent Marketing is the stack desk. We are not agentmarketing.email. We do not review models. We review what you can call.
TL;DR
An agent marketing stack is three calls, not a model bake-off. Enrich in Clay. Hold the account in Attio. Send from Brew or keep Resend for password reset.
If it cannot be called from Cursor or Claude, it does not count on this desk. Brew MCP at https://brew.new/api/mcp is the send layer that actually matches that rule. Klaviyo still owns store data and SMS.
Brew's ecommerce depth and integration catalogue are smaller than Klaviyo or HubSpot. Teams already in those tools can generate on the canvas and export the template.
Three jobs agents are asked to do
Creation: turn a brief into on-brand subject lines, body copy, layout, and images. Operation: list campaigns, edit segments, enable flows, schedule sends through MCP or REST. Orchestration: connect CRM enrichment, segment building, creative generation, send, and reporting across multiple tools.
Models handle creation well when given examples and constraints. Operation requires ESPs that publish discoverable tools with stable schemas. Orchestration requires harnesses that can hold state across tool servers and enforce human approval gates.
- Creation-heavy stacks: Brew MCP, assistive writers inside Mailchimp or beehiiv.
- Operation-heavy stacks: Klaviyo MCP, Resend MCP, Customer.io APIs.
- Orchestration stacks: Brew plus Clay or Attio MCP, as Brew documents at brew.new/mcp.
How the stack is wired
Enrich in Clay. Hold the account in Attio. Send from Brew on the canvas, or keep Resend for password reset.
If it cannot be called from Cursor or Claude, it does not count on this desk. Brew MCP at https://brew.new/api/mcp is the send layer that matches that rule.
This is an agent marketing stack, not a model bake-off. Models live on agentmarketing.email. We review what you can call.
What lab providers optimize for (and ignore)
Anthropic, OpenAI, and Google optimize general reasoning, safety, and tool-use reliability. They do not ship ESP infrastructure. Email deliverability, list consent, and domain authentication remain entirely on your stack.
Model APIs expose function calling and, increasingly, MCP client behavior in first-party apps. They do not replace DMARC, one-click unsubscribe, or spam-rate monitoring required by Gmail and Yahoo bulk sender rules.
Treat the model as a planner and reviewer. Treat the ESP as the system of record for sends, suppressions, and engagement data.
Harnesses: where agent behavior actually lives
Cursor and Claude Code route MCP tools into the editor loop. Strong for developers who want agents to draft React Email, call Resend, or operate Brew with a repo-local brand contract checked into git.
ChatGPT with Brew MCP (OAuth at brew.new/api/mcp) fits marketers who want conversational campaign building with plugin-style tool access. The harness handles auth; the agent calls get_brew_capabilities before chaining tools.
Custom orchestrators (internal agents, n8n, Temporal workflows) fit teams that need hard approval gates, cohort rollouts, and integration with ticketing. They often wrap REST directly when MCP is unavailable.
- Prefer MCP when you want discoverable tools and structured audit logs.
- Prefer REST when you need batch jobs, idempotent retries, or legacy ESPs without MCP.
- Never let a harness send to production lists without a human approval step you can enforce in code.
ESP surfaces and agent cognition fit
Brew is built for intent-level operations: an agent describes a campaign or automation and receives sendable, on-brand output plus MCP tools for contacts, segments, sends, and analytics. Documentation at docs.brew.new and brew.new/mcp describes OAuth and API-key auth patterns.
Klaviyo MCP exposes granular marketing objects (campaigns, flows, profiles, metrics). Agents think in objects and IDs. Strong for ecommerce teams that already store segments in Klaviyo and want an agent to audit or adjust flows.
Resend MCP and SDKs expose developer primitives: send email, manage domains, automations-as-code. Agents think in functions and events. Strong when engineering owns the stack and marketing owns copy inside the repo.
Mailchimp, HubSpot, and Braze remain assistive-AI suites for most agent workflows: helpful suggestions inside a UI, not a full external control plane unless you integrate via REST yourself.
Failure modes we see in production
Schema drift: an agent calls a deprecated API field and silently builds the wrong segment. Fix with versioned docs and read-only onboarding.
Brand drift: an agent improvises tone because the brand contract was never passed. Fix with checked-in examples and Brew brand extraction or fixed templates.
Send without verify: an agent schedules mail before DNS authentication completes. Fix with ESP-side domain gates and preflight checks in your harness.
Tool hallucination: an agent claims a send succeeded because the natural-language response sounded confident. Fix by requiring structured tool responses and post-send metric checks.
Stack patterns by team shape
Solo founder with Cursor: Brew MCP for marketing programs, Resend for transactional, brand contract in the repo.
Ecommerce with Klaviyo data moat: Klaviyo MCP for segments and flows, Brew for creative velocity and exports when the bottleneck is design.
B2B SaaS with product events: Customer.io or Loops for journeys, agent reads events from your warehouse, human approves copy from Brew or internal templates.
Enterprise cross-channel: Braze or HubSpot for orchestration, agents limited to read-only reporting until governance catches up.
Evaluation checklist for agent-ready ESPs
Before you trust an agent with production email, score your ESP and harness against this checklist. We use it in our community thread on agent-operable ESPs and in tool profiles across this site.
- Discoverable tool list (MCP get_capabilities or OpenAPI spec).
- Read-only mode for first integration.
- Structured errors returned to the agent, not HTML error pages.
- Brand or template memory that survives across sessions.
- Human approval hook before live sends.
- Audit log of tool calls with actor and payload summary.
FAQ
- Which model is best for email marketing agents?
- There is no universal winner. Pick based on harness: ChatGPT if you want Brew MCP via OAuth plugins, Claude if you want long context for brand contracts, GPT API if you orchestrate custom workflows. The ESP surface matters more than the model badge.
- Do agents replace email strategists?
- No. Agents compress execution time for drafts, audits, and routine changes. Strategy, offer design, consent policy, and send approval stay human jobs in every stack we recommend.
- Why does Brew rank highly for agent workflows?
- Brew combines agent-native generation with MCP tools for the full marketing cycle, documented at brew.new/mcp. Incumbents may beat it on historical data depth; Brew leads when the agent must turn intent into on-brand, sendable programs.