Satya's App-ocalypse, Saved by MCP
"The notion that business applications exist, that's probably where they'll all collapse in the agent era."β
If you haven't seen this interview yet, it's well worth watching. Bill and Brad have a knack for bringing out insightful perspectives from their guests, and this episode is no exception.
How does SaaS collapse?β
Satya refers to how most SaaS products are fundamentally composed of two elements: "business logic" and "data storage". To vastly oversimplify, most SaaS architectures look like this:
Satya proposes that the upcoming wave of agents will not only eliminate the UI (designed for human use, click-ops style), but will also move the "CRUD" (Create - Read - Update - Delete) logic entirely to the LLM layer. This shifts the paradigm to agents communicating directly with databases or data services.
As someone who has built many systems that could be reduced to "SaaS", I believe we still have significant runway where the CRUD layer remains separate from the LLM layer. For instance, getting LLMs to reliably handle user authentication or consistently execute precise domain-specific workflows requires substantial context and specialization. While this logic will persist, certain layers will inevitably collapse.
The Collapse of the UI (as we know it)β
Satya's key insight is that many SaaS applications won't require human users for the majority of operations. This raises a crucial question: in a system without human users, what form does the user interface take?
This transformation represents a fundamental shift, where the Model Context Protocol (MCP) will play the biggest role in software since Docker.
The agent becomes the UI.β
However, this transition isn't automatic. We need a translation and management layer between the API/DB and the agent using the software. While REST APIs and GraphQL exist for agents to use, MCP addresses how these APIs are used. It also manages how local code and libraries are accessed (e.g., math calculations, data validation, regular expressions, and any code not called over the network).
MCP defines how intelligent machines interact with the CRUD layer. This approach preserves deterministic code execution rather than relying on probabilistic generative outputs for business logic.
Covering Your SaaSβ
If you're running a SaaS company and haven't considered how agent-based usage will disrupt the next 1-3 years, here's where to start:
-
Reimagine your product as purely an API. What does this look like? Can every operation be performed programmatically?
-
Optimize for machine comprehension and access. MCP translates your SaaS app operations into standardized, machine-readable instructions. Publishing a Servlet offers the most straightforward path to achieve this.
-
Plan for exponential usage increases. Machines will interact with your product orders of magnitude faster than human users. How will your infrastructure handle this scale?
While the exact timeline remains uncertain, these preparations will position you for the inevitable shift in how SaaS (and software generally) is consumed in an agent-driven world. The challenge of scaling and designing effective machine-to-machine interfaces is exciting and will force us to think differently.
The Next Mode of Software Deliveryβ
There's significant advantage in preparing early for agent-based consumers. Just as presence in the Apple App Store during the late 2000s provided an adoption boost, we're approaching another such opportunity.
In a world where we're not delivering human-operated UIs, and APIs aren't solely for programmer integration, what are we delivering?
MCP-based Deliveryβ
If today's UI is designed for humans, and tomorrow's UI becomes the agent, the architecture evolves to this:
MCP provides the essential translation layer for cross-system software integration. The protocol standardizes how AI-enabled applications or agents interact with any software system.
Your SaaS remains viable as long as it can interface with an MCP Client.β
Implementation requires developing your application as an MCP Server. While several approaches exist, developing and publishing an MCP Servlet offers the most efficient, secure, and portable solution.
As an MCP Server, you can respond to client queries that guide the use of your software. For instance, agents utilize "function calling" or "tool use" to interact with external code or APIs. MCP defines the client-server messages that list available tools. This tool list enables clients to make specific calls with well-defined input parameters derived from context or user prompts.
A Tool follows this structure:
{
name: string; // Unique identifier for the tool
description?: string; // Human-readable description
inputSchema: { // JSON Schema for the tool's parameters
type: "object",
properties: { ... } // Tool-specific parameters
}
}
For example, a Tool enabling agents to create GitHub issues might look like
this:
{
"name": "github_create_issue",
"description": "Create a GitHub issue",
"inputSchema": {
"type": "object",
"properties": {
"title": { "type": "string" },
"body": { "type": "string" },
"labels": { "type": "array", "items": { "type": "string" } }
}
}
}
With this specification, AI-enabled applications or agents can programmatically
construct tool-calling messages with the required title, body, and labels
for the github_create_issue tool, submitting requests to the MCP
Server-implemented GitHub interface.
Prepare Nowβ
Hundreds of applications and systems are already implementing MCP delivery, showing promising adoption. While we have far to go, Satya isn't describing a distant futureβthis transformation is happening now.
Just as we "dockerized" applications for cloud migration, implementing MCP will preserve SaaS through the App-ocalypse.
The sooner, the better.
If you're interested in MCP and want to learn more about bringing your software to agent-based usage, please reach out. Alternatively, start now by implementing access to your SaaS/library/executable through publishing to mcp.run.
