Traditional SaaS Gives People Tools. Agents Complete the Work.

Introduction

Software has always sold better tools. That is the part that is changing.

For twenty years the promise of software as a service has been consistent: give people a better tool and they will do their work faster. A CRM helped a sales team keep track of leads. A project system helped a team organise its tasks. An accounting platform helped a business raise invoices and chase payment.

All of it worked. None of it did the work. The customer still had to open the software, read what it showed them, decide what to do, and then do it — every day, for as long as they owned the product.

That arrangement is now being renegotiated. Software can increasingly understand a job, carry out most of it, and involve a person only where judgement is genuinely required.¹ When a customer has seen that once, a product that merely organises the work in front of them starts to feel like an unfinished version of the thing they actually wanted.

Traditional SaaS gives people tools to do the work. Agent-based software completes the work for them. Everything else in this piece follows from that one sentence.

What Actually Changes

Responsibility for moving the work forward shifts from the user to the software

Take something ordinary: a new enquiry arrives from a website form. A traditional system stores it, shows it on a dashboard, and gives a salesperson the tools to follow up. The salesperson reads it, works out what the person is asking for, writes a reply, sends it, sets a reminder, updates the record, and decides what happens next.

An agent-based system approaches the same enquiry differently. It reads the message, works out what is being asked, checks whether this is an existing customer, drafts or sends an appropriate reply, requests the information that is missing, proposes a time, updates the record, and raises the ones that need a person — the unusual request, the unhappy customer, the deal large enough to warrant attention.

The distinction is not the presence of AI. It is where responsibility sits. In a tool, the software waits and the person acts. In an agent, the software acts and the person supervises.

What that changes about the product

Read the third row again, because it is the uncomfortable one. A tool-shaped business wants users in the product. An agent-shaped business wants the work gone. Those two ambitions pull a roadmap in opposite directions, and a product cannot serve both indefinitely.

The Autonomy Ladder

Nobody sensible starts at full autonomy

The most common way this goes wrong is to promise an autonomous replacement for a role and then discover, in production, that the job contained a dozen judgement calls nobody had written down. The workable path is to move up a ladder, one rung at a time, earning the next rung with evidence.²

1. Level 1
   Recommend

   The software says what it would do and why. The person still does it. This is worth shipping on its own — it removes the deciding, which is often the slow part — and it is the cheapest way to find out how often the reasoning is right.

2. Level 2
   Prepare

   The work arrives finished and waiting for approval: the reply drafted, the record updated, the booking held. The person reviews and releases it. Most of the time saved in a workflow is captured at this rung, before any real autonomy is granted.

3. Level 3
   Complete the routine cases

   Cases that match clear, customer-set rules go through without review. Everything else still stops for approval. The rules are the product here — which cases qualify, what limits apply, what always requires a person.

4. Level 4
   Own the workflow, escalate the exceptions

   The default is that the work happens. A person is involved by exception rather than by design, and their attention goes to the cases that actually deserve it. This is where the pricing conversation changes from software to outcome.

Each rung has to be earned against real cases. Take fifty examples from the last year, run them through, and count three things: handled correctly, correctly escalated, and got it wrong. That number is both your quality bar and your sales evidence.

If You Are Thinking of Building a SaaS

Start from the job, not the feature list

The instinct is to ask what the software should let people do. The better opening question is what the customer is trying to get finished, and what it currently costs them to finish it — in hours, in errors, in the salary of whoever does it today.

Look for a job that happens often, has a clear finish line, already touches software, and is currently done by a person whose time is expensive. Then find out how it is really done. Watch ten or twenty actual cases before designing anything. The exceptions and small judgement calls you find there are not noise to be tidied away later — they are the product.

The questions worth answering before any of it is built

• What starts this piece of work, and how does the software find out?
• What information is needed before a sensible decision can be made?
• Which decisions can be made without a person, and under what limits?
• Which actions must always be approved before they take effect?
• When must it stop and hand over, and to whom?
• How will both sides know the job was done properly?

Those answers change what gets built. Instead of a system that helps a team answer support requests, you get one that reads the request, finds the account, drafts the answer, resolves the routine cases and escalates the rest. Instead of scheduling software, an agent that collects availability, proposes a time, coordinates everyone, books it and chases the confirmations. Instead of another dashboard, something that watches the numbers, notices what changed, explains why it matters and proposes the next move.

The opportunity is not to add AI to a product that would otherwise be a tool. It is to decide, at the start, that the product is responsible for finishing the job.

If You Already Have a SaaS

Your users have already told you which workflow to automate

An established product has something no new entrant has: real people doing real work inside it every day. That usage is a map of where the labour is, and it is worth reading properly before deciding what to build next.

Watch what happens after login. Which screens do people return to several times a day? What do they copy out of your product and into something else? Which fields do they fill the same way every time? Where do they write the same message with three words changed? Those patterns are where a tool can start becoming an agent.

You do not have to rebuild the platform. Pick one workflow — frequent, painful, with an unambiguous finish line — and move it up the ladder. Choosing well matters more than moving fast.

There is a commercial reason to move before you feel ready. Once a competitor in your category sells the completed outcome, your product is no longer being compared on features. It is being compared on how much work the customer still has to do after paying you.

If You Are Mid-Build

The cheapest time to change shape is now, and it gets more expensive monthly

If you are part-way through building a product and the roadmap ahead is mostly screens, forms, filters and manual workflows, it is worth stopping for a week to re-examine the assumption underneath it: that the customer wants a place to do this work.

This is not an argument for abandoning the problem you chose. The problem is probably still real, and the domain knowledge you have built up is the expensive part. It is an argument for reconsidering the shape of the answer while changing it still costs weeks rather than quarters.

Ask the team four questions and insist on honest answers. Are we building a tool or finishing a job? Where are we still asking the customer to do repetitive work? What could the software prepare, decide or complete instead? And what would a customer need to see before they would trust it to do so?

Answer those now and the adjustment is a redesign. Answer them after launch, when customers have configured themselves into your current shape, and it is a migration.

The Trust Layer

The agent does the work. The software is what makes anyone comfortable letting it.

It is tempting to conclude that if the agent does the job, the interface hardly matters. The opposite is true. Nobody hands over part of their operation to something they cannot see, constrain, check or switch off. The software around the agent is what converts a capable model into a product a business will actually run.

This is also the answer to the question founders ask most often about this shift — whether there is still a defensible business when the underlying models are available to everyone. There is, but it is not the model. It is the accumulated knowledge of how one specific job is really done, the evidence that your version does it correctly, and the controls that let a cautious buyer say yes.⁴

What To Do Next

A four-week exercise, whichever of the three situations you are in

The point of this is a decision about product shape, not a commitment to a build. It works equally well for a product that exists, one that is half-built, and one that is still an idea.

1. Week 1
   Name the job, not the feature

   Write down the job your customer is trying to finish, in the words they would use. If you can only describe it in terms of your own screens and features, you are still describing a tool.

2. Week 1–2
   Watch it being done, ten to twenty times

   Sit with whoever does it today. Record the normal path, the exceptions, the decisions, the information they go looking for, and the moments they hesitate. The hesitations mark where human judgement is genuinely required.

3. Week 2
   Do it manually with AI assistance first

   Before building anything, run a handful of real cases by hand using AI as the engine. It is the fastest way to learn where it is reliable, where it is confidently wrong, and what context it was missing.

4. Week 3
   Build a set of fifty real cases to test against

   Take historical examples with known correct outcomes and score every version against them. Without this you have opinions about quality; with it you have a number, and the number is what a buyer will ask for.

5. Week 3–4
   Ship the smallest useful version

   One workflow, at Level 1 or 2 of the ladder, with the approvals and logging in place. Something narrow and reliable beats an ambitious agent that has to be watched constantly.

6. Week 4
   Pilot with two or three similar customers

   Same sector, same problem. Charge for it — a setup fee and a monthly fee is fine to begin with. What repeats across all three is your product; what does not is a service you may choose to keep providing.

If you would rather not assemble the team for that yourself, this is the work Abacus does with founders and product owners — see SaaS and web applications and who we help.

The question to keep asking is a simple one: after the customer has paid you and logged in, how much of the work is still theirs to do? Every year, a good answer to that question will need to be a smaller number.

Acknowledgements

Written by Richard Maurice, founder and AI solutions architect at Abacus.

Citation

@online{abacus2026saastoagents,
 author = {Abacus},
 title = {Traditional SaaS Gives People Tools. Agents Complete the Work.},
 date = {2026-08-10},
 year = {2026},
 url = {https://abacusis.ca/resources/saas-to-agents},
}

Footnotes

1. By "agent" we mean software that is triggered by an event, gathers the context it needs, takes actions across the systems involved, and knows when to bring in a person. That is a different thing from a chat box bolted onto an existing interface, which still leaves the user responsible for deciding what to do and doing it.
2. Full autonomy is rarely the goal and almost never the starting point. Most valuable agents operate with a person approving, correcting, or handling the exceptions — and the proportion handled without a person rises as the evidence accumulates.
3. Seat-based pricing quietly assumes that more value means more people using the software. When the software does the work, that assumption inverts: the customer needs fewer people on the task, and pricing has to be attached to the work completed rather than to the number of logins.
4. None of this means systems of record disappear. Something still has to hold the data, enforce the rules, and provide the audit trail. The change is that holding the data is no longer the whole product — it is the foundation the agent stands on.