Episode Details

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 conn