Contents
SaaStr AI outbound: what agents cost in CRM, data and deliverability
An AI-first outbound motion does not remove cost. It moves it. On 2 November 2026 SaaStr's Jason Lemkin wrote that vendor AI SDRs now send about 90% of SaaStr's outbound, and in the same post said SaaStr's Salesforce bill is up about 40% this year from agent usage. For anyone building GTM systems, the second number matters as much as the first. The spend leaves the sales floor and lands in the CRM, the data layer and the review process.
What did SaaStr actually claim?
All of the figures below are SaaStr's own, self-reported in the 2 November post. None are independently verified.
- SaaStr says it runs roughly $20M in revenue this year with 3 humans and 20+ agents.
- Vendor AI SDRs send about 90% of its outbound. Lemkin names Artisan, Monaco and Agentforce on outbound, plus an inbound agent from Qualified that he says has closed $1M+.
- Agentforce win-back campaigns to lapsed sponsors and attendees get 72% open rates, according to SaaStr.
- 10K, the internal agent SaaStr calls its AI VP of Marketing, averages about 35,000 Salesforce API calls a day on its own.
- 10K is now the main user of Clay, ZoomInfo and Artisan. "None of our humans log into them much anymore," Lemkin wrote.
The argument of the post is that humans at volume stop reading what they send. His example is a rep at a public software company who emailed him in October 2026 asking about "end of 2024 goals". Lemkin's diagnosis: "I guess the rep did what his system told him to do. The system is the problem."
One caution on the open rate. SaaStr does not say how it measures opens, and open tracking has been an unreliable signal since Apple introduced Mail Privacy Protection in 2021. Treat 72% as a directional claim, not a benchmark.
Where does the cost move when agents run outbound?
The useful part of the post for a GTM engineer is not the headcount line. It is the admission that the system of record is now the bottleneck. Lemkin wrote that SaaStr is running a build versus buy evaluation across its core GTM stack because Salesforce is about to start metering agentic API calls.
That changes how you should design an agent workflow. A human SDR reads a record once and then works from memory. An agent, in SaaStr's description, "reads the account record before each send, including the 400th email of the day." That is the feature. It is also the bill. Every read, every enrichment write and every activity log is an API call, and those calls scale with send volume rather than with headcount.
A worked example, using hypothetical numbers only. Suppose an agent makes 6 CRM calls per email: read account, read contacts, read recent activity, read open opportunities, write the email activity, update a status field. At 500 emails a day that is 3,000 calls. Add enrichment writes and reply handling and you can see how a single agent reaches tens of thousands of calls a day, which is the range SaaStr reports for 10K. If your CRM starts charging per call, the per-email cost of outbound now includes a CRM line that did not exist when a human did the work. The fix is design, not budget: cache account context per run, batch writes, and stop writing low-value fields back to the CRM at all.
Why does data quality decide whether this works?
Lemkin is direct that agents do not fix bad inputs. "An AI SDR with only a name and a title writes email just as generic as that one, and sends 50x more of it," he wrote. SaaStr says it built its own ABM tool inside 10K, working from first-party data such as Salesforce history, event attendance and newsletter engagement, rather than relying only on vendor enrichment.
His summary of what improved output: "Better data improved our pitches more than prompt changes did."
For a GTM team, this reorders the work. If prompt tuning is the smaller lever, then the engineering effort belongs upstream: deduplicating accounts, fixing ownership, keeping job titles and company status current, and making first-party engagement data readable by the agent. A sequence with a stale year in it is a content bug. An agent writing to a contact who left the company eight months ago is a data bug, and it repeats on every send.
What breaks on deliverability?
SaaStr's post does not publish bounce, spam complaint or reply rates, so there is no number to report here. The risk follows from its own framing, though. If an agent with thin data sends 50 times the volume of a human, as Lemkin suggests can happen, then every bad record is also multiplied by 50. Invalid addresses raise bounce rates. Irrelevant messages raise complaints. Both hit sender reputation for the whole domain, including the mail your humans send.
The practical controls are the same ones good outbound teams already use, applied harder: verify addresses before they enter a sequence, separate sending domains for agent volume, cap daily sends per mailbox, and treat a rising bounce rate as a data incident rather than a copy problem.
What review gates does SaaStr use?
The post describes three controls worth copying.
First, SaaStr asks the agent what it plans to send before it sends. Lemkin's point is that review scales: "A bad template gets caught in one review, and the fix applies to every future send."
Second, a human handles the irreversible step at first. 10K builds LinkedIn and X campaigns end to end and a human still clicks publish. SaaStr says its finance workflow ran 3 supervised deals before going autonomous on the 4th.
Third, Lemkin warns about overreach. "An agent that adds a claim you can't back up to 'improve' a pitch does more damage than one that leaves a stale date in." That is a grounding problem, and it needs a check in the pipeline, not a line in the prompt.
He also recommends an agent that reviews every outbound email before it goes out, including human-written ones, and blocks anything with a stale date, a generic product list or no reference to the prospect's situation.
What this changes for a team building GTM systems
Read past the headline. SaaStr's case is not that agents are cheaper than people. It is that agents read every record and can be corrected once for every future send, while humans at volume cannot. That only pays off if three things are true.
The CRM can carry the call volume at a price you have modelled. The data the agent reads is current enough that reading it helps. And there is a gate between the draft and the send that catches stale facts and invented claims.
If any of those is missing, an AI-first outbound motion just sends the "end of 2024 goals" email faster. Budget the API calls, fix the records, and build the review step before you scale the volume.
