The Right Order for Agent Entrepreneurship: Sell the Work, Then Write the Code
Deep thoughts on AI and aspirations —— ByteDance Deep Thinking Circle
Most people get the first step of Agent entrepreneurship backwards.
The common path is to first build what you think is an impressive digital employee—the more features the better—and then start thinking about who to sell it to. The result is something technically elegant, but customers don’t feel like their real pain has been solved.
Greg Isenberg shared a reverse approach in his entrepreneurship podcast, explained in very concrete terms. His core insight is brief: in the Agent era, you’re not selling tools, you’re selling the work itself. Following this principle, he breaks down every step from picking work, evaluating it, pricing it, to closing the sale. This framework is the most practical starting point I’ve seen recently for anyone wanting to build a business with AI Agents.
Why “Selling Work” Has Clearer Economics Than “Selling Tools”
Traditional SaaS sells software: give customers a tool, they use it to do the work themselves. Agent SaaS sells work: your team doesn’t have to do this manually anymore, we’ll do it. It sounds like just a phrasing difference, but these are two completely different businesses.
The difference lies in how the economics work. When companies buy software, it comes from the software budget—a cost center where they’re looking to save. But if there’s work someone is already being paid to do—receptionists, customer service, dispatchers, order coordinators—that’s an existing expense. When you say “I can do this work better than a person for half the cost,” the boss can immediately see the math.
Selling “work” has another advantage: it bypasses the most expensive part—market education. You don’t need to explain what large language models are or what Agent architecture means. Just one sentence: I can take on this annoying work, better than a new hire, faster than outsourcing, cheaper than adding headcount. Everyone understands that.
Five Criteria for Picking Work
You can’t pick direction by gut feel. Whether a workflow is worth turning into an Agent depends on five things.
First, it happens frequently enough. Daily is passing, hourly is better—every inbound lead, every phone call, every ticket is a candidate. Second, there’s a clear completion marker. The work is booked, the ticket is categorized, the refund is approved—you can tell at a glance whether it’s done. Third, it’s already connected to software. Agents need to touch systems like Gmail, Slack, Shopify—they rely on them both for execution and for gathering context. Fourth, edge cases exist but are learnable. Work that’s too simple doesn’t need an Agent, Zapier-style automation is enough; work that’s all subjective judgment will likely fail in the first version. The sweet spot is in the middle: repetitive labor with a bit of judgment. Fifth, the buyer can viscerally feel the loss. Missed calls, leads lost to slow responses, empty calendar slots—these pains are tied to money.
The practical approach can be simple: pick a niche industry and write down twenty things people frequently complain about. Missed calls, insurance paperwork, appointment reminders, returns and exchanges, lead follow-up—all count. Then score each one: how frequent, how expensive is the pain, how clear is the completion state, what tools does it need to connect to, who controls the budget. After scoring, it becomes obvious where to start.
Watch a Real Person First, Then Write Prompts
Greg repeatedly emphasizes—and most people skip—this step: before you start coding, watch a real person complete this task. Observe ten to twenty cases, have them screen record, and narrate what they’re thinking as they work. Ask which questions are simple, which are tricky, what they check before making decisions, where mistakes commonly happen.
He gave an example of a restaurant receptionist. A customer asks “what time do you open?” Sounds like a simple question. But a real receptionist is thinking about much more: when does the kitchen close, which tables work for customers with strollers, when does the patio shut down, how to treat VIPs, when to transfer to the banquet coordinator. These details won’t appear in any requirements document—only someone who’s done the job knows them. He has a line I’ll remember for a long time: details are the product. Many Agent products fail because the team never touched the real granularity of the work.
After gathering details, write clear instructions for the Agent: what event triggers it, what context it needs, what tools it can use, what it can decide independently, what needs human approval, when to pull in a real person, how to measure success. Think through these seven things clearly, and what you build can deliver consistently.
Don’t chase full automation in the first version either. Start with a minimum viable version: draft-and-approve, triage, coordination, or doing one small thing under clear rules—like booking appointments, sending follow-ups, processing refunds under fifty dollars. Get one small loop stable first, then gradually hand over more decision-making authority. Customer trust is basically built in this order.
The Outer Wrapper Is What Makes It SaaS
The Agent does the work, but what makes customers believe in it is the layer wrapped around the outside. Logs, approval workflows, control rules, handoff boundaries to humans, pre-launch testing environments, explanations of why the Agent made a particular decision. Customers want a “control room” feeling. The backend can be simple, but it can’t be absent.
Test sets are equally important. Find fifty real cases, mark the correct answers, and have the system run through them repeatedly. Every time you change prompts, switch models, or alter workflows, come back to this “gym” and run it again—you’ll immediately know if it’s better or worse. This test set is also a great sales tool: tell customers, we ran this on your past fifty maintenance requests, correctly categorized forty-two, flagged six for manual review, got two wrong—here’s what was wrong and how we fixed it. This transparency is more effective than any flashy demo.
The sales approach is: first find three customers in the same niche, do the work with humans plus AI together, sell results not systems. Start with setup fees plus monthly fees, and once you understand the value, move toward usage-based or outcome-based pricing. What you learn in this process is more valuable than the money: what customers actually care about, where Agents tend to fail, which part they’d miss first if you removed it. Only by circling around recurring patterns can you build a real product.
Where This Business Actually Creates Value
Finally, two doses of cold water to prevent thinking this path is too smooth.
Selling work means taking on labor-level responsibility. When an employee makes a mistake, the boss can yell and replace them; when an Agent makes a mistake, customers want refunds, compensation, explanations. This approach assumes delivery is stable enough, and stability is precisely the hardest part. Also, its replicability is inherently weak: every industry requires re-understanding the unwritten rules. The details you’ve accumulated in the roof repair industry are useless in medical aesthetics clinics.
Precisely because of this, I think this path is honest for most people. It forces you to first answer “can I consistently deliver this work,” rather than deluding yourself with “how cool are the features.” After you’ve validated it, you’ll find that what’s truly hard to replicate was never the model—it’s how deeply you understand a specific job. Those unwritten industry rules, once you dig them out and codify them into a system, become the only distance between you and the next entrant.
Key points: Agent entrepreneurship sells work before writing code; pick work based on frequency, completion markers, software integration, learnable edges, and tangible loss; details are the product, watch real people before writing prompts; start with minimum viable version; logs, approvals, and test sets form the wrapper layer; depth of understanding the work is the moat.