The Right Order for Agent Startups: Sell the Work First, Write the Code Later
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 build what you think is an impressive digital employee first, pack it with as many features as possible, then figure out who to sell it to. The result is something technically impressive but fails to address the tangible pain customers actually feel.
Greg Isenberg offered a reverse playbook in his startup podcast, and he’s extremely specific about it. His core insight is short: in the Agent era, you’re not selling tools—you’re selling work itself. Following that principle, he breaks down every step from picking work, observing it, pricing it, to closing the sale. This is the most practical starting point I’ve seen recently for anyone wanting to build a business with AI Agents.
Why “Selling Work” Is Easier to Justify Than “Selling Tools”
Traditional SaaS sells software: you give customers a tool, and they use it to do the work themselves. Agent SaaS sells work: your team no longer has to do this manually—we’ll do it. It sounds like a semantic difference, but these are two fundamentally different businesses.
The difference is in how the economics work. When companies buy software, it comes from the software budget—a cost center where they’re trying to save money. But if work is already being done by someone on payroll—receptionists, customer service reps, dispatchers, order coordinators—that’s an existing line item. When you say “I can do this work more reliably than a person, at half the cost,” the boss can immediately calculate that ROI.
Selling “work” has another advantage: it bypasses the most expensive part—educating the market. You don’t need to explain large language models or Agent architecture. Just one sentence: I can take this tedious work off your plate, better than a new hire, faster than outsourcing, cheaper than adding headcount. Everyone understands that.
Five Criteria for Picking Work
Direction can’t come from guesswork. 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—all candidates. Second, there’s a clear completion marker. Order placed, ticket categorized, refund approved—you can tell at a glance whether it’s done. Third, it’s already plugged into software. Agents need to interact with systems like Gmail, Slack, Shopify—both to execute actions and to gather decision context. Fourth, edge cases exist but are learnable. Work that’s too simple doesn’t need an Agent—Zapier-style automation is sufficient. Work that’s entirely subjective judgment will likely fail in the first version. The sweet spot is in the middle: repetitive labor with some judgment involved. Fifth, the buyer can viscerally feel the cost of failure. Missed calls, leads lost to slow response, empty calendar slots—these pains are connected to money.
The actual process 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 item: how frequent, how expensive is the pain, how clear is the completion state, what tools need integration, who controls the budget. Once you’re done scoring, the starting point becomes obvious.
Shadow a Real Person First, Then Write Your Prompts
Greg emphasizes this repeatedly, and it’s the step most people skip: before building anything, watch a real person complete this task. Observe ten to twenty cases, have them screen-record, and narrate their thinking as they work. Ask which questions are simple, which are tricky, what they check before making decisions, where errors typically happen.
He gave an example of a restaurant host. A customer asks “what time do you open?” Sounds like a simple question. But a real host has much more context running through their head: when the kitchen stops taking orders, which tables accommodate strollers, when the patio closes, how to treat VIPs, when to escalate to the banquet manager. These details never make it into any requirements document—only someone who’s done the job knows them. He has a line I remember well: the details are the product. Many Agent products fail because the team never touched the actual granularity of the work.
Once you have the details, write clear specifications for the Agent: what event triggers it, what context it needs, what tools it can use, what it can decide autonomously, what requires approval, when to pull a human in, what constitutes success. Think through these seven things clearly, and what you build will actually deliver consistently.
Don’t chase full automation in version one 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 rights. Customer trust is basically built in this sequence.
The Wrapper Is What Makes It SaaS
The Agent does the work, but what makes customers believe in it is the layer wrapped around it. Logs, approval workflows, control rules, handoff boundaries to humans, pre-production test environments, explanations of why the Agent made each decision. Customers want a “control room” feel—the interface can be simple, but it can’t be absent.
Test suites are equally important. Find fifty real cases, label the correct answers, and run the system through them repeatedly. Every time you change the prompt, swap models, or modify the workflow, go back to this “gym” and run it again—you’ll immediately know if it improved or regressed. This test suite is also a great sales tool: tell customers, “we ran your last fifty maintenance requests through the system—forty-two were categorized correctly, six were flagged for human review, two had errors, and here’s what went wrong and how we fixed it.” This kind of transparency works better than any technical showcase.
The sales approach is: find three customers in the same niche, deliver the work with a human-AI hybrid, and sell outcomes rather than the system. Start with setup fees plus monthly retainers, then once you understand the value, move toward usage-based or outcome-based pricing. What you learn in this process is more valuable than the revenue: what customers actually care about, where the Agent tends to fail, what they’d miss first if you removed it. Only by circling around recurring patterns can you build a real product.
Where This Business Really Creates Value
Two buckets of cold water at the end, so you don’t imagine this path too smoothly.
Selling work means taking on labor-level responsibility. When an employee makes a mistake, the boss can scold them or replace them. When an Agent makes a mistake, customers want refunds, compensation, explanations. This approach assumes delivery is stable enough, and stability is exactly the hardest part. Also, it’s inherently less scalable: every industry requires re-learning the unwritten rules. The details you accumulated in the roofing repair industry are useless when you move to medical aesthetics clinics.
That’s precisely why I think this path is honest for most people. It forces you to answer “can I consistently deliver this work?” rather than getting high on “how cool are my features?” Once you make it work, you’ll realize the truly hard-to-replicate part was never the model—it’s the depth of your understanding of a specific job. Those unwritten industry rules, once you dig them out and codify them into the system, become the only distance between you and the next entrant.
Key points: Agent startups should sell work before writing code; pick work based on five criteria—frequency, completion markers, software integration, learnable edges, felt losses; details are the product, shadow real people before writing prompts; start from minimum viable version; logs, approvals, and test suites form the wrapper layer; depth of understanding the work is the real moat.