THE DEATH OF THE PROXY: Architecting Dataverse for the Agent Fabric

For years, Microsoft's recommended architecture for connecting AI assistants like Claude Desktop to Dataverse relied on a local STDIO proxy. It was simple, easy to install, and perfectly suited for individual developers experimenting with AI-powered workflows. But enterprise AI has evolved. Organizations are no longer connecting a single assistant to a single application. They're connecting hundreds—or even thousands—of AI agents across multiple clients, platforms, and business systems. That architectural shift changes everything. This episode explains why the traditional proxy model has reached its limits, why Streamable HTTP fundamentally changes enterprise AI integration, and how Dataverse is evolving from the database behind Power Apps into the governed data backbone for the entire Agent Fabric.

WHY THE STDIO PROXY WAS CREATED
The original STDIO proxy solved a very specific problem. Early MCP clients like Claude Desktop needed a simple way to communicate with cloud services while running locally on a developer's machine. Instead of exposing an internet-facing endpoint, developers launched a local process that translated communication between the AI client and Dataverse. The advantages were obvious:

• Simple installation
• No HTTP server required
• No certificates
• Minimal infrastructure
• Isolated execution per user

For individual developers, this architecture worked remarkably well. Every proxy was independent, failures affected only one user, and deployment required little more than installing a small application. The problem wasn't that the proxy stopped working. The problem was that enterprise AI completely outgrew the assumptions behind it.

THE PROXY SCALING PROBLEM
The proxy architecture assumes one developer. Modern enterprises operate very differently. Instead of one Claude Desktop instance, organizations now deploy:

• Claude Desktop
• Claude Code
• GitHub Copilot
• Copilot CLI
• Custom orchestration services
• Internal AI assistants

Each proxy creates:

• Independent authentication
• Separate connection pools
• Individual infrastructure
• Separate monitoring
• Isolated failure domains

As organizations scale from ten developers to hundreds or thousands, operational complexity increases exponentially. Instead of managing one governed service, administrators find themselves maintaining hundreds of disconnected proxy processes with little centralized visibility or control. What began as a convenience gradually becomes operational debt.

THE LATENCY MYTH
One of the strongest arguments for STDIO has always been performance. Microbenchmarks show local inter-process communication taking only a few milliseconds, while HTTP introduces network latency and TLS negotiation. On paper, STDIO appears dramatically faster. However, those benchmarks ignore the actual workload. Most Dataverse operations spend hundreds of milliseconds—or even more than a second—executing business logic, security checks, and database queries. When those execution times are included, HTTP overhead becomes relatively insignificant. Even more importantly, enterprise HTTP deployments benefit from:

• Connection pooling
• Persistent sessions
• Horizontal scaling
• Long-lived services
• Shared infrastructure

Meanwhile, every new proxy instance pays startup costs, authentication overhead, and process initialization repeatedly. The presentation argues that organizations measuring end-to-end performance often find properly optimized HTTP deployments outperform local proxy architectures despite their higher transport latency.

STREAMABLE HTTP CHANGES EVERYTHING
Instead of every AI client running its own proxy, Dataverse now exposes a single Streamable HTTP endpoint. Every supported AI client connects to exactly the same service. Examples include:

• Claude Desktop
• Claude Code
• GitHub Copilot
• VS Code
• Custom AI orchestrators

Rather than multiplying infrastructure for every new user, organizations scale a single enterprise service. Additional capacity simply means adding more server instances behind a load balancer. Clients continue connecting to the same endpoint while the platform handles scaling transparently. The architecture shifts from isolated desktop utilities to enterprise-grade shared infrastructure.

PKCE ENABLES SECURE PUBLIC CLIENTS
Moving to HTTP introduces a new challenge: How do desktop applications authenticate without storing client secrets? The answer is PKCE (Proof Key for Code Exchange). Instead of embedding long-lived secrets inside client applications, PKCE generates temporary cryptographic values during authentication. This approach allows applications like:

• Claude Desktop
• Claude Code
• GitHub Copilot

to authenticate securely using Microsoft Entra ID without exposing credentials. Authentication becomes:

• Secret-free
• User-based
• Standards compliant
• Automatically renewable

This security model enables enterprises to deploy multiple AI clients without distributing confidential application secrets to every workstation.

DATAVERSE BECOMES THE AGENT FABRIC
Perhaps the most important architectural shift is how Dataverse itself is positioned. Historically many organizations viewed Dataverse simply as the database behind Power Apps. The presentation argues that this perspective is obsolete. Dataverse now becomes the central business data platform for AI agents. Every supported AI client communicates through the same endpoint. Every request uses:

• Shared governance
• Shared authentication
• Shared business logic
• Shared security
• Shared audit trails

Instead of building separate integrations for every large language model, organizations expose one governed platform that every compliant client can consume. This transforms Dataverse from an application database into enterprise AI infrastructure.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.