Part 3 of "The Great Decoupling" series
In Part 1, I argued that interfaces are becoming ephemeral — generated on demand rather than shipped as products. In Part 2, I extended this to enterprise architecture: internal and external systems becoming equivalent capability providers in a unified graph.
Now we arrive at the uncomfortable implication that makes SaaS executives lose sleep: if capabilities standardize and interfaces disappear, what's left?
The traditional answer has been data. SaaS vendors have spent decades building moats around the data they accumulate. But capability-first architecture doesn't just commoditize interfaces — it inverts the entire data ownership model.
This is the correction we've been deferring since the cloud transition began. And it cascades further than most people realize.
The Data Hostage Problem
Let me be direct about how the current model works.
The SaaS playbook for the last two decades has been: capture user activity → accumulate data → create switching costs → defend margins. Your CRM doesn't just store your CRM data; it stores your institutional memory — every interaction, every deal progression, every customer relationship pattern. Your HR platform doesn't just process payroll; it accumulates your entire workforce history. Your messaging platform doesn't just enable communication; it becomes the searchable archive of your company's conversations.
This accumulation isn't incidental. It's the strategy. The data becomes the moat. The more you use the product, the more painful it becomes to leave. That's not a bug — it's the business model.
I'm not suggesting SaaS vendors are villains. The model emerged naturally from the technology constraints of the era. Cloud storage was the obvious place to put data. Vendors had economies of scale. Users got convenience. The dependency accumulated gradually, and by the time anyone noticed, migration was prohibitively expensive.
But let's call it what it is: your data is being held hostage. Not maliciously, but structurally. The architecture creates lock-in regardless of anyone's intentions.
The Moat Becomes Visible
Capability-first architecture makes this hostage situation visible in ways it wasn't before.
In the current model, the data lock-in is hidden behind the interface. You interact with Meridian — I'm using a fictional CRM name here, but you know the real players — through Meridian's screens. The data feels like part of the application because you only access it through the application. The dependency is obscured by the experience.
But when an AI agent tries to invoke capabilities across your enterprise graph, the friction becomes obvious. The orchestrator asks for customer data. Meridian's capability responds with rate limits, restricted fields, export limitations — friction designed to keep data inside. The agent can't do what it needs to do. The human notices.
The question shifts from "why would I leave Meridian?" to "why is Meridian limiting what I can do with my own data?"
This visibility changes the power dynamic. Enterprises start asking uncomfortable questions:
- Why can't we query our own data through any interface we choose?
- Why does exporting our information require special negotiations?
- Why does the vendor's capability respond differently when the consumer is our AI rather than their UI?
The moat that felt like a reasonable trade-off starts feeling like an imposition.
The Inversion
Here's the strategic inversion that I believe is coming:
- Old logic: "We have your data, so you can't leave."
- New logic: "You're holding our data hostage, so we're routing around you."
Enterprises will demand — and regulators will likely mandate — data portability and capability interoperability. The vendors who get ahead of this, positioning themselves as trusted capability providers rather than data jailers, may actually strengthen customer relationships. The ones who cling to the moat strategy will find themselves disintermediated.
This mirrors what happened to telecom carriers. They thought owning the pipes meant owning the value. Then over-the-top services routed around them, and they became commodity infrastructure. The carriers who adapted — treating themselves as connectivity providers rather than destination services — survived. The ones who fought it lost.
SaaS vendors face the same unbundling risk. The question is whether they recognize it in time.
Capability Without Custody
The architectural solution is straightforward in concept, though challenging in implementation: separate capability from custody.
Today's MCP server typically bundles capability and data together. The Meridian MCP server provides CRM capabilities and holds CRM data. These feel like one thing because they've always been one thing.
But they don't have to be.
In this model, the capability provider offers the logic — the operations, the business rules, the AI models, the domain expertise. But the data lives where the enterprise controls it — their data lake, their sovereign storage, their terms.
The capability provider receives delegated, scoped, revocable access to perform operations. They can't hold data hostage because they never hold the data. When the enterprise revokes access, the provider has nothing to retain.
This solves the sovereignty problem structurally, not contractually. Today, enterprises fight data custody battles through legal agreements — DPAs, contractual export rights, and negotiated SLAs. That's fighting the architecture with lawyers. In the capability-first future, the architecture enforces sovereignty. The provider physically cannot retain data beyond the granted scope because the data layer isn't theirs.
The Sovereignty Cascade
Here's where the implications cascade beyond enterprise boundaries.
If enterprises can reclaim data sovereignty from SaaS vendors, the same pattern extends to individuals reclaiming data from enterprises. The logic is identical; only the scale changes.
The ownership model inverts at every layer. SaaS vendors become capability providers with delegated access. Enterprises own their domain data and access user data through delegation. Users own their personal data and grant scoped, revocable access to enterprises and services.
This isn't hypothetical — the legal and regulatory pressure already exists. GDPR's right to data portability. CCPA. The EU Data Act. Apple's App Tracking Transparency. These regulations push toward exactly this end state. What's been missing is the architecture to actually deliver on the rights they promise.
Capability-first architecture provides that missing architecture.
The Personal Data Layer
Let's follow the cascade to its conclusion: user-owned data with capability-based access.
Imagine:
- Your professional identity, skills, work history — you own it, not LinkedIn
- Your health records — you own them, not Epic or your insurance company
- Your financial transactions — you own them, not your bank
- Your AI assistant's memory of you — stored in your data layer, not the AI provider's servers
When you interact with an enterprise system, you grant delegated access to the relevant slice of your data. When you leave that job, you revoke access. When you switch doctors, you don't "request your records" — you redirect the delegation. When you switch AI providers, your context comes with you.
But what does this personal data layer actually look like? Here's my hypothesis: it's the evolution of something people already use without thinking about it — cloud drives.
OneDrive, Google Drive, Dropbox — people already store "their stuff" in these services. They already understand sharing with granular permissions. They already trust the providers. They already use them across devices without friction.
This is an oversimplification, of course — the technical, regulatory, and trust challenges of true personal data sovereignty are substantial. I'm using the cloud drive analogy as a mental model, not a complete architecture. The point is that the behavioral patterns already exist. People already think of cloud storage as "theirs." The evolution is in what that container holds and how other systems interact with it.
The behavior is established. What evolves is what gets stored:
Structured personal data becomes just more "files" in your drive. The delegation model is just "sharing" with more granular permissions. Users don't need to understand the paradigm shift — they just notice that more things work the way file sharing already works.
No new behavior to learn. No new trust to establish. Just a gradual expansion of what "your cloud drive" means.
You Become a Client of Your Own Data
Here's the crucial architectural detail: you don't access this data directly. It's wrapped in your own personal MCP server.
The symmetry is elegant: when your bank queries your income verification, and when you ask "what did I spend on groceries last month?" — both requests go through the same capability interface. You're not special. You're just another authorized client with a particular scope.
This solves problems that aren't obvious until you see the architecture:
Consistent access control: You define delegation rules once. They apply to everyone — including apps acting on your behalf. No separate "app permissions" vs. "sharing settings" vs. "privacy preferences." One model.
Complete audit trail: Every access — external or personal — is logged. You can see exactly who or what touched your data, when, and for what purpose. "Show me everyone who accessed my health records this year" becomes a simple query.
AI memory done right: Your AI assistant's "memory" of you isn't stored in OpenAI's or Anthropic's servers. It's stored in your data layer. The AI queries it via delegation, the same as any other client. Switch providers? Your context comes with you.
The "files" abstraction fades: You stop thinking in terms of documents and folders. You think in terms of questions and capabilities:
- "What's my current health insurance coverage?" (not "open Benefits folder, find policy PDF")
- "Share my verified income with the mortgage lender" (not "download statement, upload to portal")
- "What commitments do I have Thursday?" (federated query across calendar, email, tasks)
The OAuth Mental Model, Scaled
If this sounds familiar, it should. It's the OAuth mental model — the one users already understand — scaled to all personal data.
When you click "Sign in with Google," you understand: you're granting this application scoped access to your Google identity. You can revoke it anytime. Google doesn't give them your password; it delegates specific permissions.
Users get this. They've been trained by a decade of OAuth flows. The capability-first personal data layer extends the same mental model:
- OAuth today: "I grant this app access to my Google identity."
- Capability-first future: "I grant this service access to my financial history for income verification."
Same pattern. Same mental model. Same trust framework. Just more data types, more granular scopes, and universal application.
This is what Web3 promised but couldn't deliver. The blockchain community correctly identified data sovereignty as a crucial problem. But they solved the wrong technical challenge — trustless consensus — instead of the right one — capability-based delegation over sovereign data stores.
MCP, whatever it evolves into, has cracked open the right problem. The specific protocol details will mature and change. But the pattern — standardized capability invocation with delegated, scoped, revocable access — that's the foundation. The door to Web3 couldn't open, but MCP has opened.
The Governance Layer
All of this — enterprise data sovereignty, personal data ownership, delegated access — requires a governance layer that doesn't quite exist yet.
The orchestration layer we discussed in Part 2 becomes more than just a router. It manages a delegation graph — who has granted access to what, under what constraints, for how long.
This governance layer is where real power concentrates in the new architecture. Whoever operates it sees the delegation graph — the map of who trusts whom with what. That's metadata about data relationships. It's arguably more valuable than the data itself.
Which raises the question we've been building toward: who operates this layer? Who wins the platform war that determines the shape of capability-first computing?
That's Part 4.
The Stakes
I want to be clear about why this matters beyond architectural aesthetics.
The current data custody model has consequences. Users can't easily switch services because their history is trapped. Enterprises can't easily negotiate with vendors because migration costs are prohibitive. Innovation is constrained because new entrants can't compete with incumbents' data accumulation. Privacy is an afterthought because the architecture assumes vendors hold everything.
The capability-first model with data sovereignty inverts these dynamics. Users own their context and carry it between services. Enterprises own their operational data and select capability providers on merit. New entrants can compete because they don't need to accumulate data moats — they just need to provide better capabilities. Privacy becomes architectural because data stays with its owner by default.
This isn't utopian. There will be new problems, new power concentrations, new forms of friction. But they'll be different problems — arguably better problems — than the ones created by the current custody model.
The correction has been deferred for twenty years. The capability-first architecture makes it possible. Whether we actually achieve it depends on what gets built next.
Final installment: **The Great Decoupling: The Platform War and What to Build Now* — Why the orchestration layer is the defining battle of the next era*
References
SaaS Business Model Disruption: Bain & Company analysis on how agentic AI threatens traditional SaaS models and per-seat pricing. Source: Bain & Company - Will Agentic AI Disrupt SaaS?
Per-Seat Pricing Evolution: Analysis of how AI is forcing SaaS companies to reconsider pricing models. Tomasz Tunguz of Theory Ventures: "What does a software seat mean when a human is no longer operating the software?" Source: Bain & Company - Per-Seat Software Pricing
Enterprise SaaS Pricing Evolution: Major CRM vendors have experimented with per-conversation pricing for AI agents, with some pivoting back to seat-based licensing due to customer demand for predictability. Source: The Register - Salesforce AI Pricing
AI Agent Pricing Models: Overview of emerging pricing approaches including per-conversation, per-resolution, and hybrid models. Source: AIMultiple - From Traditional SaaS-Pricing to AI Agent Seats
GDPR Human-in-the-Loop Requirements: GDPR Article 22 requires "meaningful human intervention" for automated decision-making affecting individuals. Source: Medium - The Human-in-the-Loop Legal Defense
OAuth History and Evolution: OAuth emerged in 2006 when Twitter needed API delegation capabilities, reaching critical mass in 2010 when Twitter required all third-party apps to use OAuth. Source: OAuth.net - Introduction
Enterprise Data Access Risks: 86% of enterprises need tech stack upgrades for AI agent deployment, and 42% require connections to 8+ data sources. Source: Help Net Security - AI Agents Organization Risk
Top comments (0)