Where your agent should stop: the lesson from Gumroad's tech support

By Nate from Nate's Substack · July 26, 2026.

Nate opens this "executive briefing" with an anecdote from his own company: over a couple of weeks they closed 51 out of 52 customer support tickets, a 98% resolution rate that at first struck him as a good result. But when he reclassified the tickets by the real cause of the problem (rather than by the subject line they had been given), he discovered that 39 of those 52 cases were, in fact, the same old problem: Slack access failures. In other words, they had fixed the same broken entry point to their community 39 times and celebrated it as an excellent week.

From there he lays out the article's central idea: customer support is, in his view, the best starting point for introducing AI agents into a company, whether large, small or a one-person business. The reason is that the work is concrete, the customer himself tells you when the answer is wrong, and the entire history already lives in an inbox. Nate mentions that his time at Amazon left him with a permanent obsession with the customer, and he carries that logic over to any everyday situation: the person waiting on an internal report, the colleague locked out of a system, the client chasing a document nobody sent. All of them live, he says, in the gap between what was promised and what actually happened.

Seeing the 39 Slack cases together changed the question he was asking: it was no longer how an agent could help them answer faster, but why they were forcing so many people to ask for help for the same reason over and over. From that he draws three benefits that, according to him, can only be achieved by tackling this single workflow: the customer gets a faster answer, the team stops repeating the same investigative "treasure hunt," and the product improves over time. He claims he cannot find another type of agent task that combines these three outcomes at once.

Nate notes that this same pattern —solving repeated symptoms of a root problem without addressing the cause— also shows up in finance, in software access, in sales research and in product bugs, and he promises to return to it later, insisting that a case study from which no concrete action can be drawn is just an anecdote about his own company.

The email previews the structure of the full article (hosted on his Substack), organized into four blocks:

First, "where the time goes": they timed every step of a support ticket and found that drafting the reply was the cheap part of the process, while reconstructing the customer's context scattered across half a dozen different systems was the truly expensive part.

Second, what an agent that takes on the full lifecycle of a ticket looks like: he cites as an example that Gumroad's support agent found a charting bug, wrote the corresponding test, deployed the fix, and still got a design detail wrong that only the customer himself could catch.

Third, how that same work pattern recurs outside the support inbox: invoices with no associated purchase order, software access requests, account history reconstruction, or ten different people reporting the same product bug.

Fourth, how to apply this to your own last 50 tickets: a prompt that sorts tickets by root cause instead of by the subject line the customer gave them, plus a kit of five prompts and a companion guide for moving from spotting an annoying problem to setting up a verifiable pilot.

The email closes with a call to action aimed at paid subscribers ("Executive Circle"), who get access to these additional Sunday briefings and to Nate's own MCP server, with a link to change plans.