Microsoft Agent Framework .NET 1.17.0 fixes false success in a Foundry workflow path

Microsoft Agent Framework .NET 1.17.0 changes how Foundry-backed declarative workflows handle a failed agent run. In the affected path, a Responses API response.failed event could reach the workflow as an update with no content. The engine saw no error, continued to the next action, and could finish with a completed status and an empty message.

The August 4 release restores the missing failure signal and stops the workflow before it reports completion or copies the failed response into conversation state. Teams using this exact .NET declarative and Foundry path now have a bounded upgrade decision: replay one known provider failure in non-production and verify the failure state, downstream behavior, stored conversation, and exposed error detail.

The provider failure became an ordinary empty update

The failure began at the boundary between the provider event and the workflow engine. The Responses API emitted response.failed, but Microsoft.Extensions.AI.OpenAI mapped that event to a contentless AgentResponseUpdate. The raw representation still identified a StreamingResponseFailedUpdate, but the update's normal content collection gave the workflow engine no error to interpret.

In the pre-fix path shown in PR 7497, AzureAgentProvider passed that update through. A contentless update is valid in other circumstances, so the declarative engine could not infer failure from the absence of text alone. The public tests preserve this distinction: an ordinary contentless update still does not fail a workflow, while a contentless update whose raw representation identifies response.failed now does.

That lost distinction explains the false success. The engine accepted the response, advanced to the next declarative action, and could emit a completed result with an empty message. The original issue states the expected behavior plainly: the agent failure should fail the workflow, and the next node should not execute as if the agent succeeded.

Version 1.17.0 restores the failure signal in the provider

The first part of the fix is in AzureAgentProvider. It inspects each streamed update and looks through the nested raw representation for StreamingResponseFailedUpdate. When it finds one, it replaces the contentless update with a new AgentResponseUpdate that contains ErrorContent.

The replacement carries the author name and response ID for correlation. It also carries the original creation time when available. If the provider supplied an error, the new content includes its message and code. If the failed event contains no error detail, the provider uses The agent run failed. and the code failed, so the workflow still receives an explicit failure signal.

Replacement matters for information control. The original raw representation can include provider error text, and streamed updates can reach clients directly. The new update does not retain that raw failed response. It gives the workflow engine a typed error while preventing the original provider object from bypassing the host's exception-detail policy.

The workflow engine now stops before completion and conversation copy

The second part of the fix is in AgentProviderExtensions. As updates arrive, the extension checks for ErrorContent. An error update is withheld from the normal autoSend path because that path forwards updates as workflow events before the host can apply its exception-detail setting.

After the updates have been combined into an AgentResponse, the extension checks the response for errors. If it finds one, it throws a DeclarativeActionException. This happens before the engine announces a completed agent response and before it copies the response into the declarative workflow's conversation state.

The rule also covers refusals because refusals use ErrorContent. It does not treat an incomplete response as the same failure because incomplete responses can contain usable partial content. When more than one error is present, the last error wins, which lets a specific cause replace the generic fallback that can arrive first.

Error detail then follows the host policy. By default, the hosted agent reports the failure without exposing the provider message or agent name. A host that explicitly enables exception details can include the agent name, error code, and provider message. Failure remains visible in both cases; only the permitted detail changes.

The operational result changes even though Microsoft calls the fix non-breaking

Microsoft marked PR 7497 as non-breaking. That classification can coexist with a meaningful change in runtime behavior. A provider failure that previously reached the end as false success should now enter the workflow's failure path.

That change can affect alerts, retries, compensation, and any local code that reacts to workflow status. Teams should inspect those behaviors during the trial, even though Microsoft does not present the package change as an API break. A downstream process should no longer receive completed as permission to continue when the Foundry agent run failed.

The evidence has a firm scope. It covers the .NET declarative workflow path through the Foundry AzureAgentProvider shown in the PR. The release, issue, and tests do not establish that all Agent Framework workflows or all providers had this behavior. They also do not establish an affected-version range, prevalence, customer incidents, or frequency.

The tests define what this fix is expected to protect

The public diff and tests cover both sides of the failure boundary. Provider tests construct the same contentless shape produced for response.failed and verify that AzureAgentProvider turns it into ErrorContent. They also verify a generic fallback when the event has no detail and confirm that successful and ordinary contentless updates still pass through.

Workflow tests cover the original false-success path and refusals. They exercise autoSend on and off, streaming and non-streaming callers, default redaction, and optional exception detail. A test workflow places an AFTER_AGENT action after the agent invocation and verifies that the downstream action does not run after the provider failure. Other assertions verify that the engine emits a failed executor event and that raw provider detail does not leak through streamed updates under the default host policy.

These tests support the intended mechanism, but they do not replace a local replay. Your host settings, monitoring, retry rules, and downstream actions decide whether the corrected failure reaches operators and connected systems in the form you expect.

This runtime fix serves a different purpose from workflow design

Our earlier article on keeping deterministic routing and error handling in workflow code addresses a design-time architecture choice. PR 7497 addresses a narrower runtime problem: the workflow code could only enforce its failure route after the provider failure remained recognizable across the adapter boundary.

Recovery remains a separate concern. Once the workflow stops correctly, the team still needs to decide whether to retry, compensate for earlier side effects, or keep the workflow disabled. The broader rollback guidance covers that work; this release decision needs only a controlled failure replay.

Replay one known failure before adopting the release

Trial .NET 1.17.0 in a non-production environment that uses the same declarative workflow, Foundry provider, host policy, and downstream action shape as production. Trigger one known provider failure that previously exercised this path. Use the host's workflow events and stored conversation state as evidence, not the presence or absence of visible text alone.

Adopt the release for this path only when the replay shows all of these outcomes:

• The agent action stops and the workflow records a failed state.
• The next action does not run.
• The engine does not report the failed agent response as completed.
• The failed response is not copied into conversation state.
• Streaming and non-streaming callers see only the error detail allowed by the host's exception-detail policy.

Hold the upgrade for this path if any assertion fails, or if local retry and alert behavior turns the new failure state into an unsafe follow-on action. Teams that do not use this exact .NET declarative and Foundry path have no action to take from this fix alone.

If the replay exposes a gap between provider failures, workflow state, and downstream controls, BaristaLabs can help connect those parts through focused process automation. The useful outcome is a workflow that stops for the right reason and leaves enough evidence for the operator to decide what happens next.