If you view AaaS, or Agent as a Service, simply as "SaaS with an integrated AI Agent," you are missing the bigger picture.
SaaS was software designed for humans to perform tasks. Users log in, operate screens, input data, verify, approve, and produce deliverables. SaaS evolved to make that series of operations more efficient.
As Agents mature, the fundamental premise of the product changes.
Instead of users operating tools to perform work, they hand the work over to the Agent. The Agent reads information, gathers decision-making materials, creates drafts, and proceeds with necessary processing. Humans shift from performing all the work to a position of reviewing exceptions, making judgments, and providing approvals.
SaaS provided functions to perform work.
AaaS provides the completion of work.
The Addressable Market for Software is Expanding
When AI Agents evolve sufficiently, the question in product development shifts from "How can we make human work more efficient?" to "Can we entrust this job to an Agent?"
What gets replaced here isn't just existing SaaS functions. It includes internal operations, tasks previously outsourced, processes delegated to BPOs, upstream and execution work handled by consultants or SIers, and junior-level professional work.
Therefore, the AaaS market looks small if measured only by SaaS budgets. What we should look at is the budget companies pay to get work done: labor costs, outsourcing fees, BPO fees, consulting fees, SI fees, and operational costs. AaaS is moving into the labor and service markets, not just the software market.
Current Operations are a Starting Point, Not a Blueprint
When thinking about AaaS, simply tracing existing operations with AI is insufficient.
Many AI implementations proceed based on current business flows: the screens humans see, the Excel files humans update, the approval flows humans run, and the reports humans create. They try to shorten parts of that with AI.
Of course, there is value in that. However, if you assume an Agent, there will be steps that don't need to remain at all.
Current business flows are merely objects of observation. What should be read from them is not the screens or procedures, but the "completed state" that the business is trying to achieve.
The purpose of inquiry handling is not to reply via chat. It is to resolve the customer's problem.
The purpose of drawing-analysis AI is not to read drawings. It is to move tasks like estimation, drawing inspection, change impact analysis, and ordering preparation forward.
The purpose of requirements definition AI is not to generate a requirements definition document. It is to gather field issues, verify them with mocks, clarify what should be built, and create a state ready for ordering.
AaaS design needs to calculate backward from the completion state of the work, rather than being a copy of existing operations.
Think in Units of Work, Not Functions
In traditional SaaS, products were often designed in functional units: search, input, approval, notification, reports, and dashboards. These are combined to make it easier for humans to perform work.
In AaaS, you first define the unit of work.
One inquiry. One estimate request. One set of drawings. One contract review. One requirements definition project. One RFP response. One accounting process. One candidate interaction.
The Agent receives work in those units and proceeds until completion.
What must not be left ambiguous here are the completion conditions. What needs to be in place to say that the job is finished?
For an inquiry, it means the customer's problem is solved and necessary procedures are completed. For an estimate, it means a submittable estimate has been created with verified rationale and risks. For a drawing review, it means important points have been extracted, assigned to a person in charge, and an approval log remains. For requirements definition, it means field-verified mocks, business requirements, functional requirements, RFPs, and acceptance criteria are all ready.
Simply "supporting" does not make it AaaS.
You can only entrust work to an Agent once you define what constitutes completion.
Human-in-the-loop is a Design for Building Trust
An Agent does not need to execute everything with full autonomy from the start.
In many tasks, the Agent reads information, categorizes it, creates candidates, drafts, and identifies risk areas. Humans check, modify as necessary, and approve. Only approved items are executed.
This isn't a story about involving humans as a last resort because AI is immature. It is a trust design for companies to entrust important work to an Agent.
In critical operations, just being correct isn't enough. Why was that judgment made? Who approved it? How much was executed automatically? How can it be reverted in case of failure? What logs remain? Where can a human intervene?
AaaS requires evidence display, reliability indicators, operation logs, permission management, approval flows, audit logs, escalation, rollback, SLAs, and clear boundaries of responsibility. Without these, companies cannot delegate work to an Agent.
The role of the UI also changes. Traditional SaaS provided screens for humans to work on. The AaaS UI is for handing work to the Agent, checking work plans, supervising progress, reviewing high-risk areas, handling exceptions, and providing final approval.
It is closer to a control tower for operating Agents than a workspace.
Pricing Moves Closer to Workload and Outcomes than User Count
In AaaS, pricing design also changes.
In traditional SaaS, seat-based billing or monthly fees were natural. However, the better an Agent functions, the more the number of human users may decrease. If you use the number of users as a standard, customer value and billing will diverge.
In AaaS, the standard for pricing is more likely to be "how much work was completed" rather than "how many people use it." Combinations of per-transaction billing, per-completion billing, performance-based billing, usage-based billing, managed service fees, success fees, and initial implementation fees will be used.
It is more natural to calculate pricing backward from the current cost of that work rather than from software functions.
How many people are involved in that operation? What are the outsourcing costs? What are the BPO fees? What is the loss when a mistake occurs? What is the opportunity loss due to delays?
What customers are buying is not the AI itself.
It is work that is completed faster, cheaper, and more stably.
Product Improvement Targets Automatic Completion Rates and Gross Profit
In AaaS, product improvement metrics also change.
In traditional SaaS, usage rates, login frequency, seat counts, and churn rates were important. While retention is still important in AaaS, it is not enough.
What should be looked at is the economics of processing a single unit of work.
How much gross profit remains when you subtract model/API costs, human review costs, operational costs, exception handling costs, and error handling costs from the revenue per unit?
Product improvement in AaaS does not progress through feature additions alone. It is necessary to increase the automatic completion rate, decrease the human review rate, reduce exception processing, stabilize processing quality, and improve gross profit per unit.
The range of work customers can entrust expands, the Agent's degree of autonomy increases, and unit economics improve. This accumulation constitutes the evolution of the product in AaaS.
Moats Reside in the Operational Loop, Not the Model
A competitive advantage in AaaS is difficult to build with the model alone.
Foundation models continue to evolve. Many functions are imitated. The differentiation of LLM wrappers becomes thin.
What remains is the loop created while continuing to execute work.
The Agent does the work. A human corrects it. It is approved. The results return as a track record. Exceptions and failures are accumulated. From the next time onward, the Agent becomes better.
When this loop turns, it is no longer just an AI function.
What is accumulated are input data, the Agent's initial output, human corrections, approval results, customer-specific rules, industry-specific templates, deliverables, and differences from actual results. Because these are deeply tied to the customer's business context, they are difficult to copy simply.
The moat of AaaS lies not just in the intelligence of the model, but in the business intelligence accumulated while continuing to execute work.
Questions for Thinking About AaaS
If you are designing AaaS, the first thing to ask is not "What kind of AI function should I build?"
Which human tasks, outsourced tasks, BPO tasks, or professional tasks are you replacing? What is the unit of work? Is it one inquiry, one set of drawings, one estimate request, or one requirements definition project?
What needs to happen for that job to be considered finished? How much does that work currently cost? Which budget are you replacing? What input is needed for the Agent to start the work? What deliverable is delivered to the customer?
To what extent does the Agent execute autonomously, and where do humans review? How will you build evidence, authority, approval, auditing, SLAs, and responsibility boundaries? Will you bill based on processing volume, outcomes, usage, monthly fees, managed services, or success fees? Does a profit result from each unit processed? What is accumulated as it is used, and how does it improve?
Anything that cannot answer these is likely to remain an AI function, SaaS with AI, or AI contracting, rather than AaaS.
Summary
AaaS is not just the next feature of SaaS.
It is a shift where software moves from being a "tool" to becoming a "labor force."
Companies that build strong products from now on will not find it enough to just create convenient AI functions. They need to define work that customers can entrust with peace of mind, create a structure where Agents execute that work, humans focus on exceptions and judgment, and billing can be based on results and trust.
The first question to ask in AaaS is simple.
What job will your Agent take on?
I believe we should start from this question.
References
- Sequoia Capital “Services: The New Software”
- a16z “Unbundling the BPO: How AI Will Disrupt Outsourced Work”
- Sierra “Outcome-based pricing for AI Agents”
- Bessemer Venture Partners “AI Agent Autonomy Scale”
- McKinsey “Seizing the agentic AI advantage”
- BCG “How Agentic AI is Transforming Enterprise Platforms”
- Gartner “Over 40% of Agentic AI Projects Will Be Canceled by End of 2027”
- Retell AI / Stripe customer story
