There’s a moment in most agent deployments where someone asks the wrong question. They ask: “How much can this agent handle on its own?” That’s not the useful question. The useful question is: “Where does this agent have to stop?”
The distinction matters more than it might seem. Most of the hard design work in deploying an AI agent isn’t in the capabilities. It’s in identifying the point where the agent’s judgment ends and human judgment has to begin.
A case from Gumroad makes this concrete. Their support agent didn’t just respond to tickets — it identified a charting bug in the product, wrote a test to reproduce it, and shipped the fix. That’s the full loop: the agent diagnosed the root cause, generated a solution, and deployed it, all without a human in the middle. Impressive, and genuinely useful.
Then it got the design wrong in a way only the customer could catch.
This is the moment that matters. Not because the agent failed — it did most of the job correctly — but because the failure reveals exactly where the stopping condition had to be. The agent could determine that there was a problem. It could determine how to fix it technically. What it couldn’t determine was whether the fix matched what the customer actually wanted. That judgment required the customer.
The Pattern Behind the Example
This generalizes well beyond customer support. The same shape appears across teams: finance reconciliation, IT access provisioning, sales research. In each case, there’s a portion of the work that’s mechanical — retrieving context, cross-referencing systems, drafting a first response — and a portion where someone with accountability needs to validate the output.
The expensive part of a support ticket is almost never writing the reply. It’s reconstructing who this customer is across half a dozen disconnected systems before you can say anything useful. An agent can do that reconstruction reliably, at scale, without the fatigue that comes from running the same scavenger hunt for the fiftieth ticket in a row.
But “what the customer actually expected” is something only the customer can confirm. No amount of context retrieval substitutes for that.
Sorting by Root Cause, Not by Subject Line
One more thing the support example surfaces, which is undervalued: agents are good at aggregation in a way humans working through one ticket at a time simply aren’t.
Consider a team that closed 51 of 52 support tickets in two weeks and called it a great week — until they sorted those tickets by root cause instead of subject line. It turned out 39 of the 52 were the same Slack-access problem. They’d gotten very efficient at cleaning up a recurring mess. They hadn’t fixed the mess.
Getting efficient at handling a problem is not the same as solving it. An agent that surfaces the pattern — that tells you “39 of your last 52 tickets are the same upstream failure” — is worth more than one that just resolves tickets faster. The visibility is often where the real value sits, not just the throughput.
Where This Leaves Us
The honest lesson from cases like Gumroad isn’t that agents are unreliable or need constant supervision. It’s more precise than that. An agent can own the full loop up to the point where validation requires someone with skin in the game — a customer confirming a design choice, a manager signing off on a financial adjustment, an IT owner approving an access change.
Design the stopping condition first, then extend autonomy from there.
The teams that do this well start small: one class of tickets, one workflow, one clear handoff point. They’re not trying to remove humans from the loop. They’re trying to put humans in the right part of the loop — the part where human judgment actually adds something the agent can’t supply.
That’s the reframe worth sitting with: not “how automated can we be?” but “where does human validation actually matter?” Once you can answer that cleanly, the rest of the design gets a lot simpler.
Text summarized and optimized using Anthropic’s models and reviewed by a human.