Protocols Don't Pick Providers

In early June, Microsoft announced Scout, an always-on autonomous agent for Microsoft 365. Scout can schedule meetings, surface risks, and act on behalf of users without repeated prompting. That is a capable product. It is not the interesting part.

The interesting part is the infrastructure choice. Scout is built on OpenClaw, an open-source agent runtime. Microsoft is not just using OpenClaw. They are contributing policy conformance capabilities upstream. They are actively investing in a runtime they do not own.

That is a signal worth thinking through carefully.

What Microsoft Just Signaled

To be clear about what the facts say and where inference begins.

Facts: Scout is built on OpenClaw. Scout can reach MCP servers. Microsoft is contributing policy conformance upstream to OpenClaw. On top of that open runtime, Microsoft has layered its own governance stack: Entra identity for each agent, Purview policy enforcement before data leaves the organization, audit controls, and approval workflows for sensitive actions.

Inference: when a company of Microsoft's scale builds on an open-source runtime and contributes back rather than forking or building proprietary alternatives, they are making a bet. The bet is that the runtime layer is not where they expect to create durable value. They are investing in the runtime to make it trustworthy for enterprise use, not to own it.

That is not a certainty. Microsoft may change course. OpenClaw may not achieve the adoption its name implies. But the structural logic is recognizable. IBM made a similar calculation with Linux in the early 2000s, contributing to a kernel it did not control because the kernel was not where the enterprise margin lived. Google made a version of the same bet with Kubernetes. Commoditize the plumbing; compete on the layers where enterprise relationships and switching costs are real.

What Microsoft is competing on is visible in where their differentiation sits: the coordination layer, the compliance layer, the identity layer. Not the agent runtime. The runtime is the floor.

When dominant players treat a layer as infrastructure, it has a tendency to become infrastructure.

When Capability Becomes Less Differentiating

This is not a prediction that agents will shortly be able to do everything. That is too broad to be useful.

The narrower claim is more interesting: for a growing category of standardized business tasks (email verification, contact enrichment, entity extraction, document classification, domain reputation checks, address validation), the proliferation of agent runtimes, MCP servers, and APIs is making capability less differentiating. Multiple providers can already execute many of these tasks. More will be able to do so as open runtimes lower the barrier to building and exposing services.

When any reasonably capable agent runtime can reach the same pool of providers through shared protocols, the question "can an agent do X?" starts to resolve earlier in the conversation. For these standardized tasks, the answer is increasingly yes. That is a good development. Capability abundance lowers the floor for everyone.

But it creates a different problem.

When fifty providers can verify an email, the question that cannot be answered by the protocol becomes the central one: which of them should execute this particular job, right now, for this operator, under these constraints?

The Selection Problem

Take that email verification case concretely.

Fifty providers expose email verification via API or MCP. They are reachable. The runtime handles the connection. And yet an agent submitting this job still faces a decision with significant variance in outcome.

Price is not a fixed number. It fluctuates with provider demand, pricing model, and volume. The cheapest option this morning may not be the cheapest option this afternoon.

Accuracy is not uniform. Email verification quality varies by domain category, industry vertical, and geographic region. A provider that performs well on consumer email domains may perform poorly on corporate or international ones. The spec sheet does not capture this. Historical performance data does.

Latency is live state. What the provider advertises and what it delivers under current load are different things. A job with a strict time constraint needs a routing decision based on observed performance, not documented SLAs.

Policy constraints differ per customer. One operator's compliance requirements prohibit transmitting data to certain jurisdictions. Another has an approved-vendor list tied to a procurement process. A third has sector-specific regulations that constrain which providers can touch sensitive records. These constraints are not static, and they do not live in the provider's API documentation.

Trust is not implied by reachability. A provider that was reliable for the last ninety days may have degraded. A new provider with competitive pricing may have no track record at all.

Microsoft's own architecture for Scout recognizes this directly. They enforce Purview policies before data leaves the organization. They scope credentials to the task at hand. They build in human sign-off for sensitive actions. Even in a fully connected agent runtime with open protocols, they understand that what an agent can reach and what it should reach are different questions.

Protocols solve portability. They do not solve selection. They do not solve trust. They do not solve quality assurance. They do not solve routing, settlement, or execution markets. The protocol is the prerequisite; it is not the answer.

The Stack Always Has a New Top

This is not an unusual pattern. Infrastructure standardization shifts competition, but it does not eliminate it. It relocates it.

TCP/IP standardized the network layer. The valuable companies were built above it: email, search, e-commerce, social networks. The protocol became invisible because it became assumed.

Linux standardized the server operating system. Enterprise value moved to distributions, managed services, and the applications running on top. Red Hat and SUSE competed on support, tooling, and integration. Not the kernel.

Kubernetes standardized container orchestration. Cloud providers responded by offering managed Kubernetes and competing on the services wrapped around it.

Postgres and MySQL made relational databases accessible to anyone. Value moved to the data products, analytics infrastructure, and managed services built on them.

The pattern is not that software gets commoditized and dies. It is that when one layer standardizes, the layer above it becomes the new surface for competition. The infrastructure becomes unremarkable, which means the interesting problems and the margin move upward.

Agent runtimes appear to be undergoing the same transition. The question worth asking is what the layer above them looks like.

The Job as the Atomic Unit

If the runtime is shared infrastructure and multiple providers can execute the same standardized tasks through that runtime, the per-provider subscription relationship starts to look arbitrary for those capability categories. Not because subscriptions are always wrong, but because the moat that justified them (proprietary access, integration lock-in, no comparable alternative) is eroding for standardized work.

What agents and operators actually need in that environment is different. They need to declare a piece of work, get a result, and pay for successful execution. They do not need a strategic relationship with a particular provider for tasks that multiple providers can handle equally well.

The job becomes the atomic unit. Defined input, defined output type, defined cost, executed by whoever can perform it correctly under current conditions. The specific provider is a routing decision, not a procurement decision.

This is not primarily a billing argument. The billing follows from the structure. If execution is routed to the best available provider at job submission time, the fixed subscription to a single provider makes less sense for these tasks. The more fundamental shift is in how execution logic gets organized. Procurement becomes routing. Contracts become market mechanisms.

What the Missing Layer Has to Do

If agent runtimes become shared infrastructure and the job is the atomic unit of execution, something has to exist between the agent submitting jobs and the pool of providers capable of executing them. That layer has a clear job description.

It needs to route each job to the right provider based on current conditions: not just capability, but price, latency, accuracy history, and policy conformance for this operator's specific constraints.

It needs to quote cost before execution starts. The operator should know what a job will cost before committing to it.

It needs to verify that results meet the spec before settlement. A completed job that returns bad data is not a completed job.

It needs to enforce job-level policy. Not just operator-level policy managed by an IT team, but per-job constraints that travel with the work as it routes through the system.

It needs to settle. When a job completes, the provider gets paid. When it fails, it does not. The mechanism that handles that is not a protocol. It is an economic layer.

And it needs to build trust signals over time. Which providers perform well on which job types, under which conditions, for which customer profiles. That knowledge does not come from a specification. It comes from the accumulated history of execution.

None of these are protocol problems. The protocol makes providers reachable. This layer makes them comparable, selectable, and accountable. It is the market mechanism the protocol layer needs in order to produce reliable outcomes at scale.

The Question That Matters Now

The Scout announcement is worth paying attention to not because an autonomous agent now exists, but because of what the infrastructure choice suggests about how the stack may develop.

If Microsoft's bet is correct (that the runtime is infrastructure, not a source of durable differentiation), then the interesting competition is above the runtime. The enterprise application layer, where Microsoft is clearly competing, is one surface. But above the runtime and below the application, there is a layer that has to exist and does not yet have a clear incumbent.

The question worth spending time on in 2026 is not whether an agent can perform a task. For a growing category of standardized work, that question is resolving. The harder question is which provider should execute that task: at what cost, under what policy constraints, with what quality assurance, and settled how.

That question is not answered by a protocol. It is answered by a market.

OpenMerch is building the job layer: the execution market that sits between agents and the providers they rely on.