I Built Mailchimp for AI Agents: What the Product Really Needs
Mike Codeur
Mailchimp was costing me more than €4,000 per year. I used a small part of the product while paying for a platform that had grown far beyond my needs. I built AgentsMail, an email marketing SaaS focused on my campaigns, sequences, and the work delegated to agents.
The product is public. The interesting part is not only the interface. Sending an email looks easy until you must protect a template, process 25,000 contacts, prevent duplicates, track bounces, and explain why one contact received nothing.
Product first, method second
AgentsMail covers the workflow I actually use:
- contacts, lists, and tags;
- templates with controlled editable areas;
- campaigns and scheduling;
- sequences with per-contact state;
- delivery, click, bounce, and unsubscribe analytics;
- an API available to both humans and agents.
An agent can prepare a draft from a template. It fills the allowed areas and leaves the campaign in a state a human can inspect. It does not schedule or send automatically. Human approval remains in front of the sensitive action.
That boundary matters. A product built for agents should not only expose more actions. It should make states, permissions, and approvals visible.
A campaign is not a block of text
The draft remains a business object with a subject, content, template, audience, status, and CTA. The editor protects the structure while an agent or a person changes the content.
The same email must work in Gmail, Outlook, and Apple Mail, on mobile and desktop, in light and dark modes. Email HTML does not follow the same rules as a modern Web page. A component that works in a browser can fail in an older mail client.
The template is therefore a guardrail. The agent writes inside defined areas instead of freely rebuilding the whole structure.
Sending to 25,000 contacts without sending twice
One HTTP request looping over 25,000 recipients is fragile. It can time out, fail halfway through, or resend messages after a retry.
AgentsMail splits the work into batches with Inngest, limits concurrency, and keeps progress observable. Every task must be idempotent: replaying an attempt must not send a second email to the same contact.
| Risk | Technical response | Expected evidence |
|---|---|---|
| Large request times out | asynchronous batches | visible progress |
| Partial failure | retry only the affected batch | tracked errors and recovery |
| Duplicate send | idempotency key | one send event per contact |
| Provider overload | bounded concurrency | stable throughput and controlled errors |
The result is not merely a faster button. It is the ability to resume work without losing state or sending twice.
Deliverability closes the loop
Amazon SES transports the email. It does not provide the whole product around it.
AgentsMail must verify domains, account for SPF and DKIM, receive delivery events, handle bounces and complaints, and update the contact, campaign, and sequence. An unsubscribe must stop the next steps immediately.
The per-contact history answers practical questions:
- when did the contact enter the sequence?
- which email was prepared and sent?
- did delivery succeed?
- which link was clicked?
- which condition selected the next branch?
- why is the next message blocked?
Without that history, aggregate charts look useful but cannot diagnose a real case.
I did not rebuild all of Mailchimp
Speed starts with the scope I rejected. I kept the capabilities required for my workflow and left out a general CRM, landing pages, social publishing, and years of historical compatibility.
The PRD describes what to build. A feature graveyard also records what will not be built. Every refusal reduces delivery time, risk, and future maintenance.
AgentsMail is smaller than Mailchimp. It must be complete inside its chosen scope, not imitate every menu.
One story contains the required context
For a feature such as campaign sending, I prepare a complete folder:
- research on the current code and existing APIs;
- design of the flow and states;
- a plan with tasks, dependencies, tests, and a Definition of Done;
- execution on a dedicated branch;
- separate review with tests run again;
- validation of visible behavior and failure cases.
I delegate a verifiable outcome, not a long sequence of tiny prompts. Stories run in parallel only when their dependencies are ready. Contacts and templates can unlock campaigns; campaigns can then unlock deliverability and analytics.
This structure let me move quickly without treating speed as a substitute for control.