Forem: Jay Desmarais

[Boost]

Jay Desmarais — Fri, 20 Feb 2026 16:54:07 +0000

The Case for Humans as Creators in an AI-Driven World

Jay Desmarais ・ Feb 20

The Case for Humans as Creators in an AI-Driven World

Jay Desmarais — Fri, 20 Feb 2026 16:53:21 +0000

What If We're Not Being Replaced? The Case for Humans as Creators in an AI-Driven World

Every time another AI doom-sayer gets screen time—every time I see another op-ed about how artificial intelligence will be the end of human relevance—I cringe. Not because the risks aren't real. They are, and the instinct to worry about what happens to us when machines can write code, diagnose disease, generate art, and operate robots with increasing dexterity is deeply human. But the conversation is so lopsided. There are so many voices painting a dark picture of what AI brings, and not nearly enough asking the question I can't stop asking: what if this is the most significant expansion of human creative potential in history? What if the "what if" worth exploring isn't "what if AI takes everything?" but rather "what if AI gives us everything we need to become what we've always had the potential to be?"

Let me paint a picture.

The Core Problem With the Doom Narrative

The traditional response to every major technological leap has been fear of displacement. And historically, that fear has been partially justified—transitions are messy, people do get hurt, and institutions are almost always too slow to adapt. I don't discount any of that. I don't dismiss the AI safety researchers, the economists warning about labor disruption, or the ethicists raising alarms about power concentration. These are serious people doing serious work, and the risks they outline are real.

But here's a crucial difference between acknowledging risk and letting risk define the entire narrative. The doom framing treats humanity as a static thing—a fixed set of capabilities that either gets matched and replaced, or doesn't. What I've come to appreciate deeply is that this fundamentally misunderstands what humans are. We're not a bundle of skills competing with machines. We're the ones who decide what's worth doing in the first place.

The fundamental problem with the replacement narrative is that it confuses execution with intention. AI can optimize, iterate, analyze, and produce at superhuman speed. What it doesn't do—what it fundamentally can't do—is wake up one morning and decide that something matters.

The Pattern: Every Offload Has Made Us More, Not Less

Here's a pattern I've come to appreciate deeply, and it repeats so consistently throughout history that I think it qualifies as something close to a law.

Every time humans have offloaded cognitive drudgery to a tool, the ceiling of what we could explore rose dramatically. Writing freed us from the limits of memory. The printing press democratized knowledge beyond monasteries and royal courts. Calculators didn't kill mathematics—they let mathematicians tackle problems that were previously unthinkable. Computers didn't replace thinkers; they gave thinkers superhuman reach.

Same pattern, different century.

Now consider what happens when that pattern reaches its logical extreme. AI that can match or exceed human cognitive performance across domains, combined with robotics that handles the physical execution. At first glance, this might seem like the moment the pattern breaks—the moment there's nothing left for humans to do. But there's a crucial difference this time that actually makes the pattern stronger: the offload is so comprehensive that it frees humans from both mental and physical drudgery simultaneously.

The theory then is this—when you remove both the cognitive grind and the physical labor, what remains isn't emptiness. What remains is the essence of what makes human experience valuable: curiosity, taste, meaning, connection, wonder, and the stubborn desire to explore something simply because it's there.

The Human as Creator: Closing the Gap Between Vision and Reality

Here's where things get particularly interesting.

Think about what a musician endures today. Years—sometimes decades—of technical practice before the instrument becomes transparent enough to express what they actually hear in their mind. There's a gap between the vision in your head and your ability to manifest it in the world, and that gap is often measured in years of grinding technical skill acquisition.

Now imagine that gap effectively disappearing.

Not because the musician is replaced—the AI doesn't have a song it's burning to write. But because the musician can now go from internal vision to external reality with AI as the bridge. The creative impulse, the emotional truth, the thing that makes a piece of music resonate with another human being—that's still entirely human.
Take for example a scientist who has an intuition—a hunch, really—about some mechanism in molecular biology. Today, testing that hunch might take a five-year research program, grant applications, lab work, peer review. In a world where AI can rapidly model, simulate, and iterate on hypotheses, that same scientist becomes exponentially more powerful. Not replaced. Amplified. The creative act—the intuition, the question that nobody thought to ask—that's still irreducibly human.

The beauty here is that this isn't limited to elite creators. Every person walking around with an idea they can't quite execute, a vision they can't quite build, a curiosity they can't quite pursue because the barriers to entry are too high—those barriers start to dissolve.

One human imagination, infinite execution capacity, zero gap between vision and reality.

Exploration Without Limits

Now let's talk about what happens when you combine this creative amplification with the material abundance that AI-driven automation could produce.

If the production of goods, infrastructure, energy, and services becomes dramatically cheaper and more efficient, then the resources available for exploration—in every sense of the word—expand enormously. Space isn't just for government agencies and billionaires anymore. Deep ocean research isn't constrained by the economics of submarine engineering. Building entirely new kinds of communities, institutions, and ways of living becomes possible because the cost of experimentation drops to near zero.

Imagine a world where someone says "I want to build a self-sustaining community on the ocean" or "I want to explore what's beneath the ice of Europa" and the limiting factor isn't money, manufacturing, or engineering expertise—it's whether the idea is compelling enough to pursue. Humans become the ones choosing where to go and why, which are fundamentally creative and philosophical acts. AI handles the how.

This is the part that genuinely excites me. The exploration isn't just physical. It's intellectual, artistic, spiritual. When survival and productivity pressures ease, civilizations have historically produced their most extraordinary cultural output. Athens. The Renaissance. The creative explosions that followed periods of broad prosperity. What we're talking about is that dynamic at civilizational scale—and unlike those historical examples, not limited to a privileged aristocratic class.

But What About the Risks? (Yes, I've Thought About Them)

I want to be clear about something: looking through an optimistic lens doesn't mean closing your eyes.

The transition period matters enormously. Whether this shift happens over five years or fifty changes almost everything about how manageable it is. Power concentration—where a small number of entities control AI systems that can outthink any human strategist—is a genuine and serious threat. The question of how wealth and resources get distributed when labor is no longer the primary mechanism for accessing economic value is perhaps the defining political challenge of the coming decades.

I hold all of this alongside the optimism. These aren't contradictions. The risks are real precisely because the potential is so transformative. You don't get concerned about the governance of something that doesn't matter.

What I'm choosing to do—and what I'd encourage others to consider—is to let the risks inform our preparation without letting them define our imagination. The doom narrative, taken to its extreme, becomes a kind of learned helplessness. If the future is inevitably terrible, why bother shaping it? I reject that framing entirely.

The Elephant in the Room: Singularity

Now let's talk about the big one—the scenario that fuels most of the existential dread. The singularity. The idea that AI reaches a threshold of self-improving intelligence where it surpasses human understanding entirely, accelerates beyond our ability to control it, and—depending on who you ask—either ignores us, subjugates us, or optimizes us out of existence. It's the premise of most AI doom-sayers, and I'd be intellectually dishonest if I didn't address it head-on.

Here's what I'll say: I understand why this scenario captures the imagination. It's compelling precisely because it follows a certain internal logic. If intelligence can improve itself, and each improvement makes the next improvement faster, you get a runaway curve that humans can't keep up with. Game over. Humanity loses control. Roll credits.

But there's a crucial difference between a compelling thought experiment and an inevitability.

The singularity narrative assumes that raw intelligence—disconnected from values, context, and purpose—is the only variable that matters. It treats intelligence as a single axis that just goes up, and once it's high enough, nothing else counts. Now, I'm not an AI researcher or a singularity expert—but something in my gut pushes back on this. It feels like an incomplete picture. Intelligence doesn't operate in a vacuum. It operates within systems—economic systems, governance structures, social contracts, physical infrastructure—all of which are shaped by human choices made before any hypothetical singularity arrives.

This is why I believe the work happening right now in AI safety, alignment, and governance isn't a footnote—it's the main story. The researchers working on ensuring AI systems remain aligned with human values aren't just hand-wringing about a theoretical problem. To me, they're doing some of the most important work of our generation. And the fact that this work is happening now, while we still have the ability to shape these systems, is itself a reason for measured optimism.

Here's the thing that the singularity doomsday framing often glosses over: we're not passive observers watching an asteroid approach. We're the ones building these systems. Every architecture decision, every alignment technique, every governance framework put in place today is a deliberate act of shaping what AI becomes. Maybe I'm being too optimistic here, but the idea that we'll just accidentally build something that escapes all constraints feels like it discounts the enormous and growing effort specifically dedicated to making sure that doesn't happen.

Could something still go wrong? Of course. I'm not naive about that. But "something could go wrong" is true of every transformative technology humanity has ever developed, from nuclear energy to genetic engineering. The answer has never been to stop building. The answer has always been to build responsibly, with eyes wide open—and that's exactly what I see happening across the AI research community.

I choose to put my energy toward the version of the future where we get this right. Not because failure is impossible, but because success is worth fighting for.

The What-If That Matters

Here's the what-if I keep coming back to: what if we're not at the end of human relevance, but at the beginning of what humanity was always meant to become?

For most of human history, the vast majority of human potential has been consumed by survival. Growing food, building shelter, fighting disease, performing repetitive labor just to keep the machinery of civilization running. The fraction of human creativity that has actually been expressed—turned into art, science, philosophy, exploration—is vanishingly small compared to what was always latent in billions of human minds.

AI and robotics don't replace that latent potential. They unleash it.

The musician who never had time to learn an instrument. The scientist who spent her career on grant paperwork instead of research. The architect whose most ambitious designs stayed in a sketchbook because they were structurally impossible. The kid in a developing nation who has a groundbreaking idea but no access to labs, tools, or capital. Every one of these represents unrealized human creativity—and every one of these barriers is the kind of thing AI and automation can dissolve.

Looking forward, I believe the most important work isn't building the AI itself—brilliant people are already doing that. The most important work is building the social, economic, and governance structures that ensure this amplification reaches everyone, not just those who are already privileged. That's a human problem. A creative problem. A problem of values and vision and political will.

And I find it deeply fitting that the challenge of the AI age turns out to be an irreducibly human challenge.

It's not about predicting the future so much as building in a way that doesn't foreclose it. And the future I want to be part of building—the one I think is genuinely possible—is one where the human role isn't diminished by machines, but elevated by them. Where we stop being laborers and start being, fully and completely, what we've always been at our best: creators, explorers, dreamers with the tools to make those dreams real.

That's the what-if worth asking.

The Great Decoupling: The Platform War and What to Build Now

Jay Desmarais — Sun, 25 Jan 2026 16:35:25 +0000

Part 4 of "The Great Decoupling" series

We've covered a lot of ground in this series. Part 1 argued that interfaces are becoming ephemeral — capability and presentation decoupling permanently. Part 2 extended this to enterprise architecture — internal and external systems becoming equivalent nodes in a unified capability graph. Part 3 followed the implications to data sovereignty — the hostage model inverting as enterprises and users reclaim ownership.

One question has been building throughout: if this architecture emerges, who operates the orchestration layer?

This isn't an academic question. Whoever controls the layer that routes capabilities, manages delegations, and maintains the audit trail occupies the most strategic position in the new software landscape. This is the platform war that will define the next era.

The Orchestration Layer as Power Center

Let's be precise about what the orchestration layer does and why it matters.

In the capability-first architecture, the orchestrator sits between consumers (humans, AI agents, other services) and capability providers (internal systems, external SaaS). It handles:

Discovery: What capabilities exist? What can this identity access?
Routing: Where should this request go? Which provider? Which instance?
Authorization: Can this identity invoke this capability with these parameters?
Delegation management: Who has granted access to whom, under what constraints?
Audit: What was accessed, when, by whom, for what purpose?
Context: What's the session state? What constraints carry forward?

None of these functions is revolutionary individually. API gateways do routing. Identity providers handle auth. Logging systems track access. But the orchestration layer integrates them specifically for capability-based computing, with AI agents as first-class consumers.

The entity that operates this layer sees everything. Not the data itself — that stays with owners under the sovereignty model. But the metadata about data relationships: who's accessing what, how often, through which capabilities, for what purposes. This is the map of trust relationships across the entire enterprise (or across all users, in the personal layer).

That map is extraordinarily valuable. It reveals:

Which capabilities are actually used vs. just purchased
Which data is most accessed and by whom
Where bottlenecks and friction exist
How workflows actually flow across system boundaries
Which providers are reliable vs. problematic

Whoever holds this position can optimize, recommend, intermediate, and eventually shape how capability-first computing evolves.

Who Wins?

Several categories of players are positioning for this layer:

The hyperscalers (AWS, Azure, GCP) have obvious advantages: existing enterprise relationships, infrastructure at scale, capital to invest, and integration with their cloud platforms. Microsoft has embedded MCP into Copilot Studio, Azure API Management, and VS Code. AWS's Bedrock AgentCore includes an MCP gateway. Google's Vertex AI Agent Builder supports both MCP and A2A.

But hyperscalers also have conflicts of interest. If Microsoft operates the orchestration layer, do capabilities hosted on AWS get fair treatment? If AWS operates it, does Azure integration work smoothly? Enterprises are wary of deepening dependency on cloud vendors who already have significant leverage.

Integration platform vendors (MuleSoft, Workato, Boomi) have relevant expertise — they've been connecting enterprise systems for years. Some are owned by larger CRM platforms, positioning them to extend into orchestration. But these platforms were built for a different era of point-to-point integration. Adapting to capability-first, AI-native architectures requires significant evolution.

New entrants positioning as neutral may have the clearest path. The Snowflake playbook — positioning as "not your cloud vendor's data warehouse" — demonstrated that enterprises will pay a premium for perceived neutrality. A new orchestration platform that explicitly avoids cloud vendor lock-in could capture enterprise trust.

Open-source foundations offer another model. Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation, with governance designed to prevent any single vendor from controlling the protocol. The orchestration layer could follow a similar path — an open-source core with commercial distributions, like Kubernetes and its ecosystem.

My intuition is that the orchestration layer needs to be perceived as neutral to achieve enterprise adoption at scale. This favors either the open-source foundation model or new entrants explicitly positioning against incumbent lock-in. The hyperscalers will compete aggressively, but their conflicts of interest create openings.

The Protocol Layer Beneath

The platform war isn't just about who operates the orchestration layer — it's also about what protocols that layer speaks. And here's where it's important to be clear about MCP's role.

MCP is the enabling standard that opened the door. It proved that a capability-first architecture works at scale. It aligned the major players — OpenAI, Google, Microsoft, AWS — around a common pattern. That alignment is the breakthrough, not the specific protocol details.

MCP as it exists today will evolve. The 2029 version may look quite different from the 2026 version. But the doors it opened won't close. The architectural direction is set.

What needs to mature:

Agent-to-agent coordination: When AI agents need to collaborate, they need protocols beyond just invoking capabilities. Google's Agent2Agent (A2A) protocol addresses this — how agents discover each other, negotiate collaboration, and coordinate workflows.

Streaming and subscriptions: Current MCP is primarily request-response. But real-time capabilities need streaming updates and subscription models. "Notify me when inventory drops below threshold" requires different patterns than "tell me current inventory."

Semantic standards: MCP provides transport; it doesn't define what an "order," "customer," or "invoice" means across systems. The semantic layer — shared vocabulary for business concepts — is still fragmented. Whoever establishes semantic standards for key domains gains enormous influence.

Delegation protocols: The OAuth-style delegation we discussed in Part 3 needs protocol-level standardization. How does one entity grant scoped access to another? How are constraints expressed? How is revocation propagated?

The platform war is partly about who controls the orchestration layer and partly about who shapes the protocols that the layer implements. These battles are related but distinct. You can win the protocol war and lose the platform war, or vice versa.

The Timeline: Why 2-3 Years, Not 5-10

The skeptical response to everything in this series is: "Maybe, eventually, but this is a decade-long transformation." I disagree. The timeline compresses because of three interlocking factors.

AI accelerates its own adoption. When capability integration used to take six months, it now takes six weeks because AI assists with building it, and technical bottlenecks dissolve. When AI can help evaluate and select capability providers, procurement cycles shorten. When AI can document and migrate data, switching costs drop. The technology accelerates its own deployment.

Competitive pressure shifts from advantage to survival. The messaging from tech leadership has shifted notably. Jensen Huang, Sam Altman, Satya Nadella — they've all expressed variations of the same message: companies that don't embrace AI transformation face existential risk. Not eventually. Competitively. Now.

When the question shifts from "what's the ROI of this transformation?" to "what's the cost of being disrupted while we deliberate?" — decision-making accelerates. Boards push harder. Procurement cycles compress. "Fast follower" strategies become suicide pacts.

User expectations bleed across contexts. Once users experience contextual rendering in one application — asking Claude for a custom visualization, getting exactly what they need in seconds — they carry that expectation everywhere. They won't tolerate logging into five systems to answer one question. They won't accept fixed dashboards that don't match their mental model. They won't wait for IT to build reports that an agent could generate instantly.

This expectation pressure drives adoption from the bottom up, even as strategic pressure drives it from the top down. The pincer movement compresses timelines.

My estimate: foundational infrastructure solidifies in 2026-2027. Early adopter enterprises deploy capability-first architectures in 2027-2028. Mainstream adoption follows in 2028-2029. By 2029, the frozen interface will feel as dated as the CD-ROM software installation experience feels today.

What Builders Should Do Now

If you're building software today — whether SaaS products, internal enterprise systems, or new ventures — the implications are actionable.

Expose Capabilities, Not Just APIs

Traditional REST APIs expose data operations — CRUD on resources. Capability-first systems expose capabilities — operations with semantic descriptions that AI can reason about.

The difference matters when the consumer is an agent trying to understand what's possible. A well-described capability with clear parameters, examples, and constraints enables AI to invoke it appropriately. A generic REST endpoint requires the AI to guess.

Will the specific MCP protocol details matter in five years? Maybe, maybe not. But the pattern — semantically rich capability definitions that AI can discover and invoke — that's the direction. Build toward the pattern, not just the current spec. Start building capabilities with AI consumption in mind, even if your current consumers are human-operated UIs.

Separate Capability from Presentation

Even if you're building a traditional UI-driven application, architect it so that the capability layer can be consumed independently. This is the viewer/action pattern I described in my earlier post on capability-based architecture.

The test: could an AI agent invoke your core functionality without touching your UI code? If the answer is no, you have architectural coupling that will become technical debt.

Design for Delegated Data Access

Build assuming your capability might operate on data you don't own or store. This changes how you think about state, caching, and persistence.

Instead of: "My service stores customer records and exposes operations on them."

Think: "My service performs customer operations on data that might live anywhere — my database, the customer's data lake, or their personal data store."

This doesn't mean you can't have a database. It means your architecture should accommodate data sources you don't control, with appropriate caching, consistency handling, and fallback behavior.

Make Authorization Capability-Aware

Traditional authorization asks: "Can this user access this endpoint?"

Capability-aware authorization asks: "Can this identity (human or agent) invoke this capability with this scope on this data under these constraints?"

The difference is significant. Capability-aware authorization handles:

Agents acting on behalf of users (with delegated permissions)
Scoped access that varies by data subset
Constraints that travel with delegations (time limits, purpose restrictions)
Audit requirements that track the full delegation chain

Build your authorization model with these requirements in mind, even if your current implementation is simpler.

Invest in Your Semantic Layer

If interfaces become ephemeral and capabilities become standardized, where does differentiation live?

Increasingly, it lives in the semantic layer — the meaning structure of your domain. What does "customer lifetime value" mean in your context? How do "orders," "shipments," and "returns" relate? What business rules govern state transitions?

This semantic layer becomes your moat when capability invocation is commoditized. Anyone can expose a getCustomerValue capability. But the meaning of that value — how it's calculated, what factors it includes, how it predicts behavior — that's your domain expertise encoded as computable structure.

Invest in making your semantic layer explicit, documented, and defensible. It's where your differentiation moves.

The Opportunity in Transition

I want to close with something I find genuinely exciting about this shift.

The capability-first architecture doesn't just redistribute existing value — it creates conditions for new value that couldn't exist before.

Cross-system intelligence becomes possible. When capabilities are composable across system boundaries, AI can reason about your business holistically rather than system by system. The agent that understands your CRM, ERP, and communications platform together can surface insights none of those systems could generate alone.

Workflow creation becomes dynamic. Instead of building integrations between specific systems, users can describe workflows in natural language and have them assembled from available capabilities on demand. "When a high-value customer hasn't ordered in 30 days, alert the account manager and prepare a re-engagement offer" becomes a capability composition rather than an integration project.

New specializations emerge. The orchestration layer, the semantic layer, the rendering layer — these create new categories of tools and platforms. Some of the most valuable companies of the next decade will operate in layers that don't quite exist yet.

Personal agency increases. When users own their data and control delegation, they become genuine participants in the digital economy rather than products being monetized. The business models that emerge will necessarily be more aligned with user interests because users have architectural leverage they currently lack.

The Scaffolding Falls Away

The SaaS interface was never the point. It was a temporary solution to a temporary limitation — humans needed to operate software, and the technology for anything else didn't exist.

MCP didn't create this shift — it revealed it was possible. It opened the door. The specific protocol will evolve, mature, perhaps be superseded by something we can't yet imagine. But the architectural direction is set. Capability-first is the future.

As that future unfolds, the interface becomes what it should have been all along: a rendering choice, generated on demand, adapted to context, owned by no one.

The capability remains. The data — properly owned, properly governed — remains. Everything else was scaffolding.

If you've been building capability-based architectures, you're ahead of the curve. If you haven't, I'd encourage you to start now — not because the future demands it, but because the present does. The chaos of AI transition rewards architectural clarity. The patterns that make your code maintainable today will make it adaptable tomorrow.

And the next time someone asks what your product is — consider whether the answer should be an interface, or a capability waiting to be rendered however your users need it.

This concludes "The Great Decoupling" series. For practical implementation patterns, see my earlier post on Capability-Based Architecture.

References

Current AI Agent Capabilities: Carnegie Mellon's TheAgentCompany benchmark found the best agent tested completed only 24% of realistic office tasks autonomously. Top models hit only 82% accuracy on enterprise document processing. Source: AIMultiple - 12 Reasons AI Agents Still Aren't Ready
Agentic AI Project Failure Rates: Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027 due to unclear ROI and implementation challenges. Source: Gartner Press Release
AI Agent Implementation Challenges: Analysis of early AI agent deployments and common failure modes. Source: Medium - Six Weeks After Writing About AI Agents, I'm Watching Them Fail Everywhere
Microsoft MCP Integration: Microsoft embedded MCP into Copilot Studio, Azure API Management, and VS Code. Source: Wikipedia - Model Context Protocol
OpenAI MCP Adoption: OpenAI brought full MCP support to ChatGPT in September 2025, including "Developer Mode" with read/write capabilities. Source: Nerd @ Work - OpenAI Brings Full MCP Support to ChatGPT
A2A and MCP Complementary Positioning: Google's Agent2Agent protocol addresses agent-to-agent coordination, explicitly positioned as complementary to MCP's tool integration focus. Source: Koyeb - A2A and MCP: Start of the AI Agent Protocol Wars?
Enterprise AI Transformation: Analysis of how AI agents will transform enterprise software, with the prediction that the shift will be gradual rather than sudden. Source: The New Stack - AI Agents Will Eat Enterprise Software, Just Not in One Bite
AI Agent Development Costs: Enterprise AI agent development costs range from $50,000-$500,000+ for enterprise-grade solutions, with ongoing maintenance at 20-30% of initial costs annually. Source: Symphonize - Costs of Building AI Agents
RPA Implementation Lessons: Historical context on why RPA implementations often failed, providing cautionary parallels for AI agent adoption. Source: CIO - Why RPA Implementations Fail

The Great Decoupling: The Data Sovereignty Correction

Jay Desmarais — Fri, 16 Jan 2026 22:54:45 +0000

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

The Great Decoupling: The Enterprise Capability Graph

Jay Desmarais — Fri, 16 Jan 2026 21:33:54 +0000

Part 2 of "The Great Decoupling" series

In Part 1, I argued that we're witnessing the decoupling of capability from presentation — that the SaaS interface, far from being the product, is becoming an ephemeral rendering layer generated on demand. MCP has emerged as the enabling standard for this shift, proving the pattern works and catalyzing industry-wide adoption.

But that's just the first domino.

Here's the question that kept nagging at me: if external SaaS products expose capabilities via MCP, why wouldn't internal enterprise systems do the same? And if they do, what happens to the boundary between "our software" and "their software"?

The answer, I've come to believe, is that the boundary dissolves. Internal and external systems become equivalent nodes in a unified capability graph. And that changes everything about how enterprises think about architecture, vendors, and control.

The Symmetry No One's Talking About

Most discussions of MCP focus on AI agents calling external services — your assistant querying your CRM, pulling data from your document platform, triggering workflows in your automation tools. That's valuable, but it's only half the picture.

The pattern works identically for internal systems. Your custom ERP. Your homegrown analytics pipeline. That sprawling collection of internal tools your platform team maintains. Each of these can expose capabilities through the same protocol.

Once they do, something interesting happens. The orchestration layer — whatever routes requests, manages authentication, handles authorization — stops caring about the origin of capabilities. It routes to get_customer_credit_limit without knowing or caring whether that capability lives in an internal Oracle instance or an external Experian API.

(Meridian is a fictional CRM — a stand-in for the dominant platforms you're already thinking of. The pattern applies regardless of vendor.)

Internal and external become implementation details. The enterprise sees a unified graph of capabilities, some provided internally, some externally, all accessible through the same interface.

This symmetry has profound implications.

Build vs. Buy Transforms

The traditional "build vs. buy" decision pits two options against each other: build a feature internally (control but cost) or purchase a product with a UI your employees learn (faster but lock-in). The comparison involves not just functionality but also interfaces, training, integration work, and long-term dependency.

Capability-first architecture transforms this into expose vs. consume.

Should we build this capability internally or consume it from an external provider? The integration is identical either way — same protocol, same orchestration layer, same developer experience. The evaluation becomes purely about the capability itself: cost, quality, reliability, compliance, and specialization.

This doesn't eliminate the decision's difficulty, but it changes its shape. You're no longer comparing "our custom tool with our custom UI" against "their product with their UI that we need to train everyone on." You're comparing capability providers on capability merits.

And critically, the decision becomes more reversible. If you start with an external capability provider and later decide to build internally, the integration doesn't change. If you build internally and later find a better external option, same story. The orchestration layer abstracts the origin.

This reversibility is strategic gold in the current environment, where the right answer keeps changing.

Capability Architecture as Chaos Survival

Let me paint a picture of the current enterprise reality.

AI capabilities are emerging faster than evaluation cycles can process them. The vendor landscape shifts monthly — acquisitions, pivots, new entrants, sudden deprecations. Build vs. buy decisions that seemed sound six months ago look questionable today. Integration complexity explodes as each new AI tool requires its own connection pattern. Technical debt accumulates from point-to-point connections that made sense at the time.

Every enterprise architect I talk to describes some version of this chaos. The ground won't stop shifting.

Capability-based architecture directly addresses this reality:

Challenge	Capability Architecture Response
Rapid AI evolution	Swap capability providers without rewiring consumers
Vendor uncertainty	Reduce lock-in via standard interfaces
Build/buy fluidity	Internal and external capabilities integrate identically
Integration complexity	Single protocol, not N×M point-to-point connections
Technical debt	Clean abstractions prevent integration spaghetti

This isn't about preparing for some distant future. It's about surviving the present. The patterns that make your architecture maintainable today — isolation, explicit contracts, standard interfaces — are exactly what you need to navigate an environment where the right answer keeps changing.

The pitch to enterprises isn't "adopt this for the future." It's "adopt this to stay agile now."

The Orchestration Layer Emerges

As enterprises deploy capability-based architectures, a new layer crystallizes: the orchestrator.

This isn't just an API gateway or a service mesh, though it shares DNA with both. The orchestrator handles:

Capability discovery: What capabilities are available? What can this identity access? The orchestrator maintains the registry and handles dynamic discovery.

Request routing: When a request comes in, where does it go? The orchestrator routes based on capability type, data residency requirements, load, cost optimization, or custom rules.

Authentication and authorization: Can this identity invoke this capability with these parameters on this data? The orchestrator enforces access control consistently across internal and external capabilities.

Audit and observability: What was invoked, when, by whom, with what parameters, returning what results? The orchestrator maintains the audit trail that compliance requires.

Context management: What's the session state? What permissions were delegated? What constraints apply? The orchestrator maintains context across capability invocations.

The orchestrator becomes the enterprise's control plane for capabilities. Not the capabilities themselves — those remain distributed across internal systems and external providers — but the layer that makes them accessible, governable, and composable.

This is a new category of infrastructure. Not quite an integration platform (though it handles integration). Not quite an AI framework (though it enables AI). Not quite identity management (though it handles identity). It's the connective tissue of the capability-first enterprise.

What Platform Teams Become

If this architecture emerges, the role of enterprise platform teams transforms.

Today, platform teams manage specific systems. "We own the Meridian instance." "We maintain the internal analytics platform." "We run the integration middleware." Each system is a distinct responsibility with its own expertise.

In the capability-first model, platform teams become capability curators. They don't just maintain systems — they curate the capability graph. Their responsibilities shift:

From: Managing the CRM instance
To: Ensuring CRM capabilities are available, performant, and properly governed — regardless of whether those capabilities come from Meridian, a competitor, or internal implementation

From: Building integration pipelines between systems
To: Defining capability contracts and ensuring providers (internal or external) meet them

From: Training users on specific application UIs
To: Ensuring capabilities are discoverable and well-documented for AI and human consumption alike

From: Negotiating vendor contracts for products
To: Evaluating capability providers on capability merits — quality, reliability, cost, compliance

This is a meaningful elevation. Platform teams move from system administrators to capability brokers, from tool maintainers to graph architects.

The Enterprise AI Fabric

Here's where I see this converging. The combination of:

Unified capability graph (internal and external systems equivalent)
Orchestration layer (discovery, routing, auth, audit)
Contextual rendering (interfaces generated on demand)
AI agents (as primary capability consumers)

...constitutes something new. Call it the Enterprise AI Fabric — the connective layer that makes AI-native operations possible.

This fabric enables scenarios that are currently painful or impossible:

Cross-system operations without integration projects: "Update the customer record, adjust their credit limit, and notify the account team" becomes a single orchestrated flow across CRM, financial system, and communication platform — without building a custom integration.

Graceful capability substitution: When a vendor raises prices or degrades quality, swap to an alternative without consumer-side changes. The orchestrator routes differently; everything else continues.

AI agents with appropriate enterprise access: Instead of giving AI tools direct API keys to everything (security nightmare) or nothing (useless), the orchestrator mediates access with proper authorization and audit.

Federated capabilities across organizational boundaries: Partners, suppliers, and customers can expose capabilities into your graph (with appropriate access controls), enabling inter-organization workflows without point-to-point integrations.

The Forcing Function Is Already Here

I want to be clear: this isn't a ten-year vision. The forcing function is already present.

Every major enterprise is grappling with AI adoption. Every one of them is hitting the same walls — how do we give AI access to our systems safely? How do we avoid building N×M integrations? How do we maintain governance while enabling experimentation?

Capability-based architecture is the answer emerging from these pressures. MCP — or whatever it evolves into — is the enabling standard crystallizing from the chaos. The orchestration layer is what enterprises build when they realize they need to manage capabilities systematically.

MCP's current form isn't the point. The point is that it's proven the pattern works, the major players have aligned around it, and the architectural direction is now clear. What MCP looks like in 2028 may be quite different from today — but the doors it opened won't close.

The question isn't whether this architecture emerges. It's whether your enterprise leads or follows.

But There's an Uncomfortable Question

If capabilities become standardized and interchangeable... if interfaces become ephemeral rendering layers... if internal and external systems become equivalent nodes in a graph... where does value live?

For two decades, SaaS vendors have built moats around their data. Your CRM doesn't just provide CRM capabilities — it accumulates your institutional memory. Every interaction, every deal progression, every customer relationship pattern. That's not a feature. That's a hostage.

The capability-first architecture makes this hostage-taking visible. When the orchestrator asks for customer data and the capability responds with friction designed to keep data inside vendor walls, the customer notices.

This leads somewhere uncomfortable for vendors and potentially liberating for enterprises: the data sovereignty question we've been deferring for twenty years.

That's Part 3.

Next in the series: **The Great Decoupling: The Data Sovereignty Correction* — How capability-first architecture inverts the SaaS power structure*

References

Enterprise AI Agent Adoption: G2's August 2025 survey found 57% of companies have AI agents in production, with another 22% in the pilot phase. PwC research shows 79% of organizations have adopted AI agents to some extent. Source: Gupta Deepak - MCP Enterprise Adoption Guide
Multi-Agent System Designs: 66.4% of enterprises use multi-agent system designs rather than single-agent approaches, creating demand for coordination protocols. Source: Gupta Deepak - MCP Enterprise Adoption Guide
Agentic AI Project Challenges: Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 due to unclear ROI and implementation challenges. Source: Gartner Press Release
AWS Agentic AI Security Framework: AWS published the Agentic AI Security Scoping Matrix, defining four security scopes from basic tool use to fully autonomous systems. Source: AWS Security Blog
AI Agent Security Concerns: Gartner predicts 25% of enterprise breaches will trace back to AI agent abuse by 2028. Source: CIO - Autonomous AI Agents = Autonomous Security Risk
MCP and A2A Protocols: Analysis of how MCP (tool integration) and Google's A2A (agent-to-agent coordination) are positioned as complementary rather than competing standards. Source: Koyeb - A2A and MCP: Start of the AI Agent Protocol Wars?

The Great Decoupling: The End of Frozen Interactions

Jay Desmarais — Fri, 02 Jan 2026 16:28:21 +0000

Part 1 of "The Great Decoupling" series

Have you ever stopped to consider why software has a user interface at all?

Not the philosophical "what is an interface" question, but the practical one: why does every SaaS product ship with a specific arrangement of screens, buttons, and workflows that every customer must learn and adapt to?

The honest answer is a historical accident. Software needed interfaces because humans needed to operate it, and the technology for anything else didn't exist. We've spent decades refining these interfaces — better layouts, smoother interactions, more intuitive navigation — without questioning whether the interface itself was the right abstraction.

That assumption is dissolving faster than most people realize.

What I've been exploring recently — and what I believe represents a genuine architectural inflection point — is the emergence of capability-first systems where the interface becomes an ephemeral rendering layer rather than a product feature. This isn't an incremental improvement. It's a fundamental restructuring of what software is.

What follows is my synthesis of where I see this heading — informed by three decades of watching technology transitions play out, but still very much a thesis about the future rather than a description of the present. I've been wrong before, and I'll be wrong again. But I've also learned to recognize when architectural assumptions are shifting beneath us, and I believe we're in one of those moments now.

The Core Problem: We've Been Shipping Frozen Interactions

Let me paint a picture. A product manager at a mid-sized company needs to understand why Q3 revenue dipped in the enterprise segment. Today, this triggers a multi-application odyssey: log into the CRM, export pipeline data, pivot to the BI tool, cross-reference with the financial system, maybe ping someone in Slack who knows where that one spreadsheet lives. Each application presents its own interface, its own mental model, its own friction.

The question worth asking: why does the product manager need to learn five interfaces to answer one question?

The traditional response has been better integration — connect the systems, sync the data, build dashboards that pull from multiple sources. This helps, but it treats symptoms rather than causes. The fundamental problem is that we've been shipping frozen interactions. Every SaaS product encodes specific workflows in specific screens, and customers bend their processes to match. The interface is the product, which means changing how you work means changing products.

Consider what this implies. Your CRM doesn't just provide CRM capabilities — it provides its specific way of doing CRM, frozen into its interface. Your document platform doesn't just provide collaboration — it provides its specific way, with its particular blocks and layouts and mental models. Users don't just adopt functionality; they adopt an entire interaction paradigm.

(Throughout this series, I'll use "Meridian" as a stand-in for the dominant CRM platforms you're already thinking of. The patterns apply broadly across the SaaS landscape — I'm using a fictional name because the argument is about the category, not any specific vendor.)

This made sense when humans were the only consumers of software. Interfaces were necessary translation layers between human intent and machine capability. But that constraint — human as sole operator — is the assumption now breaking down.

The Moment of Decoupling

Here's where things get interesting. What if the product wasn't the interface? What if it were the underlying capability — the ability to query pipeline data, generate forecasts, track customer health — and the interface was generated dynamically based on context, user preference, and modality?

This isn't speculative. It's already happening in narrow contexts.

When you ask Claude to visualize data, and it generates a custom chart in seconds, that's not "using a BI tool." That's generating a BI tool instance for a specific question. The dashboard isn't a product feature — it's a byproduct of a capability (data access plus visualization rendering) meeting a moment of intent.

When a developer asks an AI assistant to query a database and format the results, they're not learning SQL syntax or navigating a database GUI. They're expressing intent and receiving a contextual rendering of the result.

When a support agent asks their AI assistant to pull up customer history, the interface that appears isn't the CRM's standard screen — it's a synthesized view optimized for the specific question being answered.

Each of these is a small example. But they share a pattern: the capability exists independently of its presentation. The interface becomes a rendering choice, not a product feature.

The Model Context Protocol — MCP — is the enabling standard that's making this pattern concrete. It may not look exactly like it does today; protocols evolve, mature, and get extended. But MCP has opened the door. It's proven that capability-first architecture isn't just theoretically elegant — it's practically implementable. And once that door opens, everything downstream shifts.

MCP: The Enabling Standard

For those less familiar with MCP, here's the essential mental model. MCP defines a standard way for AI systems to discover and invoke capabilities exposed by external servers. An MCP server publishes tools (executable operations with typed parameters), resources (data sources the AI can query), and prompts (reusable interaction templates). An MCP client — typically an AI assistant or agent — connects to servers, discovers available capabilities, and invokes them as needed.

The protocol will evolve. What matters isn't the specific implementation details today — it's that MCP has established the pattern and proven it works at scale. If you've read my earlier post on capability-based architecture, you'll recognize the core idea: define operations once with clear contracts, then invoke them from any interface — human or machine. One implementation, multiple consumers, zero duplication.

But MCP's significance isn't the protocol mechanics — it's what it enables and proves possible.

When Anthropic released MCP in November 2024, adoption happened at unprecedented speed. OpenAI announced support within months. Google, Microsoft, and AWS followed. By late 2025, Anthropic had donated MCP to the Linux Foundation's Agentic AI Foundation, with governance designed to prevent vendor lock-in.

The ecosystem metrics tell the story: thousands of MCP servers in the registry, nearly 100 million monthly SDK downloads, major SaaS platforms racing to expose their functionality via MCP. This velocity isn't about MCP being perfect — it's about the industry recognizing that capability-first architecture is the right direction. MCP opened the door; what walks through it may look different in three years. But the door is open.

The Great Decoupling

Here's the architectural shift I believe we're witnessing: the permanent decoupling of capability from presentation.

In the current model, SaaS products bundle three things together:

Capabilities — the actual functionality (manage orders, analyze data, send messages)
Data — the information the capability operates on
Interface — the specific screens and workflows users interact with

The interface has been the product's face, its brand, its differentiation. This bundling made sense when humans were the only consumers. But when AI agents become primary consumers, the interface bundle breaks apart.

Consider what happens when your AI assistant can directly invoke a "get order history" capability. You don't need the vendor's orders screen. You don't need to learn their navigation. You just ask your question and get an answer, rendered in whatever format suits your current context — a table, a chart, a voice summary, a spatial visualization in AR glasses.

The capability remains essential. The data remains essential. The interface becomes... optional. Or more precisely, the interface becomes a contextual rendering layer generated on demand rather than shipped in advance.

This is why I believe the interface isn't just less important in this future — it's fundamentally different in kind. It's not a product feature but a rendering choice. The same capability might appear as a dashboard widget, a conversational exchange, a voice command response, or a data payload for another agent. Same capability server, different clients.

What "Contextual Rendering" Actually Means

Let me make this concrete. Contextual rendering isn't just "different devices get different layouts." It's the interface being generated based on:

User context: What role does this person have? What's their expertise level? What are they trying to accomplish right now? A CFO asking about revenue trends gets a different rendering than a sales rep asking the same underlying question.

This is already visible in Microsoft's Copilot ecosystem. The same underlying AI capabilities render differently in Excel (formulas and data analysis), Word (document generation and editing), Teams (meeting summaries and action items), and Outlook (email triage and drafting). Same capability engine, different contextual presentations based on where the user is and what they're doing. Microsoft isn't building four separate AI products — they're building one capability layer with context-aware rendering.

Session context: What happened earlier in this conversation? What's already been established? The rendering builds on prior context rather than starting fresh with each interaction.

Watch what ChatGPT and Claude are doing with projects and memory. These aren't just features — they're early implementations of session context that persists across interactions. When Claude remembers that you're working on a specific codebase, or ChatGPT recalls your preferences from previous conversations, the rendering adapts. The responses build on an established context rather than starting cold. We're seeing session context evolve from "within this conversation" to "across all our interactions."

Modality context: Are they at a desktop with a large screen? On mobile while walking? In a car using voice? Wearing AR glasses? The same capability renders appropriately for each.

Preference context: Does this user prefer tables or charts? Detailed or summary views? Do they want the AI to explain its reasoning or just give the answer?

Again, Claude's memory and ChatGPT's customization features are early moves here — learning that you prefer concise answers, or that you want code examples in Python rather than JavaScript. The preference layer is thin today but growing.

The capability doesn't change. The data doesn't change. But the presentation adapts fluidly to the moment.

This is what I mean by the interface becoming ephemeral. It's not a fixed artifact shipped with the product. It's generated fresh for each interaction, optimized for the specific context of that moment. And crucially, the major AI platforms are already building this way, which tells you something about where the industry sees the future heading.

The Multi-Modal Default

Here's something I find genuinely exciting about this shift. Once you decouple capability from presentation, multi-modal becomes the default rather than the exception.

Today, supporting voice interfaces or AR, or chat-based interaction requires building separate products or integrations. Each modality is a project. But when capabilities are exposed through a standard protocol, each modality is just another rendering client.

The same "get order history" capability:

Renders as a data table in a desktop dashboard
Becomes a voice summary in the car: "You had 47 orders last month, up 12% from the previous month."
Appears as a spatial visualization in AR glasses
Returns structured data to another AI agent for further processing

One capability, many renderings, zero duplication. The patterns that enable AI integration turn out to be exactly what you need for genuine multi-modal applications.

The Transition Has Already Started

Look around, and you'll see the early signals:

AI assistants generating visualizations on demand rather than users navigating to dashboards. Every custom chart Claude or ChatGPT generates is a micro-instance of this pattern.

Microsoft's Copilot ecosystem treats AI capabilities as a layer that renders contextually across applications. They're not building separate AI features for each Office app — they're building a capability layer that presents differently based on context. This is the architectural pattern, implemented at scale.

Memory and project features in ChatGPT and Claude, building persistent session and preference context. These aren't just convenience features — they're the foundation for contextual rendering that adapts to you, not just to the current request.

Voice interfaces are gaining sophistication as they move from simple command-response to genuine capability invocation. Alexa asking your CRM for pipeline updates isn't navigating the CRM's UI — it's invoking a capability.

SaaS platforms racing to expose MCP servers. Payment processors, CRM platforms, service management tools, and financial data providers — the major platforms are building capability interfaces alongside (and eventually instead of) building more UI features.

Enterprise interest in "headless" architectures. The API-first movement prepared the ground; capability-first extends it to AI-native consumption.

The frozen interface isn't melting slowly. It's being disrupted by a fundamentally different model of human-software interaction.

Where This Leads

The decoupling of capability from presentation is just the first domino. Once you see software as capability providers with ephemeral interfaces, deeper questions emerge:

If external SaaS products expose capabilities via MCP, why wouldn't internal enterprise systems do the same? And if they do, what happens to the distinction between "our software" and "their software"?

If capabilities become standardized and interchangeable, where does value live? The interface was the product's differentiation — what replaces it?

And if the interface no longer binds users to specific products, what happens to the data those products have accumulated? Who owns it? Who should?

These questions lead somewhere profound — a restructuring not just of how software gets built, but of how it's sold, owned, and governed.

That's where we're headed in Part 2.

Next in the series: **The Great Decoupling: The Enterprise Capability Graph* — When internal systems and external SaaS become indistinguishable*

References

MCP Protocol and Adoption: Anthropic introduced the Model Context Protocol in November 2024. By late 2025, the ecosystem had grown to approximately 2,000 servers in the MCP Registry and 97+ million monthly SDK downloads. Source: Model Context Protocol Blog - One Year of MCP
Industry Adoption: OpenAI announced MCP support in March 2025, with Sam Altman noting, "people love MCP, and we are excited to add support across our products." Google DeepMind, Microsoft, and AWS followed with native MCP integration. Source: Wikipedia - Model Context Protocol
Linux Foundation Governance: Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation in late 2025, co-founded with Block and OpenAI. Source: Anthropic - Donating the Model Context Protocol
SaaS Platform MCP Adoption: Major platforms across payments, CRM, and financial data have released MCP integrations. Source: FinTech Magazine - Plaid Boosts Fintech with Claude AI Integration
MCP as Industry Standard: Analysis of why MCP achieved rapid adoption over competing approaches. Source: The New Stack - Why the Model Context Protocol Won

Environment Variables Without the Chaos: A Vault-First Approach

Jay Desmarais — Wed, 31 Dec 2025 19:17:31 +0000

Have you ever joined a project and spent your first day hunting down the magical incantation of environment variables needed to run the application locally? Perhaps someone pointed you to an outdated .env.example file, or worse, a Slack message from six months ago with half the values redacted. "Just ask Sarah for the database password," they say. Sarah left the company in March.

The environment variable problem seems trivial until it isn't. What starts as a handful of configuration values inevitably grows into dozens of settings scattered across developer machines, deployment pipelines, and hastily-shared documents. And it's not just secrets—API endpoints, feature flags, service URLs, port numbers, and environment-specific behavior toggles all end up in the mix. I've watched teams lose entire days to configuration drift—where production, staging, and local environments slowly diverge until mysterious bugs appear that "work on my machine."

There's a better way. In this post, I'll walk you through a pattern I've been using that treats a cloud vault as the single source of truth for all environment configuration, populates it automatically during infrastructure provisioning, and provides developers with a single command to sync the right variables to the right projects—no secrets in source control, no copying values through chat, no wondering if your local setup matches everyone else's.

While the examples here use Azure Key Vault and Azure-specific tooling, the pattern itself is cloud-agnostic. Swap in AWS Secrets Manager, Google Cloud Secret Manager, HashiCorp Vault, or any other secret store with a CLI—the architecture remains the same. The key insight isn't about Azure; it's about establishing a single source of truth and automating the flow from that source to everywhere configuration is needed.

The Core Problem: Configuration Has Too Many Homes

Let me paint a picture. A typical application deployment involves several environments: local development, perhaps a shared dev environment, staging, and production. Each environment needs its own set of configuration values—and these aren't just secrets. Yes, there are database connection strings and API keys (I'm not saying this is right, but you can't argue that it's there), but there's also:

Service endpoints: Where does the frontend call the API? Where does the API call the authentication service?
Feature flags: Is the new checkout flow enabled? Should we show the beta banner?
Behavioral settings: What's the session timeout? How many retry attempts? What log level?
Infrastructure coordinates: Which Redis cluster? What storage account? Which message queue?

The traditional approach scatters these values across multiple locations:

Developer machines: Each developer maintains their own .env files, manually updated whenever something changes
CI/CD pipelines: Variables configured in GitHub Actions, Azure DevOps, or whatever orchestrates your deployments
Hosting platforms: App Service configuration, Static Web App settings, Azure Functions local settings
Documentation: READMEs, wikis, or Notion pages that inevitably fall out of sync
Human memory: "Oh, you need to set SPECIAL_FLAG=true for that feature to work"

The fundamental problem is that there's no authoritative source. When a value needs to change, someone has to remember everywhere it lives and update each location. They won't. Drift is inevitable.

The Vault as Source of Truth

The pattern I recommend flips this model. Instead of the vault being one of many places configuration lives, it becomes the place. Every other location—local .env files, CI/CD variables, app service configuration—is derived from the vault rather than managed independently.

When you need to change a configuration value, you update it in the vault. Developers run a sync script to refresh their local environments. Deployments pull from the vault directly or through secure variable injection. One change propagates everywhere.

Populating the Vault During Provisioning

The first piece of this pattern is ensuring the vault gets populated with the right values when infrastructure is provisioned. If you're using Bicep, Terraform, or CloudFormation, this becomes part of your infrastructure-as-code.

Here's an Azure Bicep example that provisions a Key Vault and populates it with generated values:

@description('Environment name (dev, staging, prod)')
param environment string

@description('Base name for resources')
param baseName string

// Generate a secure random string for JWT secret
var jwtSecret = uniqueString(resourceGroup().id, 'jwt', environment)

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-${baseName}-${environment}'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enableRbacAuthorization: true
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
  }
}

// Secrets that should be generated during provisioning
resource jwtSecretEntry 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = {
  parent: keyVault
  name: 'JWT-SECRET'
  properties: {
    value: '${jwtSecret}${uniqueString(deployment().name)}'
  }
}

// Secrets derived from other provisioned resources
resource dbConnectionString 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = {
  parent: keyVault
  name: 'DATABASE-CONNECTION-STRING'
  properties: {
    value: 'Server=${sqlServer.properties.fullyQualifiedDomainName};Database=${sqlDatabase.name};...'
  }
}

// Environment-specific configuration
resource apiBaseUrl 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = {
  parent: keyVault
  name: 'API-BASE-URL'
  properties: {
    value: environment == 'prod' 
      ? 'https://api.mycompany.com' 
      : 'https://api-${environment}.mycompany.com'
  }
}

The key insight here is that configuration values fall into categories. Some—like JWT signing keys—should be randomly generated during provisioning and never typed by a human. Others—like database connection strings—are derived from resources created in the same deployment. Still others—like API URLs—follow predictable patterns based on environment. By encoding these rules in your infrastructure templates, you eliminate manual configuration entirely.

For values that genuinely need human input—third-party API keys, for instance—I recommend a two-phase approach. The infrastructure provisioning creates placeholder secrets, and a separate onboarding script prompts operators to fill in the values that can't be generated:

#!/bin/bash
# post-provision-setup.sh

VAULT_NAME="kv-myapp-$ENVIRONMENT"

echo "Setting up third-party integrations for $ENVIRONMENT..."

# Check for placeholder values and prompt for real ones
if [[ $(az keyvault secret show --vault-name $VAULT_NAME --name "STRIPE-API-KEY" --query "value" -o tsv) == "PLACEHOLDER" ]]; then
  read -sp "Enter Stripe API key: " stripe_key
  az keyvault secret set --vault-name $VAULT_NAME --name "STRIPE-API-KEY" --value "$stripe_key"
  echo "✓ Stripe API key configured."
fi

The Three-Layer Configuration Architecture

Here's where the pattern gets interesting. Fetching values from the vault is only part of the puzzle. In a real monorepo, different applications need the same configuration in different formats. Your Vite frontend expects VITE_API_URL in a .env file. Your Azure Functions expect ApiUrl in a local.settings.json file with a specific JSON structure. Your backend services might want API_URL in yet another .env file. Same value, different names, different formats.

The solution is a three-layer architecture:

The configuration manifest is the crucial middle layer. It's a declarative JSON file that lives in your repository and describes how configuration flows into each application:

{
  "$schema": "./env-manifest.schema.json",
  "vault": {
    "namePattern": "kv-{environmentCode}-{appName}"
  },
  "globalVariables": [
    "jwt-secret",
    "database-connection-string",
    "api-base-url",
    "control-api-url",
    "redis-host",
    "redis-password",
    "feature-flag-new-checkout"
  ],
  "defaults": {
    "redis-port": "6380",
    "jwt-expiration": "24h"
  },
  "localOverrides": {
    "api-base-url": "http://localhost:7073",
    "control-api-url": "http://localhost:7074",
    "enable-test-credentials": "true"
  },
  "applications": {
    "portal": {
      "configPath": "apps/portal/.env",
      "format": "dotenv",
      "requiredGlobals": [],
      "secretMappings": {
        "api-base-url": "VITE_API_URL",
        "control-api-url": "VITE_CONTROL_API_URL",
        "enable-test-credentials": "VITE_ENABLE_TEST_CREDENTIALS"
      },
      "specificOverrides": {
        "VITE_ENVIRONMENT": "${ENVIRONMENT}"
      }
    },
    "management-api": {
      "configPath": "apps/management-api/.env",
      "format": "dotenv",
      "requiredGlobals": [],
      "secretMappings": {
        "jwt-secret": "JWT_SECRET",
        "database-connection-string": "DATABASE_URL",
        "redis-host": "REDIS_HOST",
        "redis-password": "REDIS_PASSWORD"
      },
      "specificOverrides": {
        "NODE_ENV": "${NODE_ENV}",
        "PORT": "7073",
        "JWT_EXPIRATION": "24h"
      }
    },
    "control-functions": {
      "configPath": "apps/control-functions/local.settings.json",
      "format": "json-settings",
      "requiredGlobals": [],
      "secretMappings": {
        "api-base-url": "ApiBaseUrl",
        "jwt-secret": "JwtSecret",
        "database-connection-string": "DatabaseConnectionString"
      },
      "specificOverrides": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "node"
      }
    }
  }
}

This manifest captures everything the loader script needs to know. The same canonical secret api-base-url becomes VITE_API_URL in the portal and ApiBaseUrl in the Azure Functions project. The localOverrides section automatically redirects URLs to localhost—without polluting the vault with development-specific values. And specificOverrides handles values that are constant for an application but shouldn't live in the vault (like port numbers or runtime settings).

The Environment Loader Script

With the manifest in place, the loader script becomes surprisingly straightforward. Before diving into implementation, let me walk through the essential flow:

Read the manifest — what variables exist, where they go
Fetch secrets from Key Vault — the canonical values
Apply local overrides — localhost URLs, test credentials
Map canonical names to app-specific names — api-url → VITE_API_ENDPOINT
Write config files in each app's expected format — dotenv, JSON, YAML

Here's the logic in pseudocode:

function loadEnvironment(targetEnvironment):

    # 1. RESOLVE CONFIGURATION SOURCES
    manifest = readJSON("config/env-manifest.json")
    infraParams = readJSON("infra/env/{targetEnvironment}.parameters.json")
    vaultName = buildVaultName(infraParams.environmentCode, infraParams.region)

    # 2. AUTHENTICATE & CONNECT
    if not cloudCLI.isLoggedIn():
        exit("Please authenticate with cloud provider first")

    vault = connectToVault(vaultName)

    # 3. FETCH ALL SECRETS FROM VAULT
    secrets = {}
    for secretName in manifest.globalVariables:
        secrets[secretName] = vault.getSecret(secretName) 
                              ?? manifest.defaults[secretName] 
                              ?? null

    # 4. APPLY LOCAL OVERRIDES (when running locally)
    if targetEnvironment == "local":
        for key, value in manifest.localOverrides:
            secrets[key] = value  # localhost URLs, test credentials, etc.

    # 5. GENERATE CONFIG FILES FOR EACH APPLICATION
    for app in manifest.applications:

        # Build this app's environment variables
        appEnvVars = {}

        # Add global variables this app needs
        for varName in app.requiredGlobals:
            appEnvVars[varName] = secrets[varName]

        # Map infrastructure secrets to app-specific names
        # e.g., "api-url" → "VITE_API_ENDPOINT" for frontend
        for secretName, localVarName in app.secretMappings:
            appEnvVars[localVarName] = secrets[secretName]

        # Add app-specific overrides
        for key, value in app.specificOverrides:
            appEnvVars[key] = value

        # Write in the correct format for this app type
        outputPath = app.configPath

        switch app.format:
            case "dotenv":
                writeAsDotenv(outputPath, appEnvVars)
            case "json-settings":
                writeAsJsonSettings(outputPath, appEnvVars)
            case "yaml":
                writeAsYaml(outputPath, appEnvVars)

        log("Generated {outputPath} with {count(appEnvVars)} variables")

    # 6. VALIDATE & REPORT
    detectConflicts(generatedFiles)
    reportMissingSecrets(secrets)

    log("Environment setup complete for: {targetEnvironment}")

The key insight is that the script separates what from how. The manifest declares what each application needs. The script handles how to fetch, transform, and write those values. This separation means adding a new application is a manifest change, not a script change.

Output Formatters

Different runtimes expect different file formats. The script handles this with format-specific writers:

function writeAsDotenv(path, vars):
    content = "# Generated - do not edit\n"
    for key, value in vars:
        content += "{key}={value}\n"
    writeFile(path, content)

function writeAsJsonSettings(path, vars):
    settings = {
        "IsEncrypted": false,
        "Values": vars
    }
    writeFile(path, toJSON(settings))

In practice, the bash implementation uses jq for JSON parsing and simple string concatenation for dotenv output. The actual script I'm using for a personal project runs about 150 lines, including error handling, colored output, and progress reporting—but the core logic follows the pseudocode above.

The Security Boundary: Frontend vs. Backend

This brings us to an important architectural concern that the manifest encodes: the security boundary between frontend and backend configuration.

In a Vite-based frontend (or Create React App, Next.js, and similar), environment variables are embedded into the JavaScript bundle at build time. Only variables with a specific prefix—VITE_ for Vite, REACT_APP_ for CRA, NEXT_PUBLIC_ for Next.js—are included. This is a security feature. It means you can't accidentally expose your JWT signing secret to every browser that loads your application.

The manifest makes this explicit through the secretMappings:

{
  "portal": {
    "format": "dotenv",
    "secretMappings": {
      "api-base-url": "VITE_API_URL",
      "enable-test-credentials": "VITE_ENABLE_TEST_CREDENTIALS"
    }
  },
  "management-api": {
    "format": "dotenv",
    "secretMappings": {
      "jwt-secret": "JWT_SECRET",
      "database-connection-string": "DATABASE_URL"
    }
  }
}

The portal only gets variables mapped with VITE_ prefixes—safe for browser exposure. The API gets the actual secrets—never bundled into client-side code. The manifest documents and enforces this boundary.

Format-Aware Generation

Different application types expect different configuration formats. The loader script handles this transparently:

Application Type	Output File	Format
Vite/React Frontend	`.env`	Dotenv with `VITE_` prefix
Node.js Backend	`.env`	Standard dotenv
Azure Functions	`local.settings.json`	JSON with `Values` object
Database Tools	`.env`	Connection string only

For Azure Functions specifically, the output looks like:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "ApiBaseUrl": "http://localhost:7073",
    "JwtSecret": "dev-jwt-secret-value-here",
    "DatabaseConnectionString": "Server=localhost;Database=myapp;..."
  },
  "Host": {
    "CORS": "*"
  }
}

Same configuration, different shape. The manifest defines the mapping, and the script handles the transformation.

Handling Multiple Environments

Real applications need to support multiple environments, and developers occasionally need to point their local setup at staging or production (carefully, and with appropriate access controls). The loader script handles this through a simple argument:

# Local development (default) - uses dev vault with localhost overrides
./scripts/load-env.sh local

# Point at the dev environment's actual URLs
./scripts/load-env.sh dev

# Point at staging (requires staging vault access)
./scripts/load-env.sh staging

# Production (release automation, no human should require access unless absolutely required)
./scripts/load-env.sh prod

For teams that frequently switch environments, I've found it helpful to add convenience wrappers in package.json:

{
  "scripts": {
    "env:local": "./scripts/load-env.sh local",
    "env:dev": "./scripts/load-env.sh dev",
    "env:staging": "./scripts/load-env.sh staging"
  }
}

A word of caution: developers should never need production secrets locally. If they do, it usually indicates a gap in your staging environment's data or configuration. Grant read access to production vaults sparingly and audit its use. The convenience of the loader script shouldn't become a vector for secret sprawl.

Smart Defaults and Graceful Degradation

One pattern I've come to appreciate is building applications that work with minimal configuration in development while requiring explicit configuration in production. The manifest supports this by simply omitting optional services from an application's secretMappings—if a secret isn't mapped, the variable won't be set, and the application can detect this and degrade gracefully:

function getRedisClient(): Redis | null {
  const host = process.env.REDIS_HOST;

  // Graceful degradation: Redis is optional for local dev
  if (!host) {
    console.log('REDIS_HOST not configured, using in-memory fallback');
    return null;
  }

  return new Redis({
    host,
    port: parseInt(process.env.REDIS_PORT || '6380', 10),
    password: process.env.REDIS_PASSWORD,
    tls: process.env.REDIS_TLS === 'true' ? {} : undefined,
  });
}

For local development, you might configure the management API without Redis at all:

{
  "management-api": {
    "secretMappings": {
      "jwt-secret": "JWT_SECRET",
      "database-connection-string": "DATABASE_URL"
      // Redis mappings omitted for local dev
    }
  }
}

This means a new developer can clone the repo, run the loader script, and start the application immediately—even if they don't have Redis running locally. The application gracefully degrades to in-memory alternatives. When they deploy to staging or production, the full infrastructure is available and configured.

Integrating with CI/CD

The final piece is connecting this pattern to your deployment pipeline. Rather than maintaining a parallel set of variables in GitHub Actions or Azure DevOps, the pipeline pulls directly from Key Vault.

For GitHub Actions with Azure, this looks like:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Fetch secrets from Key Vault
        id: keyvault
        uses: azure/get-keyvault-secrets@v1
        with:
          keyvault: kv-myapp-prod
          secrets: 'JWT-SECRET, DATABASE-CONNECTION-STRING, STRIPE-API-KEY'

      - name: Build frontend
        run: npm run build --workspace=portal
        env:
          VITE_API_URL: https://api.mycompany.com
          VITE_ENVIRONMENT: prod

      - name: Deploy API
        uses: azure/webapps-deploy@v2
        with:
          app-name: myapp-api-prod

For App Service specifically, Azure supports Key Vault references in application settings. Instead of copying secrets into App Service configuration, you reference them:

resource appService 'Microsoft.Web/sites@2023-01-01' = {
  name: 'myapp-api-${environment}'
  properties: {
    siteConfig: {
      appSettings: [
        {
          name: 'JWT_SECRET'
          value: '@Microsoft.KeyVault(VaultName=${keyVault.name};SecretName=JWT-SECRET)'
        }
        {
          name: 'DATABASE_URL'  
          value: '@Microsoft.KeyVault(VaultName=${keyVault.name};SecretName=DATABASE-CONNECTION-STRING)'
        }
      ]
    }
  }
}

With Key Vault references, App Service fetches the current secret value at runtime. When you rotate a secret in Key Vault, the application picks up the new value on its next restart—no redeployment required.

The .gitignore Imperative

None of this works if secrets accidentally end up in source control. Your .gitignore must be ironclad:

# Environment files - never commit these
.env
.env.*
!.env.example

# Azure Functions local settings
local.settings.json

# Local overrides
*.local

I also recommend a pre-commit hook that rejects any attempt to commit files matching these patterns:

#!/bin/bash
# .git/hooks/pre-commit

# Check for .env files
if git diff --cached --name-only | grep -E '\.env($|\.)' | grep -v '\.example$'; then
  echo "Error: Attempting to commit .env file(s). This is not allowed."
  exit 1
fi

# Check for Azure Functions local settings
if git diff --cached --name-only | grep 'local.settings.json'; then
  echo "Error: Attempting to commit local.settings.json. This is not allowed."
  exit 1
fi

Onboarding: From Clone to Running in Minutes

The payoff for all this infrastructure is a dramatically simplified onboarding experience. Here's what a new developer's first day looks like:

# 1. Clone the repository
git clone https://github.com/myorg/myapp.git
cd myapp

# 2. Install dependencies
npm install

# 3. Authenticate with Azure
az login

# 4. Load environment configuration
./scripts/load-env.sh local

# 5. Start developing
npm run dev

That's it. No hunting for configuration values. No asking colleagues for files. No wondering whether your setup matches everyone else's. The vault is the source of truth, the manifest defines the mapping, the script generates the files, and the developer is productive in minutes rather than hours.

Tradeoffs and Considerations

This pattern isn't without costs, and it's worth being explicit about them:

Cloud dependency: Developers need CLI authentication and vault access before they can generate local configuration. For open-source projects or teams not already using a cloud vault, this may be prohibitive.

Script complexity: The loader script grows as applications are added to the monorepo. Each new application type might need a new output format. This is manageable but requires maintenance.

Implicit configuration: Developers might not understand where values come from. When something breaks, they need to understand the three-layer model to debug effectively. Good error messages and documentation help.

Stale local configs: If configuration changes upstream, developers must re-run the loader script. Consider adding a reminder to your PR template or making the script part of your standard "pull and update" workflow.

Offline limitations: First-time setup requires network access to the vault. Once generated, .env files work offline, but you can't onboard a new developer on an airplane.

Alternatives Not Taken

It's worth briefly mentioning approaches I considered and rejected:

Committed .env.example files: Requires manual copying and filling in values. Drifts from reality. Doesn't solve the "ask Sarah" problem.

Encrypted .env files in repo: Key distribution becomes its own problem. Who has the decryption key? How do you rotate it?

Container-based dev environments: Higher overhead, requires Docker knowledge, less flexible for polyglot development. Good for some teams, but adds complexity.

Manual documentation: Prone to drift, slow onboarding, doesn't scale. The only thing worse than no documentation is wrong documentation.

Alternatives Worth Considering

Hybrid local/dev environments for tier-specific development: In a monorepo, you might want to work only on the frontend while connecting to cloud services deployed in your development environment. You could extend the manifest and script to handle this case—perhaps a local-frontend environment that uses localhost for the portal but dev URLs for backend services. For my needs so far, I pull the variables for development and manually override the endpoints I want to run locally. It's not elegant, but it works until the pattern proves itself enough to warrant the extra complexity.

Where This Leads

Once you've established a vault as the source of truth with a manifest-driven loader, interesting possibilities emerge. Secret rotation becomes a single-point operation. Audit logs show exactly who accessed which configuration and when. Environmental parity is guaranteed rather than hoped for.

The manifest also becomes documentation. New team members can read env-manifest.json to understand what configuration each application needs. When adding a new service, the manifest change in the pull request makes the configuration requirements explicit and reviewable.

Looking forward, this pattern positions you well for more sophisticated configuration management: automatic rotation policies, integration with CI/CD secret scanning, even zero-trust architectures where applications authenticate using managed identities rather than shared secrets.

If you've been battling environment variable chaos, I'd encourage you to start with a single vault and a minimal manifest that covers one application. Write a loader script that generates one .env file. Experience the simplicity of ./scripts/load-env.sh local instead of "ask Sarah for the database password." Then gradually extend the manifest to more applications, add more sophisticated features, and watch onboarding time collapse from days to minutes.

Sarah will thank you. And so will the next developer who joins the team.

Capability-Based Architecture: A Practical Guide to Portability, Isolation, and AI-Readiness

Jay Desmarais — Fri, 19 Dec 2025 22:30:40 +0000

Have you ever found yourself staring at a codebase that started as a clean, well-intentioned application and somehow evolved into a tangled web of interdependencies? The kind where touching one component sends ripples through six others, and deploying a new feature feels like performing surgery on a house of cards? If so, you're not alone—and there's a better way to think about application design.

I've spent considerable time exploring architectural patterns that address this complexity head-on, and what I've found is that the most resilient, maintainable applications share a common trait: they're built around capabilities rather than features. The examples here are drawn from patterns I've started using myself, built on years of wrestling with these problems. In this post, I'll walk you through the key patterns that enable this approach and explain why they matter for modern application development.

The Core Problem: Entanglement

Let me paint a picture. Developer BW joins a team working on an e-commerce platform. She's tasked with adding order history export functionality. Simple enough, right? Except the order history component directly imports the user service, which depends on the authentication module, which has hooks into the notification system, which... you get the idea. What should be a self-contained feature becomes an exercise in understanding the entire application's dependency graph.

The traditional response has been to "be more careful" with dependencies or to introduce dependency injection frameworks. These help, but they treat symptoms rather than causes. The fundamental problem is architectural: we've allowed our components to know too much about each other.

Thinking in Capabilities

A capability is a discrete, self-contained unit of functionality that can be mounted into an application without hard dependencies on other capabilities. Think of capabilities as building blocks with well-defined shapes—they snap into place without needing to know what other blocks exist around them.

What makes this concept particularly powerful is that capabilities are full-stack by nature. A single capability encapsulates both its user interface components and its backend processing logic. The order history capability doesn't just render a list of orders—it also handles data fetching, caching, export generation, and any server-side operations that feature requires. Some capabilities are UI-heavy, presenting rich interactive experiences. Others are entirely headless, performing background processing, scheduled tasks, or API integrations without any visual component at all. Most live somewhere in between.

This full-stack encapsulation means you're not coordinating between a "frontend order history component" and a "backend order history service" that happen to share a name. You're working with a single cohesive unit that owns its entire vertical slice of functionality. When you add the order history capability to an application, you get everything it needs to function—viewers, actions, data access, business logic—in one portable package.

The theory then is this: if each capability is truly isolated, you can add, remove, or modify one without affecting others. You can test them independently. You can even share them across entirely different applications.

But isolation alone isn't enough. Capabilities still need to cooperate. The key insight is that cooperation doesn't require coupling—it requires communication. And that's where event-driven patterns come in.

Event-Driven Communication: The Great Decoupler

Rather than calling methods on other capabilities directly, isolated capabilities communicate through events. If capability A needs to inform capability B that something happened, A emits an event. B subscribes to that event if it cares about it. Neither knows the other exists.

Take for example our e-commerce scenario. When an order is placed, the order capability emits an order-placed event with the relevant data. The notification capability, which has subscribed to this event, picks it up and sends the confirmation email. The analytics capability logs the conversion. The inventory capability updates stock levels. Each handles its concern independently.

// Order capability emits an event
context.emit('order-placed', {
  orderId: order.id,
  customerId: order.customerId,
  total: order.total,
  timestamp: Date.now(),
});

// Notification capability subscribes (in a completely separate module)
eventBus.subscribe('order-placed', async (event) => {
  await sendOrderConfirmation(event.payload.orderId, event.payload.customerId);
});

The beauty here is that the order capability doesn't import, reference, or even know about the notification capability. If you remove notifications entirely, the order capability continues functioning. This is graceful degradation in action—the application becomes resilient to component failures or removals.

Separating Presentation from Operation: The Viewer/Action Pattern

Here's a pattern I've come to appreciate deeply: the explicit separation of viewers (UI components) and actions (operations). At first glance, this might seem like a rehash of MVC or its descendants. But there's a crucial difference—actions are defined as first-class, schema-validated operations that can be invoked by any interface, not just your UI.

Consider a media player capability. It defines actions like play, pause, seek, and setVolume. The viewer components—PlayButton, PauseButton, VolumeSlider—invoke these actions, but they're just one interface to the underlying operations.

const mediaActions = defineActions({
  play: {
    id: 'play',
    name: 'Play',
    description: 'Start or resume media playback',

    params: {}, // No parameters needed

    execute: async (_, context) => {
      await context.state.mediaElement.play();
      context.emit('playback-started', { 
        mediaId: context.state.currentMedia.id 
      });
      return { status: 'playing' };
    },
  },

  seek: {
    id: 'seek',
    name: 'Seek',
    description: 'Jump to a specific position in the media',

    params: {
      type: 'object',
      properties: {
        position: { 
          type: 'number', 
          description: 'Position in seconds' 
        },
      },
      required: ['position'],
    },

    execute: async ({ position }, context) => {
      context.state.mediaElement.currentTime = position;
      return { 
        status: 'seeked', 
        newPosition: position 
      };
    },
  },
});

This is why I believe we're finally ready for AI-integrated applications. Those same action definitions—complete with descriptions, parameter schemas, and examples—can be automatically transformed into AI tools. An LLM assistant can invoke seek(position: 45) exactly as a user would click on the seek bar. The action definition is the single source of truth for both human and machine interfaces.

This pattern also clarifies how capabilities can be both UI-driven and headless. A capability with viewers and actions presents interactive experiences—the user clicks, the action executes. But a headless capability simply defines actions without viewers. Consider a data synchronization capability that runs background jobs, or an integration capability that processes webhooks from external services. These capabilities have actions (sync, process, transform) but no UI components. They're still first-class capabilities, mountable and configurable through the same mechanisms, just without a visual presence. The viewer/action pattern accommodates both modes naturally—viewers are optional, actions are the core.

Mounting Points: Surfaces and Experiences

Now let's talk about where capabilities actually appear in your application. This is where the concepts of surfaces and experiences become useful.

A surface represents a major area or context in your application—think of it as a distinct "place" where users accomplish goals. An e-commerce platform might have surfaces like "cart," "account," "admin dashboard," and "product catalog." Each surface has its own layout, context providers, and behavioral characteristics.

An experience, on the other hand, represents a user journey or workflow within a surface. Within the cart surface, you might have a "checkout" experience or a "quick-buy" experience. Experiences shape how capabilities are presented and orchestrated for specific user flows.

Capabilities are then mounted at the intersection of surfaces and experiences. Order history might be mounted at account:overview with a compact view, while the same capability appears at account:orders with full filtering and pagination. Same capability, different presentations based on context.

// Same capability, context-aware presentation
{
  viewers: {
    'account:orders': {
      viewer: 'full',
      props: {
        pageSize: 20,
        showFilters: true,
      },
    },
    'account:overview': {
      viewer: 'compact',
      props: {
        pageSize: 5,
        showFilters: false,
      },
    },
  },
}

This mounting system provides remarkable flexibility. You define capabilities once and configure how they appear across your application declaratively. Need to add order history to a new mobile surface? Add a mounting configuration—you don't touch the capability code.

Configuration Hierarchy: Flexibility Without Chaos

Speaking of configuration, here's a pattern that solves a surprisingly common tension: how do you provide sensible defaults while allowing runtime customization without losing control?

The answer is a configuration hierarchy that flows through multiple layers:

Code defaults (checked into source control, deployed with the application)
Persisted configuration (modified by admins at runtime, stored in your persistence layer)
Runtime evaluation (feature flags, A/B tests, conditional rules)

Each layer can override the previous, but you always know where your configuration originates. If an admin changes a capability setting, that's recorded in the persistence layer. If a feature flag activates a new behavior, that's evaluated at runtime. But the foundational defaults remain stable in code.

Code Defaults          →    Persisted Config    →    Runtime Evaluation
(app.config.ts)             (Admin UI changes)       (Feature flags, ABAC)
     ↓                           ↓                         ↓
  Version controlled        Scoped overrides         Dynamic evaluation
  Deployed with app         Global/tenant/user       Context-aware

This hierarchy enables scenarios like blue/green deployments of configurations. Define a "blue" variant with your stable settings and a "green" variant with your next release. Route traffic between them without redeploying code.

Pluggable Middleware: Protocol Agnosticism

Here's where things get particularly interesting for the purposes of modern multi-channel applications. When you define actions with clear schemas and execution logic, you can expose them through multiple protocols simultaneously.

The pattern I recommend is a middleware layer that wraps your core service actions with cross-cutting concerns like authentication, authorization, validation, and auditing. This middleware then plugs into different adapters for different protocols:

An HTTP adapter exposes actions as REST endpoints
A CLI adapter makes them available from the command line
An AI adapter transforms them into tools for language models

┌─────────────────────────────────────────────────────────────────────────┐
│                           Service Registry                              │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐         │
│  │ configActions   │  │ orderActions    │  │ mediaActions    │         │
│  │ ├─ get          │  │ ├─ getOrders    │  │ ├─ play         │         │
│  │ ├─ set          │  │ ├─ cancelOrder  │  │ ├─ pause        │         │
│  │ └─ delete       │  │ └─ exportOrders │  │ └─ seek         │         │
│  └─────────────────┘  └─────────────────┘  └─────────────────┘         │
└─────────────────────────────────────────────────────────────────────────┘
                                  │
                  ┌───────────────┼───────────────┐
                  ▼               ▼               ▼
           ┌───────────┐   ┌───────────┐   ┌───────────┐
           │   HTTP    │   │    CLI    │   │    AI     │
           │  Adapter  │   │  Adapter  │   │  Adapter  │
           └───────────┘   └───────────┘   └───────────┘

The same exportOrders action becomes POST /api/orders/export, myapp orders export --format csv, and the AI tool export_orders(format: "csv"). One implementation, three interfaces, zero duplication.

Access Control: Beyond Simple Roles

While we're discussing middleware, let's address authorization. Traditional role-based access control (RBAC) assigns permissions to roles, and users inherit permissions through their roles. It works, but it's often too coarse for modern applications.

The pattern I advocate combines hierarchical scopes with attribute-based conditions. Scopes establish the basic hierarchy: system-admin inherits from account-admin, which inherits from tenant-admin, and so on. But individual capabilities, features, or actions can require additional conditions based on attributes.

{
  access: {
    scopes: ['tenant-admin', 'account-admin', 'system-admin'],
    conditions: [
      { attribute: 'tenant.plan', operator: 'in', value: ['business', 'enterprise'] },
      { attribute: 'user.mfaEnabled', operator: 'equals', value: true },
    ],
  },
}

This configuration means: you need at least tenant-admin scope, AND your tenant must be on a business or enterprise plan, AND you must have MFA enabled. It's expressive enough for complex enterprise requirements while remaining declarative and auditable.

Capability Sets: Organized Complexity

As applications grow, individual capabilities benefit from grouping into capability sets. A set is a collection of related capabilities that share a controller, state, and can communicate through private internal events.

Imagine an order management set containing order-history, order-tracking, order-returns, and order-notifications capabilities. Each capability maintains its isolation—they don't import each other. But the set controller can maintain shared state (like cached order data) and facilitate internal communication that wouldn't make sense to expose publicly.

The set also becomes a convenient unit for:

Enabling/disabling related capabilities together
Applying consistent access rules
Versioning and distributing as a package
Configuring AI tool availability

@myorg/order-management/
├── controller/                 # Shared state and lifecycle
├── actions/                    # Set-level actions
├── events/
│   ├── internal.ts            # Private events within the set
│   └── public.ts              # Events other sets can subscribe to
└── capabilities/
    ├── order-history/
    ├── order-tracking/
    ├── order-returns/
    └── order-notifications/

Capabilities within the set can emit private events that only siblings can subscribe to. This prevents other parts of the application from depending on implementation details while still enabling internal coordination.

AI-Readiness: The Dual Interface Pattern

I've touched on AI integration several times, and for good reason—it's becoming table stakes for modern applications. The architectural decisions you make today determine how naturally AI assistants can interact with your system tomorrow.

The dual interface pattern means every action you define can be invoked by both humans (through viewers) and AI (through tool definitions). But there's nuance here. Not every action should be available to AI. Bulk operations, destructive actions, or those requiring human judgment might need to be gated:

{
  features: {
    'export-history': {
      ai: {
        enabled: true,  // Safe for AI to trigger
        readOnly: true,
      },
    },
    'bulk-delete': {
      ai: {
        enabled: false,  // Requires human oversight
      },
    },
    'cancel-order': {
      ai: {
        enabled: true,
        requiresConfirmation: true,  // AI must get user approval
      },
    },
  },
}

This granular control means you can embrace AI integration without surrendering safety. The AI assistant can query orders, export reports, and track shipments. But canceling orders requires confirmation, and bulk deletions are human-only operations.

The Persistence Question

All of this architectural elegance needs somewhere to live beyond memory. The pattern here is a pluggable persistence provider interface that different storage backends can implement:

Local file storage for development
Blob/table storage for serverless deployments
SQL databases for enterprise requirements

The persistence layer handles configuration storage, state synchronization, and audit logging. But because it's behind an interface, you can swap implementations without changing application code. Start with file-based storage in development, deploy to Azure Table Storage in production, migrate to SQL when requirements change—all without touching your capabilities.

AI-Assisted Development: When Your Architecture Speaks to Your Tools

Here's something I find genuinely exciting: the same structural clarity that enables runtime AI integration also dramatically amplifies AI-assisted development. Think about it—we've defined capabilities with explicit manifests, actions with typed schemas, events with documented contracts, and mounting configurations that declare where everything lives. This isn't just good for humans reading the code. It's exactly the kind of structured, self-describing codebase that AI coding tools thrive on.

Consider what happens when you ask an AI coding assistant to "add a refund action to the order management capability" in a traditional codebase. The AI needs to understand your project structure, infer where actions live, guess at your patterns for defining operations, figure out how you handle validation, and hope it doesn't break something in the process. The context window fills with exploratory reads, and the result is often a best-effort approximation that requires significant human correction.

Now consider the same request in a capability-based architecture. The AI can immediately locate the capability manifest, which explicitly declares the capability's structure:

// The manifest tells the AI exactly what this capability contains
export default defineCapability({
  id: '@myorg/order-management/order-returns',
  version: '2.1.0',

  actions: './actions',           // Actions live here
  viewers: './viewers',           // UI components here
  events: {
    emits: ['return-initiated', 'refund-processed'],
    subscribes: ['order-updated'],
  },

  features: {
    'bulk-returns': { /* ... */ },
    'refund-processing': { /* ... */ },
  },
});

The AI doesn't guess—it reads. It knows actions are in ./actions, follows the established pattern from existing actions, generates a new action with the correct schema structure, and updates the manifest. The structural conventions eliminate ambiguity.

But the benefits go deeper than navigation. Because actions have explicit parameter and result schemas, the AI can generate type-safe implementations with confidence. It knows what the action receives, what it should return, and can even infer appropriate error handling from existing patterns:

// AI generates this by following established patterns
refundOrder: {
  id: 'refundOrder',
  name: 'Refund Order',
  description: 'Process a full or partial refund for an order',

  params: z.object({
    orderId: z.string().describe('The order to refund'),
    amount: z.number().optional().describe('Partial refund amount; omit for full refund'),
    reason: z.enum(['customer-request', 'damaged', 'wrong-item', 'other']),
  }),

  result: z.object({
    refundId: z.string(),
    amount: z.number(),
    status: z.enum(['pending', 'processed', 'failed']),
  }),

  access: {
    scopes: ['tenant-admin', 'account-admin'],  // Inferred from sibling actions
  },

  ai: {
    enabled: true,
    requiresConfirmation: true,  // AI recognizes this is a sensitive operation
    description: 'Processes a refund for a customer order. Use when customer requests money back.',
  },

  execute: async (params, context) => {
    // Implementation follows patterns from existing actions
  },
}

Notice how the AI can infer access control patterns from sibling actions, recognize that refunds are sensitive operations requiring confirmation, and even generate AI-specific metadata. The architecture teaches the AI how to write code that belongs.

The isolation principle pays dividends here too. When an AI modifies a capability, the blast radius is inherently contained. The AI can refactor the entire internal implementation of order-returns without risking breakage in order-tracking or order-notifications. There are no hidden dependencies to accidentally sever, no implicit contracts to violate. The capability boundary is a safety boundary.

Event contracts provide another form of guidance. When the AI sees that a capability subscribes to order-updated events, it understands the integration point without needing to trace import statements through the codebase:

// AI understands the integration contract explicitly
externalHandlers: {
  'order-updated': async (event, context) => {
    // AI can generate handlers knowing exactly what payload to expect
    const { orderId, status, timestamp } = event.payload;
    // ...
  },
}

For scaffolding entirely new capabilities, the structured approach is transformative. A prompt like "create a customer loyalty capability with points tracking and reward redemption" gives the AI enough to generate a complete, well-structured capability skeleton: manifest, action definitions with schemas, event declarations, viewer stubs, and even test files following your project's patterns. What might take a developer an hour of boilerplate becomes a starting point generated in seconds.

Perhaps most importantly, this architecture makes AI-generated code reviewable. When every action has a declared schema, when access controls are explicit in configuration, when events are typed and documented—the human reviewer can quickly verify correctness. The AI's output isn't a black box of interconnected mutations; it's a discrete unit with clear contracts that can be evaluated in isolation.

I've started thinking of well-structured capability architectures as a form of "AI-legible" code. Just as we write code for humans to read (with the computer as a secondary audience), we're now writing code for AI to read, understand, and extend. The patterns that make code maintainable for humans—explicit contracts, isolation, self-documenting structure—turn out to be exactly what makes code extensible by AI.

This creates a virtuous cycle. AI helps you build capabilities faster. Those capabilities follow patterns that make future AI assistance more effective. Your codebase becomes increasingly amenable to AI collaboration over time, rather than accumulating the kind of implicit complexity that confounds both humans and machines.

Practical Implications and Where This Leads

If you implement these patterns, you'll notice several things. First, your velocity on new capabilities increases. New capabilities don't fight with existing code—they snap into place. Second, your test coverage improves naturally. Isolated capabilities with clear action contracts are straightforward to test. Third, your application becomes genuinely multi-modal. The same codebase serves web users, CLI power users, and AI assistants.

Looking forward, these patterns position you well for scenarios that are rapidly emerging. Imagine AI agents that don't just respond to queries but proactively take actions on users' behalf. With explicit action definitions, proper access controls, and confirmation requirements, you've already built the foundation. Or consider the rise of ambient computing, where your application exists across watches, glasses, voice assistants, and traditional screens. Surface and experience abstractions let you mount capabilities appropriately for each context.

Turns out that the principles underlying resilient, maintainable applications—isolation, explicit contracts, event-driven communication, declarative configuration—are exactly what you need for AI-native, multi-modal, highly adaptable systems. It's not about predicting the future so much as building in a way that doesn't foreclose it.

If you've been grappling with application complexity, I'd encourage you to start small. Take one feature and refactor it into an isolated capability with explicit actions. Add event-based communication with one neighbor. Observe how the dynamics change. Then gradually extend the pattern outward. The architecture I've described isn't an all-or-nothing proposition—it's a direction of travel that pays dividends incrementally.

And the next time you're asked to add order history export functionality? It'll be a capability you define once and mount wherever it's needed. No surgery on houses of cards required.