Malcolm Angus
← Sources

Show notes

Show notes: Agents are the new SaaS

2026-07-30


Video: AI Agents are the new SaaS, Greg Isenberg, Startup Ideas podcast.

The whole episode is one argument: software is moving from "help me do the work" to "do the work with me," and most people who see the shift are not building for it. The reason the phrase "bigger than SaaS" gets used is the market. SaaS sold tools into the software budget. Agents sell into the labor budget, which is human capital, a multi-trillion-dollar line. What follows is Greg's step-by-step playbook for finding the niche, building the first agent, proving it works, packaging it like SaaS, and selling it like labor.

The product is the job

The mental model is one line: SaaS sells software, agent SaaS sells work. A normal SaaS product says here is a tool your team could use. An agent product says here is a job your team no longer has to do by hand, and then you sell that service. It sounds like a small change. It is a big one, for the customer and for you.

Two panels. Left, SAAS: HERE IS A TOOL, with a dashboard to log into, reports to read, and seats to pay for, and the note YOU STILL DO THE JOB. Right, in focus, AGENT SAAS: THE JOB, DONE, with calls answered, jobs booked, and tickets triaged, and the note NO HEADCOUNT ADDED.

Take restaurants. A restaurant wakes up worried that the phone rings during the dinner rush, the host is busy seating people, callers ask the same questions, and reservation and private-dining calls get lost. That is lost revenue. This is why a company like Slang AI is interesting: an AI superhost that answers inbound calls, handles guest questions, manages reservations, routes VIPs, and alerts staff to high-priority topics, integrated with the tools the restaurant already runs. Same idea in home services, where a startup like Same Day sells AI dispatchers and receptionists that answer calls, respond to texts, and book and reschedule jobs. Miss fewer calls, book more of the same demand.

When you look for an idea, the test is simple: I handle this one annoying job better than a junior employee, faster than an agency, and cheaper than adding headcount.

Put simply: stop selling a tool your customer has to operate. Sell the finished job.

Pick a workflow with a paycheck attached

Start with the paycheck. If people already pay someone to do the work, an employee, an agency, a receptionist, a dispatcher, there is an opening to do that work cheaper and hand the person back their time for higher-value work. A good agent workflow has five traits.

A checklist of five traits a workflow needs to be worth an agent: it happens all day, it has a clear finish line, it touches software you already run, its edge cases are annoying but learnable, and, highlighted, the buyer can feel the loss. Caption: score every annoying job on these five, the best one is your product.

The middle trait is the one people get wrong. If the workflow is too basic, a Zap already does it and there is no business. If it is pure human judgment, the first version breaks and you lose the customer. The sweet spot is repetitive work with just enough judgment that AI helps.

The first rep is concrete. Pick one niche and write down twenty jobs people complain about. For roofers it might be missed calls, financing questions, insurance paperwork, appointment reminders. For med spas, lead qualification, no-show recovery, membership upsells. Then score each job on five things: how often it happens, how expensive the pain is, how easy it is to know when the job is done, what tools it needs access to, and who already owns the budget. Start with the job that has a paycheck attached.

Put simply: do not invent demand. Find work someone already pays for and offer to do it for less.

Shadow the human before you build

This is the step most founders skip, and it is where the unfair advantage hides. Before you prompt, before you code, find someone who does the job and watch them do it ten to twenty times. Ask them to screen-record it and narrate. Ask what makes a case easy, what makes a case weird, what they check before they decide, and where the mistakes happen. You are mapping the real workflow.

A host answering "what time are you open?" is not really answering that. They know when the kitchen closes, which tables fit a stroller, when the patio is shut, how to handle a VIP, when to route a private-dining inquiry. The detail is the product. Once you have watched the real thing, you can answer the seven questions that make a spec.

A spec sheet titled Spec the agent in seven questions: what wakes it up, what context it needs, what tools it can use, what it can do on its own, where it needs approval, when it escalates, and, highlighted, what success looks like. Caption: the detail is the product, spec what the human actually knows.

Answer those seven and you are not building agent slop. You are building an agent that does the work as well as a person and far more consistently, which is what people pay for.

Put simply: the hours you spend watching the job get done are the cheapest quality you will ever buy.

Build the smallest useful agent

Most people hear "agent" and picture a fully autonomous employee. That is the demo that goes viral and then does not work. Start smaller. Greg calls it the minimal useful agent, and there are four good first versions, each with a little more autonomy than the last.

A rising ladder of four agent versions: draft and approve (start here, in focus), triage, coordinate, and bounded action, under a dashed arrow labeled more autonomy. Caption: start as a predictable workflow, add judgment only where it pays.

A draft-and-approve agent reads context and drafts the reply, quote, or summary, and a human approves it. A triage agent classifies inbound work and routes it. A coordinator agent moves between systems and people, checking availability, sending reminders, chasing missing information. A bounded-action agent does one specific thing under clear rules, like processing a refund under fifty dollars, the way Uber Eats already refunds a missing salad automatically.

Greg points at Anthropic's agent guidance for the sharpest version of this: many agent problems should start as workflows. A workflow follows a predictable path; an agent decides more dynamically. Earn the autonomy by starting predictable and adding judgment only where it creates value. One workflow, one promise, is enough for day one, and it builds confidence in you and in a customer who is buying an agent for the first time.

Put simply: ship the smallest version that does one job, and let the customer's trust, not your ambition, decide when it grows.

The wrapper is what makes it SaaS

A cool automation is not a business. What turns it into an agent-first SaaS product is the wrapper. The agent does the work; the wrapper creates the trust. The agent itself lives inside the phone system, the inbox, the Slack channel, the CRM. What the customer actually buys is the control room around it.

Two panels. Left, WHERE THE AGENT WORKS: the phone system, the inbox, Slack, the CRM, invisible, it just does the job. Right, in focus, WHAT THE CUSTOMER BUYS: a log of every action, approvals and controls, handoff rules, a test harness, and the reason it did what it did.

The dashboard can be simple, but the customer needs the controls: logs of what happened, approvals, handoff rules, a way to test the agent before it goes live, and a way to see why the agent did what it did. That is also why evals matter so much in an agent business. Before you promise autonomy, build a small test set.

A single bar of fifty real jobs the agent was scored on: forty-two routed correctly in focus, six flagged for human review, two got wrong, with a color-coded legend. Caption: an eval set is the gym and the sales asset, show the two it missed and how you fixed them.

Take fifty real examples of the job and mark the right answers: fifty calls, fifty leads, fifty maintenance requests. Run the agent against them. Did it classify correctly, ask for the right missing information, apply the right policy? That set is your gym: every time you change the prompt, the model, the tools, or the workflow, you run it back through. It is also a quietly great sales asset. Telling a property manager "we tested this on fifty of your old maintenance requests, it routed forty-two correctly, flagged six for review, and made two mistakes, here are the two and here is how we fixed them" builds more trust than any pitch.

Put simply: the agent is the engine, the wrapper is the product, and the eval is the receipt that lets a stranger trust both.

Sell the pilot like labor, then productize

The fastest path is a pilot where you do the work by hand with AI, then productize the parts that repeat. Start with three customers in one niche: same niche, same workflow, same pain. Sell the outcome, "we will answer and qualify your missed calls," and charge a simple setup fee plus a monthly fee.

A four-step flow: sell a pilot, find the repeated pattern, build the wrapper, and in focus, agent SaaS. A pricing line reads 1,500 dollar setup plus 1,000 a month, moving to 30 dollars per qualified appointment. Caption: do the work by hand first, the parts that repeat are the product.

Keep the pricing easy to understand at first, then add usage or outcome pricing once you know what the value is. Greg's examples: fifteen hundred setup and a thousand a month for one workflow; or two thousand setup plus thirty dollars per qualified appointment; or three thousand a month up to five hundred handled tickets. The exact number matters less than the learning, what the customer values, where the agent breaks, what needs approval, and what they would miss if you took it away. He is a strong believer that outcome pricing is where agent businesses end up, because the customer does not want to pay for another seat, but you get there with patience, not on day one.

Then you build the product around the repeated pattern. If every roofer needs the same emergency-call script, service-area check, financing question, and estimate follow-up, you have a product. You earn the software by doing the work first.

Put simply: bill for the outcome, deliver it by hand until the pattern is obvious, and only then write the code.

Distribution: the workflow teardown

You still need people to see the thing and think "I need this." The format Greg is watching work in real time is the workflow teardown. Show the old way, then show the agent way.

Two columns. The old way: a call comes in at dinner rush, nobody answers, the caller books the next company, or a rep asks the same five questions and forgets the follow-up, and the lead is lost. The agent way, in focus: the agent answers, asks the right questions, checks the service area and urgency, books the job, updates the CRM, sends the confirmation, and flags the one weird case for a human.

The old way ends with a dropped follow-up and a manager whose heart breaks. The agent way ends with the job booked and the edge case flagged. That contrast is the content, because the owner feels the pain. You are selling painkillers, not vitamins. Pick one workflow and make the internet associate you with it: make the checklist, the benchmark, the teardown, the fifty-examples post. Create the content, find the winners, then put paid ads behind them, and focus on one platform to start.

Put simply: make fun of the old way, show the new way, and become the person the internet tags for that one workflow.

The thirty-day plan

Greg closes with a zero-to-one plan. One niche, one workflow, one promise, and you build an audience the entire time.

  1. Day 1. Pick a niche where missed work costs money: home services, property management, insurance agencies.
  2. Day 2. Interview ten operators, ask them to screen-share the workflow, and just watch. You can pay them for the time.
  3. Day 3. Pick one workflow with frequency, real pain, software access, and a clear success metric.
  4. Day 4. Write the agent spec: trigger, context, tools, rules, handoffs, eval.
  5. Day 5. Run it manually with AI. Paste the context into Claude or ChatGPT, draft the output, have a human approve. You are testing whether the AI helps before you build software.
  6. Day 6. Build the smallest useful version. Draft-and-approve or triage is usually enough.
  7. Day 7. Create the eval set from fifty real examples.
  8. Week 2. Sell two pilots in the same niche.
  9. Week 3. Add the product wrapper: logs, approvals, settings, analytics, handoffs.
  10. Week 4. Publish workflow teardowns, turn the pilots into proof, and double down on what is working.

By the end of week four you have formats that work and you know where to spend to acquire customers. Months two and three are about learning your LTV and the channels that pay back.

Put simply: thirty days is enough to find one painful workflow, make it disappear, and prove someone will pay for that.

Takeaways

  • The product is the job. Sell the outcome, not the tool, and you are selling into the labor budget, not the software budget.
  • Start with a paycheck. The best first workflow is repetitive, has a clear finish line, touches tools people already run, and has a buyer who feels the loss.
  • Shadow the human before you build. The detail is the product, and the seven-question spec is how you capture it.
  • Ship the minimal useful agent and earn autonomy. Draft-and-approve first; add judgment only where it pays.
  • The wrapper is the SaaS and the eval is the receipt. The agent creates output; logs, approvals, and a fifty-job test create the trust.
  • Sell the pilot like labor, then productize the repeated pattern. You earn the software by doing the work first.