AI SDR Sending Infrastructure: Gmail API, a Sequencer, or Your Sales Engagement Platform
For cold first touches, have the agent enroll prospects into a cold email sequencer such as Instantly or Smartlead, and keep the Gmail API for replies inside threads the prospect already started. If your reps already live in Outreach, Salesloft or Apollo, use that instead, so the agent's touches show up where people look. Sending cold email straight through the Gmail API only makes sense at very low volume, with someone willing to build the scheduler and the bounce handling by hand.
Every AI SDR eventually calls a function that puts an email in front of a stranger. Which function that is shapes the agent's behavior more than the prompt does.
Most of what ranks for AI SDR setup skips this part. Vendor pages describe the agent. Deliverability guides, including ours, describe the mailboxes and the domains behind them. The pipe in between, the actual tool the agent is handed when it decides to email someone, gets a sentence at most, and it is the decision we would least like to make twice, because every guardrail on this site (the exclusion check and the pause flag above all) has to be rebuilt around it.
The options, side by side
Three pipes you can wire an agent to yourself, plus the one we sell. We put ours last on purpose.
| Send path | Best for | What the agent calls | Pricing model | Key trade-off |
|---|---|---|---|---|
| Gmail API, directA Google Workspace mailbox, messages.send | Replies inside a thread the prospect started. Cold email only at a trickle, from one mailbox. | send(message). One call, one email, out the door now. | Included in the Workspace seat | You build scheduling, mailbox rotation, bounce parsing and unsubscribe headers yourself. A retry after a timeout can send twice. |
| Cold email sequencerInstantly, Smartlead | Cold first touches spread across several mailboxes and domains. | Add lead to campaign, with the drafted copy passed in custom variables. | Monthly subscription, tiered by volume | The sequencer owns the schedule, so stopping the agent stops nothing that is already queued. Replies land in the tool before they reach the agent. |
| Sales engagement platformOutreach, Salesloft, Apollo | Teams whose reps already work their day in it and need agent touches next to their own. | Add prospect to a sequence or cadence. | Per seat, usually on an annual contract | Sends from reps’ own mailboxes, which are the ones you can least afford to burn. Built for people clicking through steps. |
| Done-for-you service (ours, disclosed)Mira Outbound | B2B teams with deals of $5K or more who would rather buy booked meetings than run mailboxes. | Nothing on your side. We run the agent and the send path. | Free pilot, then per-meeting pricing agreed with each client | You do not own the pipes or the mailbox history. A poor fit for low-ACV or consumer sales. |
Our pick for cold first touches: enroll, do not send
Google Workspace lets one user send 2,000 messages a day. Our deliverability guide puts a healthy cold mailbox at 50 to 100 a day. That gap is the argument.
Hand an agent the Gmail API and the only ceiling it will ever bump into is Google's, which sits twenty times above the one you should be living under, and an agent working through a long, loosely filtered list on a quiet night will keep going until something stops it. A sequencer puts the per-mailbox cap and the rotation across mailboxes in a system the agent cannot reconfigure. It is the same reasoning that puts our kill switch inside the send tool: a limit the agent can reason about is a limit it can reason its way around.
Mira works this way. Cold steps go out through a sequencing tool, and a person approves the first touch. Replies are drafted in Gmail, inside the thread the prospect started.
One warning comes with enrolling. Our MCP tool permission matrix already says it: a single enrollment call can schedule five or six emails, so treat it as a send with a delay attached, and cap it per day on the server side.
Where each option fits (and where it does not)
The Gmail API is the right tool for replies. When a prospect writes back asking about pricing, the answer belongs in that exact thread, from that exact mailbox, minutes later, and a sequencer adds nothing there but delay. It is the wrong tool for a cold campaign of any real size, unless you enjoy building a scheduler.
A cold email sequencer wins on first touches across many mailboxes. It loses when your copy does not fit its shape. Most of these tools expect a template with variables, so an agent that writes the whole email ends up stuffing it into one custom field, and you should send yourself a test with that field empty before the first real enrollment.
A sales engagement platform beats a sequencer if you have an SDR team that already runs its day in Outreach or Salesloft. Their call tasks and the agent's emails sit on one timeline, and nobody has to check two tools to learn whether a prospect has been touched this week. The cost is that those platforms send from your reps' real mailboxes, the addresses your customers reply to, and an agent that damages one of those has damaged something you cannot spin up again on a new domain next Tuesday.
A done-for-you service like ours fits a B2B team that wants the meetings and has nobody to own the mailboxes. It is a worse deal than a sequencer plus your own agent if you have an engineer who likes this kind of work and the patience to run a shadow mode first. We would rather say so here than lose you in month three.
What breaks on the Gmail API path
Four things, in the order they tend to show up.
The duplicate. messages.send takes no idempotency key, and a call can time out on your side after Gmail has already delivered the email. The agent sees an error and tries again. Before any retry, read the thread (or search Sent for that recipient over the last few minutes) and only resend if nothing is there. Write the audit record before the call, never after, so a crash in between still leaves a trace.
The broken thread. A follow-up only lands in the original conversation if it carries the threadId, In-Reply-To and References headers pointing at the earlier message, and a subject that matches. Miss one and the prospect gets what looks like a second cold email from a stranger who forgot they already wrote.
Bounces arrive as mail. Mailer-daemon notices drop into the same inbox the agent reads for replies, so your reply classifier needs a label for them, and the bounce has to flow back to suppression and to the mailbox's bounce count. Nobody does this for you.
Then unsubscribe headers. Google requires one-click unsubscribe (List-Unsubscribe plus List-Unsubscribe-Post) from anyone sending more than 5,000 messages a day to Gmail addresses, and a sequencer adds those for you. On the raw API you write the headers and host the endpoint behind them. Our compliance guide covers the legal side.
What breaks on the sequencer and platform paths
The schedule lives somewhere else. Once the agent enrolls a prospect, the next five touches belong to the sequencer's clock, and pausing the agent process does nothing to them. Your stop procedure has to call the sequencer's own pause, per campaign and per mailbox, and you should test that it actually holds the next queued step.
Replies arrive in the tool first. They reach the agent through a webhook or a polling job, and when that link fails it fails silently. An interested prospect sits in a unified inbox nobody opens, while the agent reports a quiet day. Alert on silence: if a campaign that normally sees replies by mid-morning has none by noon, somebody looks.
Ownership drifts. On a sales engagement platform the agent usually enrolls prospects as some user, and if that user is a real rep, the replies and the credit land on someone who did not choose them. Give the agent its own user with its own mailboxes. Then decide, on paper, who gets an interested reply, because the CRM writeback will copy whatever owner the platform picked.
Microsoft 365
Most of the Gmail section applies to Microsoft Graph's sendMail as well, with different limits and a set of failure modes we have not run long enough to write about honestly.
One tool in front of all of them
Whatever you pick, do not hand the agent the vendor's API directly. Give it one send tool and one enroll tool that you own. Each call checks the exclusion list against the live CRM, checks suppression, reads the pause flags, counts against the daily cap, writes the audit record, and only then calls the vendor. If any check cannot reach its source, the tool refuses.
The side benefit shows up the day you switch vendors. The agent never notices. Its tool still has the same name and the same arguments, and every guardrail you tested in shadow mode still sits exactly where you tested it.
If reading this far has convinced you that you do not want to own a send path at all, that is a reasonable conclusion and roughly what our pilot is for. We run your first campaign on our infrastructure, you see who was contacted and what came back, and the free pilot costs nothing if it does not book meetings.
Why we care
After the free pilot we get paid per qualified meeting, and a qualified meeting is one where the prospect shows up. A burned mailbox costs us weeks of sending, and a missed reply costs us the one meeting that campaign was going to produce. Mira runs 24/7 on OpenClaw from a Mac mini in San Francisco, and the OpenClaw MCP Integration Kit ships twelve annotated MCP skill configs, Gmail among them, with a tool permission matrix and a troubleshooting runbook for auth failures, if you are building your own send tool. The rest of the system, from first email to booked call, is on how Mira works.
Jascha Kaykas-Wolff founded Mira Outbound and runs Mira, the outbound agent described across this site, on OpenClaw. These guides come from the guardrails that agent actually uses. kaykas.com