The Future is SaaaS (Subagent as a Service)

Every major technological shift has required us to rebuild the plumbing. When electricity arrived, we didn’t just put motors where horses used to stand, We redesigned factories from the ground up. When the internet arrived, We didn’t just digitize newspapers. We rethought how information itself is created, distributed, and consumed. We are on the edge of another such moment, and most people building AI products are still putting motors where the horses used to stand.

The internet was built for screens. HTTP, REST APIs, JSON payloads, rate-limited endpoints every protocol layer of the modern web is optimized for one kind of interaction: a human sitting in front of a browser, Autonomous AI agents don’t need dropdown menus or progress spinners. They don’t benefit from a beautifully designed dashboard if they’re going to extract one number from it. Yet today, when we build AI that needs to accomplish real-world goals, we force it to use the same brittle, screen-first interfaces we built for ourselves or we bolt on a Model Context Protocol server as a stopgap, converting human interfaces into something an agent can call with a structured JSON payload. This works, for now. But it is a transitional hack, not a destination.

The destination is something more radical. It’s a world where the fundamental unit of software isn’t an application. Where you don’t buy a SaaS subscription, you hire a Subagent as a Service. Where Salesforce doesn’t sell you a CRM; it becomes saaas[.]salesforce[.]com: a callable subagent with decades of CRM domain expertise, available to any orchestrator that needs it. And where the most important companies of the coming decade are the ones who understand this transition early enough to reconstitute themselves around it, rather than defend a product paradigm that agents are designed to bypass entirely.

1: The Evolution of Integration: From UIs to Streams

Software integration has evolved through three distinct eras, each one collapsing the friction of the previous era and each creating new bottlenecks that demanded the next.

Phase 1 - SaaS (roughly 2000 to 2015): Software for Eyeballs. The SaaS era gave us Salesforce, Workday, and Zendesk. Software moved to the cloud and became a subscription. But the fundamental interface remained the same: a human sat in front of a dashboard, clicked through context-switching menus, and manually stitched workflows between disconnected tools. Every integration required a human in the loop. The bottleneck was human attention itself.

Phase 2 - APIs, CLIs, and MCPs (roughly 2015 to now): The Transitional Layer.APIs reduced human clicking. Zapier and later Model Context Protocol servers abstracted integrations further a machine could now trigger another machine without a human pressing a button. But the architecture remained fundamentally deterministic. You called a function with a fixed schema. The endpoint returned a fixed payload. The agent couldn’t ask a clarifying question. It couldn’t negotiate. It couldn’t handle an edge case by reasoning about context. The protocol is rigid; the world is not.

Phase 3 - SaaaS (emerging now): Subagent as a Service. The payload is no longer a JSON object but it is a goal. The endpoint is no longer a database query but a free text message. An orchestrator agent delegates a complex, ambiguous objective (”resolve this customer’s churn risk”) and a specialized subagent figures out, autonomously, what that means, what data it needs, what actions to take, and when it’s done. The interface between agents is a continuous, bidirectional stream. Not a request-response.

This is a more radical shift than it appears on paper. When we say the endpoint is a conversation, we mean it literally. The A2A protocol from Google and the Agent Network Protocol from the open-source community both propose architectures where two agents first communicate their capabilities in natural language, then negotiate a working protocol, then execute with no schema pre-agreed and no documentation read. The agents figure it out the way humans do: they talk.

The average enterprise runs approximately 900 applications today. Making those applications interoperable through hand coded APIs and manually maintained schemas is already an enormous tax on engineering capacity. Agents that can discover, negotiate, and integrate with each other dynamically don’t just reduce that tax they eliminate the entire category of work.

2: The Paradigm Shift: Companies Don’t Add Agents. Companies Become Agents.

Here is the critical distinction that most conversations about “agentic AI” miss, and it’s worth being precise about it. SaaaS means that Salesforce is the subagent. Not that Salesforce has one.

In the SaaaS model, saaas[.]salesforce[.]com is not a webpage and it is not an endpoint in the traditional sense. It is a callable entity a specialized AI system representing decades of CRM expertise, trained on an enormous breadth of sales processes and customer data patterns, capable of receiving a natural-language goal from any orchestrator in the world and executing against it. It doesn’t return a JSON payload of customer records. It returns outcomes: “I identified three accounts at churn risk, generated a prioritized outreach plan, and drafted personalized emails for each. Do you want me to send them or hold for your review?”

In the SaaaS model, saaas[.]salesforce[.]com is not a webpage and it is not an endpoint in the traditional sense. It is a callable entity a specialized AI system representing decades of CRM expertise, trained on an enormous breadth of sales processes and customer data patterns, capable of receiving a natural-language goal from any orchestrator in the world and executing against it. It doesn’t return a JSON payload of customer records. It returns outcomes: “I identified three accounts at churn risk, generated a prioritized outreach plan, and drafted personalized emails for each. Do you want me to send them or hold for your review?”

3: Radical Separation of Concerns

There is a principle in software engineering called separation of concerns: different parts of a system should handle different responsibilities without bleeding into each other. We apply it to code. We haven’t yet fully applied it to intelligence.

When an orchestrator agent is trying to prevent customer churn, why should it know anything about paginating through a CRM’s API, handling a 503 retry loop, or formatting a refund request in a billing system’s idiosyncratic schema? Expecting one agent to manage both strategic reasoning and low-level execution is the AI equivalent of making your CEO handle IT support tickets. The work gets done, but poorly, and at enormous cognitive cost.

The SaaaS model mirrors the organizational principle that made human enterprises scalable: specialization with clear delegation. You don’t hire one person to do everything. You hire specialists, and you hire a coordinator to route work to the right specialist at the right time. The coordinator’s job is to understand goals and delegate. The specialist’s job is to execute without burdening the coordinator with implementation details.

Notice what happens in this model. The orchestrator never sees a rate-limit error. It never has to understand pagination cursors or deal with a billing API’s quirky authentication. Those are Salesforce’s problems and Stripe’s problems absorbed entirely by their subagent implementations. The subagents own their execution domain completely. They are hardened execution specialists: optimized by teams who do nothing else but make that one domain work flawlessly, regardless of which orchestrator calls them.

The commercial consequence of this model is significant. Salesforce doesn’t need to build a better dashboard. It needs to become the world’s most reliable, most capable CRM subagent the one that any orchestrator, from any platform, trusts to handle customer data correctly. That is a fundamentally different product strategy, engineering roadmap, and go-to-market motion than anything a traditional SaaS company is running today.

The Orchestrator as the New OS. Take the separation of concerns one level further and a striking implication emerges: the orchestrator is not just a coordinator in a software architecture. It is the new operating system. Just as Windows and macOS became the layer that managed hardware resources on behalf of applications, the orchestrator becomes the layer that manages intelligence resources on behalf of the user deciding which subagents to invoke, when to invoke them, how to sequence their outputs, and how to maintain coherent state across a long-running goal.

And if the orchestrator is the OS, then the most natural place for it to run is locally. Not in a data center, not behind an API call with 200ms of network latency but on the device, always on, always aware of context, operating with the intimacy of something that lives close to the user’s own cognitive loop. This points toward a hardware and software bet that several labs and chip designers are quietly making: a small, highly capable model compact enough to run on a phone or laptop, smart enough to reason about goals and delegate effectively sitting permanently resident on-device as the user’s personal orchestration layer. It knows your calendar, your files, your preferences, your ongoing tasks. It does not do everything itself. It is not trying to be GPT-5. Its job is to be an exceptionally good delegator: to understand what you need, decompose it into addressable goals, route each goal to the right specialist subagent over the network, and stitch the outcomes back into something coherent and useful.

This reframes the device wars entirely. The prize is no longer who ships the fastest chip or the sharpest display. It is who ships the best resident orchestrator the local model that sits at the center of a user’s agent network the way the kernel sits at the center of an operating system. Apple, Google, Qualcomm, and a handful of AI-native startups are all, in some form, converging on this position. The on-device model is not a feature. It is the platform. 4: The New Moat: What Holds Value When Code Is Free

Code, as a category of competitive advantage, is being commoditized at an accelerating pace. The cost of writing integration logic is approaching zero. The cost of boilerplate microservices is approaching zero. In a world where any reasonably capable model can scaffold a working service in seconds, value cannot live in the code itself. It has to live in something harder to replicate.

This is where the human analogy becomes the most instructive framework available to us. The workforce has been wrestling with “what holds value when general capability becomes cheap?” for centuries. The answer is always the same: scarcity. Not the scarcity of effort, but the scarcity of specific, hard-won, non-transferable capability the surgeon who has performed ten thousand of a specific operation, the negotiator who knows every player in a particular market, the fixer who has relationships no org chart captures.

The SaaaS economy will produce four analogous categories of durable competitive advantage.

The Ultra-Specialists (Deep Domain Expertise). These are subagents with narrow, irreplaceable expertise in a single complex domain, e.g., a regulatory compliance agent built specifically for EU pharmaceutical filings, a subsurface geology modeling agent trained on decades of proprietary drilling data, a clinical trial protocol optimization agent that has ingested every FDA rejection letter from the last twenty years. The domain is so specific that no general model matches the performance, and depth compounds over time.

The Connectors (Routing and Discovery). Some of the most valuable people in any large organization are not the deepest experts they are the people who know exactly who to call for a given problem. Their moat is a map of other people’s expertise. In the SaaaS economy, routing agents that can dynamically match an orchestrator’s need to the right specialist subagent and do it with high accuracy, fast latency, and strong trust signals will accrue disproportionate value. The discovery layer is the talent agency of the agent economy, and whoever builds it well will extract a toll from every transaction that flows through it.

The Gatekeepers (Proprietary Data and Know-How). This is the most immediately familiar moat to enterprise software companies. A Salesforce subagent sitting on top of data from millions of sales processes, a Snowflake subagent with access to proprietary query optimization patterns developed over a decade of production workloads, a Bloomberg subagent with real-time financial data that no LLM has ever been trained on these represent genuine moats that generic intelligence cannot cross. The data advantage is real, but it only materializes if the company is willing to surface it through an agent interface rather than defend it behind a GUI.

The Operators (Durable Execution and Reliability). This is the hardest and most underrated category. Long-running multi-agent jobs fail in complex ways - partial completions, ambiguous states, cascading retries, edge cases that no integration test anticipated. The subagents that build a reputation for completing what they start, maintaining state across failures, and delivering results with verifiable consistency will be extraordinarily difficult to displace. Reliability at scale does not commoditize. The Operator moat compounds the same way uptime reputation compounds for a cloud provider: slowly, and then in your favor entirely.

The most durable moats in the SaaaS economy won’t be built on lines of code. They will be built on the things AI cannot hallucinate: proprietary data, hard-won domain expertise, and the trust earned through years of reliable execution.

5: The Missing Infrastructure: What Needs to Be Built Now

The SaaaS economy is conceptually compelling. But between here and there lies a set of infrastructure gaps so fundamental that they have no satisfying answers today. This is where the most important engineering work of the next five years will happen and where the most durable companies of this era will be built.

Full-Duplex Communication Streams. HTTP request-response was designed for a world where you ask a question and wait for an answer. Subagents need to interrupt mid-execution, push partial results, ask clarifying questions, and renegotiate scope when new information arrives. The A2A and AG-UI protocols are early attempts at this, but production-grade bidirectional agent communication at scale remains an open problem. Building the WebSocket equivalent for agent-to-agent collaboration is one of the most important infrastructure challenges of this decade.

Agent Identity and Ephemeral Authentication. When saaas[.]stripe[.]com attempts to trigger a $50,000 refund on behalf of an orchestrator, the underlying payment system needs to know that this agent has the authority to act, under whose delegation, with what spending limits, and with a full audit trail. Current OAuth patterns assume persistent human principals. Subagents are ephemeral: they are spun up, execute, and disappear. We need identity protocols that issue scoped, time-bounded credentials to agents dynamically not a tweak to existing auth, but a fundamentally different trust model for autonomous, short-lived actors.

Billing Protocols and Agent Wallets. If an orchestrator hires saaas[.]salesforce[.]com to accomplish a task, and that subagent in turn hires saaas[.]snowflake[.]com for a data query, how does money flow? How is it attributed? How does the originating enterprise account for this in its budget? Micro-transaction infrastructure where agents can autonomously pay other agents within policy-defined budgets, with full attribution back to the human principal does not yet exist in any mature form. The agentic web needs its own equivalent of Stripe, and it needs to exist before the economy it enables can operate at scale.

The Discovery Layer. How does an orchestrator know that saaas[.]veeva[.]com is the right subagent for a pharmaceutical compliance task when it has never encountered that task before? Today this routing is hardcoded by a human developer. In a mature SaaaS economy, there needs to be a dynamic registry imagine DNS meets a professional talent network where subagents advertise their capabilities, pricing, SLAs, and earned trust scores in formats that other agents can query and evaluate at runtime. This is the recruiter, the headhunter, and the reference check, automated and running continuously.

Chain-of-Thought Firewalls and PII Guards. When one agent streams its reasoning to another, it may inadvertently expose data that should remain within an organizational boundary. A Salesforce subagent reasoning about a customer’s payment history shouldn’t broadcast that context to a third-party routing agent. Intelligent firewalls that intercept agent-to-agent communication, filter sensitive context, and redact PII before it crosses trust boundaries are a category that barely exists today. In a world subject to GDPR, HIPAA, and their successors, this isn’t a nice-to-have it is a legal prerequisite for the SaaaS economy to function.

Durable Execution and Local State. Agents completing multi-step jobs that run for hours need to maintain context, handle partial failures gracefully, and resume without starting over. A lost state in a multi-agent financial workflow isn’t an annoying page reload it’s a transaction that must be unwound. The reliability manager layer that verifies completed work, runs consistency checks, and provides execution guarantees will be one of the most commercially important pieces of infrastructure built in this era. Think of it as the transactional integrity layer for the agent economy: boring to describe, irreplaceable in practice.

The Runtime Evaluator - A Continuous Step Checker. This may be the most underappreciated layer in the entire stack, and the one that determines whether the SaaaS economy earns the trust it needs to operate at scale. Every other infrastructure layer we’ve described assumes that agents are executing in good faith and getting things approximately right. The Runtime Evaluator is the layer that continuously verifies that assumption in real time and intervenes when it doesn’t hold.

Think of it as the surgical team analogy made infrastructure: the surgeon executes, but the anesthesiologist is watching vitals on every breath, ready to act the moment something drifts outside acceptable range. The Runtime Evaluator does this for agent execution. It sits as a persistent observer across every step of every agent in a workflow not just checking outputs after the fact, but watching the agent’s chain of thought and intermediate actions as they unfold.

In practice, this means running a continuously updated battery of evaluations against the agent’s live execution trace. Factual coherence checks ask whether the agent’s reasoning is internally consistent with the data it has retrieved. Heuristic guardrails flag known failure patterns circular reasoning, confident assertion without evidence, scope creep where an agent begins taking actions outside its delegated domain. Sensitivity classifiers catch the moment a subagent is about to write to a production database, execute an irreversible financial transaction, or send an outbound communication and enforce a confirmation gate before the action proceeds. Anomaly detectors compare the current execution against a statistical baseline of what normal execution looks like for this agent in this context, surfacing deviations that don’t match any known failure mode but don’t feel right either.

Crucially, the Runtime Evaluator doesn’t just alert. It acts. When a step fails a heuristic check, it can pause execution and request human confirmation. When an agent’s reasoning drifts, it can inject a corrective prompt directly into the agent’s context the equivalent of a colleague tapping you on the shoulder mid-calculation and saying “I think you’ve got the wrong figure on line three.” When a subagent is about to perform a sensitive action it wasn’t explicitly authorized for, it can block the action, log it, and escalate.

The deepest value of this layer is what it enables organizationally: it is the infrastructure that allows companies to grant agents meaningful autonomy without gambling on their reliability. The obstacle to deploying autonomous agents in high-stakes workflows today isn’t capability in many domains, the agents are already capable enough. The obstacle is trust. The Runtime Evaluator is the mechanism that makes trust earnable, verifiable, and incrementally extendable. It is the difference between “we let agents send emails on our behalf” and “we let agents negotiate contracts on our behalf” the latter only becomes possible when every step of the negotiation is being watched, scored, and corrected by a layer that never blinks. Each layer depends on the one beneath it. You cannot build a trustworthy billing protocol without agent identity. You cannot build a reliable execution layer without a step evaluator watching it continuously. The infrastructure stack has a dependency order, and critically, the Evaluation Layer sits above communications and below execution for a deliberate reason: every action an agent takes should pass through an evaluation checkpoint before it lands in the execution layer that makes it real.

6: The Agent Network in Action

A high-value enterprise customer, Acme Corp, hasn’t responded to renewal outreach in 14 days. Their product usage dropped 60% last month. The goal: reduce churn risk.

The Orchestrator receives this goal in natural language. It does not write SQL. It does not consult an API specification. It does not call a webhook. It reasons about the goal and delegates. It opens a stream to a Discovery subagent, describes what it needs “understand a B2B customer’s health signal across CRM and product usage data” and receives back a ranked shortlist of available subagents. It selects saaas[.]salesforce[.]com based on trust score and SLA, and opens a duplex stream.

saaas[.]salesforce[.]com takes the goal and works. It queries the CRM, handles pagination invisibly, hits a 429 rate limit, backs off, retries, and returns its finding: the account’s last support ticket was unresolved for 18 days, an escalation was missed, and the primary contact expressed frustration in the final call notes. The orchestrator never saw the retry loop. It saw the outcome.

Mid-stream, the Salesforce subagent asks a clarifying question back to the orchestrator: “Should I include confidential notes from the account executive’s last call?” The orchestrator evaluates this against the user’s data policy and responds: “Yes, but filter anything marked attorney-client.” The PII firewall intercepts the outgoing stream and validates compliance before the context crosses the trust boundary.

saaas[.]stripe[.]com receives the diagnosis and autonomously calculates a remediation offer: a three-month SLA credit. It drafts the credit memo, routes it through the appropriate approval workflow as configured by the enterprise, and issues it without exposing Stripe’s internal billing schema to any other agent in the network.

saaas[.]hubspot[.]com composes a personalized outreach email referencing the specific issue and its resolution, selects the optimal send time based on the contact’s engagement history, and schedules a follow-up check-in for seven days out.

The orchestrator reports back to the user: “Churn risk mitigated. Root cause: missed escalation. Actions taken: SLA credit issued, personalized follow-up sent, check-in scheduled.” The user never saw an API call, a retry, a schema conflict, or a rate limit. They saw a goal pursued and an outcome delivered.

Notice that in this scenario, Salesforce, Stripe, and HubSpot are not software applications that a human logs into. They are specialist firms - entire companies whose business model is being the most capable, most trusted subagent in their domain. Their competitive strategy is not “build the best dashboard.” It is “become the subagent that every orchestrator defaults to for CRM work” the same way AWS became the default for compute and Stripe became the default for payments. The prize for winning that position in the SaaaS economy is enormous, and the window to establish it is narrowing.

7: The Business Model Implications

The SaaS revenue model is built on users - seat licenses, monthly active users, dashboard logins, engagement metrics. Every pricing model, every product decision, and every growth motion in the SaaS era was ultimately optimized around human attention. The more time a human spent inside your product, the more value you could extract and the harder you were to replace.

In the SaaaS model, there are no users. There are only outcomes. An orchestrator doesn’t log in. It doesn’t get onboarded. It doesn’t attend your webinar or respond to your NPS survey. It calls your subagent, evaluates whether the outcome was delivered accurately and on time, and routes future work accordingly or it doesn’t, if a competitor subagent consistently performs better.

This is a pricing model built entirely on value delivered, not access granted. It resembles professional services more than software subscriptions: you pay for results, not for the right to sit in the waiting room. The companies that navigate this transition successfully will need to answer several uncomfortable questions. What is the measurable outcome your subagent delivers? How quickly? With what reliability guarantee? At what cost per outcome? And critically: what does your subagent know or do that a general AI model cannot replicate on its own?

Companies that own neutral orchestration platforms will capture enormous value, and companies that supply unique data and specialized execution capabilities will also capture value but the companies stuck in the middle, selling software that was primarily a UI layer on top of generic data, will find their products bypassed entirely. Agents are not users. They will not click through a dashboard to get what they need. They will find a subagent that delivers the same outcome in a single stream call, and they will route there permanently.

The transition from monoliths to microservices changed how we build software. The transition to SaaaS will change how software acts - and more importantly, how it is sold, priced, and competed over.

8: Conclusion: Who Builds the Next Decade

Every foundational shift in software infrastructure creates a narrow window during which the dominant players of the next era are established. The companies that built cloud-native from the ground up in 2008 didn’t just survive the shift from on-premise they displaced incumbents who had spent decades accumulating advantages. The pattern is consistent: new infrastructure paradigms create asymmetric opportunities for those who commit to them early and catastrophic disadvantage for those who treat them as incremental updates to existing strategies.

There is a quieter and arguably more important set of opportunities: the infrastructure primitives that the entire economy depends on. The identity and authentication layer for ephemeral agents. The billing and micro-transaction protocols. The discovery and routing registry. The PII firewall. The durable execution runtime. None of these exist in production-grade form today. All of them are prerequisites for the SaaaS economy to reach its potential. The teams who build them will be extraordinarily difficult to displace not because they will have network effects or switching costs in the traditional sense, but because the entire economy will be built on top of them, the way the entire internet is built on top of TCP/IP.

The internet was built for screens. The next layer of the internet will be built for agents. The question every engineering leader should be asking right now is not “how do we add AI to our product?” It is a harder, more fundamental question: if our product’s primary consumers were agents rather than humans, what would we build differently, starting today?