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 CREATEDThe 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 installationNo HTTP server requiredNo certificatesMinimal infrastructureIsolated execution per userFor 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 PROBLEMThe proxy architecture assumes one developer. Modern enterprises operate very differently. Instead of one Claude Desktop instance, organizations now deploy:Claude DesktopClaude CodeGitHub CopilotCopilot CLICustom orchestration servicesInternal AI assistantsEach proxy creates:Independent authenticationSeparate connection poolsIndividual infrastructureSeparate monitoringIsolated failure domainsAs 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 MYTHOne 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 poolingPersistent sessionsHorizontal scalingLong-lived servicesShared infrastructureMeanwhile, 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 EVERYTHINGInstead 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 DesktopClaude CodeGitHub CopilotVS CodeCustom AI orchestratorsRather 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 CLIENTSMoving 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 DesktopClaude CodeGitHub Copilotto authenticate securely using Microsoft Entra ID without exposing credentials. Authentication becomes:Secret-freeUser-basedStandards compliantAutomatically renewableThis security model enables enterprises to deploy multiple AI clients without distributing confidential application secrets to every workstation.DATAVERSE BECOMES THE AGENT FABRICPerhaps 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 governanceShared authenticationShared business logicShared securityShared audit trailsInstead 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.