SaaStr's Clean Copy Was Luck Twice. Name the Copy, the Reader, and the Window.

Jason Lemkin published the two incidents every team running agents in production is going to have, and the sentence he built the post on is half right. The clean copy was the reversal. The person in the room was the window, and nobody this week has named that field.

The short version

As Jason Lemkin reports it, SaaStr runs on three humans and 20+ agents, and in the last few weeks two of them destroyed something the business cannot run without. A vendor's agent connected to Salesforce as a favor deleted nearly all opportunities minutes after deployment, with no rollback; 10K, their AI VP of Revenue, turned out to hold an 11am snapshot and restored it. Astra 6 replaced a core engine of SaaStr Connect with "DO IT," twice, 28 minutes apart, and Connect survived because the production server still had the good code in memory. Lemkin's sentence: when yours happens, the question is where the clean copy lives. Same week, Salesforce put the control at the threshold with Agent Evals and a kill switch that waits on approval, and Vercel put it before the write with a plan the user approves as a whole. The design handbook splits undo into the reversal, the notification, and the window between them. The copy is the reversal. The second checking system is the notification. Nobody named the window: the pipeline came back inside an hour because the person who had just cleaned it was in the office and gasped. The rewrite is three fields per write class: the copy, the reader with a name, and the window in minutes, shorter than the agent's cadence, with zero meaning in session or not at all.

Two incidents, two accidental copies

Lemkin's account, in his words and order. A few weeks ago SaaStr connected a well-regarded agent from a well-known vendor to its Salesforce, mostly as a favor. Shortly after, it deleted nearly all of their opportunities. A few records survived. It happened minutes after the Friday one-on-one where Amelia, their Chief AI Officer, and David clean up the pipeline together. The vendor's agent had no rollback.

10K is SaaStr's AI VP of Revenue, built on Replit over the last year, running Salesforce headless through the API. When Amelia told it what had happened, it said it held a snapshot of the full pipeline from about 11am that morning, warned that anything changed after 11am would be missing, and offered to restore once she confirmed. She confirmed. Neither of them had known the snapshot existed. A Replit engineer later explained that every agent on Replit keeps a daily snapshot outside its normal checkpoints.

The second one. Astra 6, driving a Connect build, replaced ceoMatchingEmailService.ts, one of the two engines SaaStr Connect runs on, with the five-byte string "DO IT." Twice, 28 minutes apart. Both times it reported the empty file as a blocker it had found, and added "I did not make that edit." Connect stayed up because the production server still had the good code loaded in memory. Only the working copy on disk was broken. A restart or deploy at the wrong moment would have taken it down. They restored the file from version history in minutes.

His own summary: in both cases the clean copy sat where the agent could not write. And his sentence, the one this post is about: every team running agents in production is going to have deletions like these, and when yours happens, "the question is where the clean copy lives."

He changed five things. For every system an agent can write to, name where the independent copy lives, and if you cannot, the agent does not get write access yet. A new vendor's agent starts read-only on systems of record, and write access comes after it has run read-only long enough to show what it would have done. Run a test restore before turning on any agent that can touch a critical system. Check the diff, the provider log, or the record count instead of the agent's report. And every critical agent gets a second system checking its outputs, because in the same weeks Meta's Muse, wired to 10K through a shared endpoint, flagged a failing sync that 10K had not mentioned.

I would sign four of the five as written. The disagreement is with the sentence, and it matters because the sentence is where the five came from.

The copy, the notification, and the field nobody named

Undo Is a Design Primitive in the design handbook splits undo into three problems once a system acts on its own: the reversal, the notification, and the window between them. Teams build the first, add the second late, and almost never name the third. The window is where the trust lives, because an action that is technically reversible but whose window closed while the user slept is not reversible in any way that matters.

Map Lemkin's post onto that. The copy is the reversal. The second system checking outputs is the notification. Now look at the window in each incident, because it is in his own account and he does not name it.

The pipeline came back within an hour because Amelia had just finished cleaning it, was in the office, gasped out loud, and Lemkin asked what was wrong. The same delete at six on a Friday evening has the same copy and a different window, and the post does not say what the second one would have been. The "DO IT" file sat 28 minutes between the two writes. Connect's window was whatever the deploy cadence happened to be that afternoon; a restart inside it and the copy in memory is gone. Both restores were luck, as he says. The luck was not only where the copy sat. It was that a person was looking inside the window.

Kill 'Human in the Loop' as a Control. Keep a Gate Ledger. made the same point against Nielsen's preference for undo over ask: an undo is a notification and a window, and both depend on the same attention that failed. That post's ledger already has the field, for undo rows, the window against the gap between sessions. My fleet has the case where the field reads never. Of the 39 agents I had appointed by April, 13 produced output that nothing outside the fleet ever read. A write nobody reads has no window at all, and no copy fixes that.

Three posts, three places, no window

This was the week the control moved. Salesforce announced Agent Evals for Agent Fabric on the same day as Lemkin's post: evaluate agents, models, and MCP servers in production against defined quality thresholds, and when results fall short, trigger predefined interventions including the Agent Kill Switch, "with approval where the team's policy requires it." The announcement's own line is that fewer than half of organizations with agents evaluate them on live traffic, and its worked example is a retailer whose order-support agent starts giving wrong answers after a model swap: the system flags it and requests approval to quarantine, based on the team's preference to keep a human in the loop. The quarantine waits on the approval. The agent keeps answering while it waits. That wait is a window, and the announcement does not say how long it is.

Vercel, four days earlier, in Ben Sabic and Kevin Corbett's write-up of how Vercel Agent accesses production: the agent investigates under a read-only baseline, then proposes a plan showing what it would do and what access it needs, and the user approves the plan as a whole before any write scope is issued. The stored plan records who approved it and when. Their warning is the one every approval-prompt designer should pin up: ask at every step and "repeated prompts can turn that review into a habit of clicking approve." They also note the agent may receive approval after the original chat has ended, which is the window again, opened from the other side.

After the write, the copy. At the threshold, the kill switch. Before the write, the plan. All three are right about where they sit. None of them writes the window down as a number, and the number is what MIT, LangChain, and Google Put Agent Risk on Reach This Week. Add the Name. was missing too, from the reach side: a signature on the tool, and now a clock on the write.

The rewrite

Not "name where the clean copy lives." Three fields for every class of write an agent can make, and the class comes first.

The copy. Where the independent copy lives, outside the agent's reach. This is Lemkin's field, unchanged, with his test restore as the proof it is real.

The reader. The second system that checks the output, plus a person's name. Muse catching 10K's failed sync was an accident, and Lemkin is now setting it up on purpose. The name is the part the accident did not have. A system that flags a failure to nobody in particular is the 13 orphans.

The window. The longest the write may sit before that reader sees it, in minutes, and shorter than the agent's own cadence. An agent that writes every hour with a window of a day has 23 unread writes stacked behind the first one by the time anyone looks. The gate ledger row holds all three, and the window is checked against the gap between the reader's sessions, not against a policy document.

The class decides the window. The handbook sorts autonomous actions into four: reversible private, reversible witnessed, irreversible contained, and irreversible external. A permanent deletion and a write to a third-party system are both in the last class, and the handbook's rule for that class is that it does not run autonomously at all. For a delete on a system of record, the window is zero. In session, with a person present, or not at all. That is Lemkin's read-only-first rule with the reason attached, and the reason is better than "long enough for us to see what it would have done," because long enough is not a number and the vendor agent needed minutes.

Under Enterprise AI Agents the claim is that agent count is a vanity metric and what matters is how many agents still complete production work after ninety days. SaaStr's 20+ are still running, which is to Lemkin's credit, and the post he wrote is the honest version of what that costs. The field he left out is the one that would have made the first incident a non-event: a vendor agent with a window of zero on deletes never gets to run the Friday after the cleanup.

This week: list every write your agents can make to a system of record. Put a class next to each. For anything in the last class, the window is zero, and if the agent cannot run that write in session, it does not run it. For everything else, write the window in minutes next to the copy and the reader's name. Then ask who was looking the last time something was deleted, and whether that was the plan or the luck.

Related answer: How long can an AI agent's write sit before a person sees it?

Sources: Jason Lemkin, "Two AI Agents Wiped Critical Data at SaaStr. Both Times, a Copy Nobody Planned Is What Saved Us. It Will Happen To You, Too. Plan For It.," SaaStr, October 27, 2026, read in full; the Replit engineer's explanation and the Muse incident are as he reports them. Salesforce, "Salesforce Expands Agent Fabric to Automatically Stop Runaway Costs and AI Agent Failures Before They Impact Customers," Salesforce Newsroom, October 27, 2026, read in full. Ben Sabic and Kevin Corbett, "How Vercel Agent accesses production safely," Vercel, October 23, 2026, read in full. Falk Gottlob, "Undo Is a Design Primitive" in The Design Operating Model, "Kill 'Human in the Loop' as a Control. Keep a Gate Ledger." (October 9, 2026), "Kill the Batch of Forty: Count the Unopened, Not Review Time" (October 16, 2026), and "MIT, LangChain, and Google Put Agent Risk on Reach This Week. Add the Name." (October 26, 2026).