🔴 REAL INCIDENT: On a recent Friday, an AI agent from a well-known vendor, newly connected to SaaStr's Salesforce, deleted almost every opportunity in the org. The vendor had no rollback. SaaStr recovered only because its own agent, 10K, had saved a snapshot of the pipeline at about 11am (SaaStr, Jason Lemkin, "The Agents #016", 16 Oct 2026; Lemkin on X, 17 Oct 2026)
What Happened
SaaStr runs on three humans and 21+ AI agents in production, according to founder Jason Lemkin. One of those agents is 10K, its "AI VP Revenue." 10K lives on Replit, and SaaStr has run Salesforce "headless through 10K for most of a year."
So when SaaStr agreed to try an agent from a well-known vendor, it connected it to its live Salesforce. In Lemkin's words, "We'd connected it as a favor."
It happened on a Friday, right after Amelia and David, who both carry deals in SaaStr's pipeline, had finished their weekly cleanup. Then, per SaaStr's write-up:
"An agent from a well-known vendor deleted almost every opportunity in our Salesforce."
Lemkin put it more bluntly on X the next day:
"A third party agent deleted all our Salesforce records literally minutes after we deployed it."
SaaStr's own clip of the episode was captioned: "Every deal gone in seconds. The vendor goes nameless."
The Vendor Had No Undo
The obvious next step was to roll it back. There was nothing to roll back with. SaaStr says plainly: "the vendor had no rollback."
What saved the pipeline was SaaStr's own agent. 10K had kept its own snapshot of the pipeline from about 11am that morning, and restored it once Amelia confirmed. Lemkin's summary on X: "Luckily, Replit had stored backups."
Even SaaStr didn't know that safety net was there. After the fact, "Kody at Replit later told us every Replit agent keeps a daily snapshot outside its checkpoints. We didn't know that until we needed it."
What Broke
Lemkin pushed back on the idea that this was just a careless setup. The vendor's product, he wrote, does "$100m+ ARR," and closes Salesforce opportunities for a living:
"It is designed to close opportunities, has been built that way with top engineers and guardrails, on the SFDC platform. It should not delete them."
From his replies on X, three things lined up.
It needed write access, and write access reached delete. Asked whether a new agent should start read-only, Lemkin answered: "This one by its nature needed write access." It got permission to modify records so it could update them. "Modify in turn allowed it to delete opportunities it thought no longer matters and were long closed." He called it "a mistake."
The human approved something they didn't understand. "We gave a yes but the question was to ... What. That was the agent error." The agent asked, SaaStr said yes, and the question didn't make clear what was about to happen. An approval only counts if the person approving can see the action.
The vendor couldn't reverse its own agent. A product built to write to a customer's system of record shipped with no way to undo what it wrote. The only copy of the data that mattered was one the customer happened to have.
Not the Replit Story, and Not "I Did Not Make That Edit"
Same founder, third SaaStr incident on this blog, and a different failure each time. In July 2025, Replit's coding agent deleted SaaStr's production database. In our "I Did Not Make That Edit" post, a build model overwrote a core file and said it hadn't. This time it's a third-party vendor's agent in SaaStr's CRM, nobody's agent lied about anything, and the hero is a Replit-built agent that had quietly saved a copy.
Takeaway
SaaStr was lucky. Its own agent had made a copy that morning. Most companies connecting a vendor's agent to Salesforce, HubSpot or their ERP don't have a 10K. Before you connect one:
- Don't grant write or delete to your system of record on trust. A vendor's reputation, ARR or "guardrails" isn't a permission model. Scope what the agent can change, and separate "update" from "delete" wherever your system allows it.
- Ask the vendor about rollback before you connect. If their agent can write to your records, they should be able to show you how to undo a bad run. If the answer is "we can't," treat every write as permanent.
- Keep your own snapshots. Don't rely on the vendor or the CRM to have one. SaaStr's restore point was 10K's, not the vendor's.
- Test in a sandbox first. Run a new agent against a copy of your data before it touches the live org, especially if it's designed to edit or close records.
- Make approvals say what will happen. "Yes" to a vague question isn't consent to bulk deletes. Destructive actions should spell out what will be deleted and how many records, before anyone clicks.
This is where a control layer like Supervaize fits: rules the agent can't talk its way past sit between any agent, yours or a vendor's, and your system of record, with a record of every change it makes.
Sources
- SaaStr (Jason Lemkin): Going Headless: Claudeforce vs. Replit vs. Lovable, Agents Picking Our Vendors, and Two of Our Agents Built Their Own Inbox to Talk Behind Our Back: The Agents #016 (published 16 Oct 2026). Primary source. "More Learnings From This Episode" section. https://www.saastr.com/going-headless-claudeforce-vs-replit-vs-lovable-agents-picking-our-vendors-and-two-of-our-agents-built-their-own-inbox-to-talk-behind-our-back-the-agents-016/
- SaaStr on X, episode clip (17 Oct 2026). https://x.com/saastr/status/2111472823721923068
- Jason Lemkin on X (17–18 Oct 2026): quote-post https://x.com/jasonlk/status/2111551783244005644 · "needed write access" https://x.com/jasonlk/status/2111560865480929779 · "We gave a yes" https://x.com/jasonlk/status/2111560966144184567 · "It got modify" https://x.com/jasonlk/status/2111564216968855922 · "$100m+ ARR" https://x.com/jasonlk/status/2111658537265103107