OpenClaw's Microsoft Foundry Bugs Are What Enterprise Agent Integration Actually Looks Like

Enterprise agent integration does not usually fail in the dramatic places. It fails in the seams: the auth mode that passes its connection test but cannot persist config, the alias provider that looks equivalent to the base provider until one request argument crosses the wire, the reasoning knob that is treated like a portable standard even though the upstream API never agreed to that contract.

That is why two small OpenClaw pull requests from June 7 are more interesting than their diff size suggests. PR #91045 fixes Microsoft Foundry Entra ID onboarding after users hit a strict schema rollback on thinkingLevelMap. PR #91046 fixes Foundry-backed DeepSeek V4 aliases that were still receiving a top-level thinking parameter and failing with 400 Unrecognized request argument supplied: thinking. These are not glamorous launch-demo bugs. They are exactly what enterprise agent platforms look like once they leave the happy path.

The first failure is especially telling. Issue #91011 reports that openclaw models auth login --provider microsoft-foundry --method entra-id successfully completes the provider connection test, then fails atomic config persistence because models.providers.microsoft-foundry.models.0 rejects thinkingLevelMap as an unknown key. In other words: the runtime knew enough to authenticate against Azure AI Foundry using Entra ID, but the config write path did not know enough to serialize the model metadata it had just learned.

That distinction matters. Entra ID and managed identity are not enterprise garnish; they are the production path. Organizations do not want long-lived static API keys pasted into local agent configs if they can avoid it. They want scoped cloud identities, rotation, audit trails, and access governed by the same identity plane they already use. If OpenClaw can test the connection but cannot persist the provider definition, then the supported enterprise auth path becomes a manual-config exercise. That is not a small UX paper cut. It is a trust failure at onboarding.

Provider families beat provider strings

The second bug is the same class of problem from another angle. Issue #90520 shows a Foundry deployment failing as microsoft-foundry-9433/DeepSeek-V4-Pro while succeeding when promoted to the literal microsoft-foundry/DeepSeek-V4-Pro provider ID. The request path named in the PR runs through applyExtraParamsToAgent, createDeepSeekV4OpenAICompatibleThinkingWrapper, and isDeepSeekV4OpenAICompatibleModel. The fix changes the DeepSeek V4 OpenAI-compatible thinking guard from an exact provider match to a Foundry-family prefix check.

This is the kind of bug every model-router eventually earns. Teams create aliases for regions, projects, billing groups, compliance boundaries, preview deployments, and internal naming conventions. The runtime cannot assume the literal provider string is the provider identity. If microsoft-foundry-9433 is operationally a Foundry deployment, then Foundry compatibility policy has to follow it. Otherwise aliases preserve flexibility while bypassing the very normalization and safety logic that made the base provider work.

The reasoning-field detail is also worth slowing down for. Agent platforms are increasingly exposing “thinking” or reasoning controls as if they were generic model settings. They are not. Some providers accept explicit reasoning knobs. Some reject them. Some expose budget controls. Some require provider-specific wrappers. Some models are OpenAI-compatible only until you send the one field they do not recognize. OpenAI-compatible is a transport promise, not a semantic compatibility guarantee.

For practitioners, the takeaway is to stop testing provider support as a single inference call. A serious provider adapter needs contract tests across at least six surfaces: auth mode, persisted config, normalized runtime config, model aliasing, request-shape transformation, and error recovery. If the provider supports multiple identity modes, test each one. If the runtime supports aliases, test aliases. If the model has reasoning controls, test both enabled and suppressed paths. The bugs here survived because different parts of the platform had different definitions of the same provider.

There is a broader product lesson too. Enterprise integrations are mostly boring until they are not, and boring is where agent infrastructure wins or loses. Nobody buys an agent platform because its config schema accepts thinkingLevelMap. But they absolutely stop trusting one if the official managed-identity onboarding path passes validation and then rolls itself back. Nobody demos provider-family predicates. But the first time a regional Foundry alias breaks a DeepSeek deployment because one compatibility guard checked the wrong string, the platform looks brittle.

OpenClaw's fixes are small, but the direction is right: make provider governance family-aware, make write paths as strict and complete as read paths, and treat reasoning metadata as provider-specific policy rather than a universal knob. That is what “enterprise-ready” usually means in practice. Not a new splash screen. Fewer absurd failures at the boundary between identity, config, aliases, and runtime requests.

The useful engineering move is to model provider support as a matrix, not a checklist. A Foundry adapter that works for API-key auth but not Entra ID is not complete. A DeepSeek wrapper that works for the canonical provider ID but not aliases is not complete. A config schema that validates generated docs but rejects runtime-discovered metadata is not complete. This sounds pedantic until the broken case is the one your deployment standardizes on.

Sources: OpenClaw PR #91045, OpenClaw PR #91046, Issue #91011, Issue #90520