Azure Foundry workflow agents deployment issue

S K, Raghav 60

Workflow Setup (Tools & Configuration Only)

I have a multi-agent workflow built in Microsoft Foundry and published to Microsoft Teams / Copilot using InvokeAzureAgent.

The workflow consists of four sequential agents:

Agent 1 Initially used: web_search_preview tool Now: No tools configured
```
  Output type: text (Markdown)
```
Agent 2 No tools configured Output type: text
Agent 3 No tools configured Output type: text

Agent 4 No tools configured Output type: text

  This is the only agent that sends output back to Teams

All agents are configured with:

model: gpt-4.1

Text-only output

No structured/JSON output

No function calling enabled

Issue Observed

When running the published workflow from Teams / Copilot, execution fails with the following error:

downstream_error: Unhandled workflow failure
No tool output found for remote function call <call_id>
No handler found for message type PortableValue in InvokeAzureAgentExecutor

The error consistently appears at the Agent 4 invocation, even though:

Agent 4 has no tools
Agent 4 is text-only

Error Message in Copilot/Teams:
Response failed with code downstream_error: Unhandled workflow failure - #agent4 (InvokeAzureAgent) -> {"error":"Error invoking agent","agent":{"type":"agent_reference","name":"Agent 4","version":"4"},"conversation_id":"conv_7352e42c2758058400fkx9YhCYSAxSQjZvtt80UxRzgic9drjY","details":{"error":{"message":"No tool output found for remote function call call_c0080b0bf33a4e8693adc9a813e4c058.","type":"invalid_request_error","param":"input","code":null}}}. If issue persists, please use following identifiers in any support request: ConversationId = 19:RfjInPqXqN_rZ7VJd5fL54f3AnLGN4gEd-6tsJCdKC01@thread.v2, activityId = 1767687882826

Gowtham CP 7,960 Reputation points Volunteer Moderator

2026-01-06T10:05:38.1866667+00:00

Hi S K, Raghav ,

Thanks for sharing the details.

Based on the Azure AI Foundry agent execution contract, the behavior you’re seeing is expected when a workflow is invoked via InvokeAzureAgent and the terminal agent is responsible for returning the response to Copilot / Teams.

According to the Azure AI Foundry agent model, InvokeAzureAgent operates through a remote execution boundary where agent responses are normalized through the same internal pipeline used for tool execution and function resolution. Even when an agent is configured as text-only and does not explicitly declare tools, the runtime still expects the agent turn to resolve through a handled execution output before returning control to the host (Copilot / Teams).

When the final agent does not emit a resolvable execution output at this boundary, the runtime attempts to reconcile the response as a remote call result, which leads to errors such as:

No tool output found for remote function call

No handler found for message type PortableValue

This is why the failure consistently occurs at the last agent invocation, and not during earlier agents that do not cross the Copilot return boundary.

Recommended approach

Keep Foundry agents focused on intermediate reasoning or enrichment

Return the final response from the application or Copilot layer

Avoid relying on a terminal Foundry agent as the direct response emitter to Teams

This aligns with how Azure AI Foundry positions agents—as composable reasoning units rather than end-to-end conversation controllers.

References

Azure AI Foundry agents overview
https://learn.microsoft.com/azure/ai-foundry/agents/overview

Tool execution and agent orchestration behavior
https://learn.microsoft.com/azure/ai-foundry/agents/how-to/tools/overview

Hope this clarifies the behavior. If this answers your question, please accept it to close the thread.
SRILAKSHMI C 19,005 Reputation points Microsoft External Staff Moderator

2026-01-07T09:48:12.8566667+00:00

Hi S K, Raghav,

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!
S K, Raghav 60 Reputation points

2026-01-09T04:04:30.5833333+00:00

Thank you all for the suggestions and detailed explanations.

The issue is now resolved. Based on the inputs shared here, I realized that the problem was with the final agent in the workflow returning structured/tool-based output instead of a plain text message. Instead of performing reasoning and tool access in the last agent, I added an additional agent whose sole responsibility is to summarize and normalize the output into a simple text response.

Once this change was made and the agent was republished, the workflow started working correctly in Teams/Copilot without the PortableValue or tool-output errors.

I appreciate everyone taking the time to share their insights — the guidance was very helpful.
SRILAKSHMI C 19,005 Reputation points Microsoft External Staff Moderator

2026-01-09T11:51:07.3966667+00:00

Hi S K, Raghav,

I’m glad to hear the issue is now resolved and that separating the reasoning/tool execution from the final response formatting addressed the Teams/Copilot output errors. Adding a dedicated summarization agent to return plain text is a good design pattern and aligns well with how Copilot expects responses.

Appreciate you taking the time to confirm the fix and share your learnings this will be helpful for others facing similar scenarios.

Since I’ve converted my earlier comment into an answer, could you please take a moment to mark it as Accepted? This helps others in the community with the same question find the solution more easily.

Thank you!

Answer accepted by question author

Sina Salam 29,846 Volunteer Moderator

Hello S K, Raghav,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having Azure Foundry workflow agents deployment issue.

To resolve this, you must first ensure that the workflow’s final handoff returns a Basic chat > text message, not a structured or tool‑dependent value. This involves reviewing each agent node in the Foundry visualizer to confirm that the output is explicitly saved as plain text (for example, Local.LatestMessageText) and that no node expects or emits tool output. The Foundry workflow guidelines emphasize using clearly defined message types and understanding how variables flow through sequential nodes to prevent unintended PortableValue serialization.

Next, convert any remaining structured values into text before the final message is sent. If a data transformation node or agent produces a PortableValue or structured element, use a Set‑Variable or Parse‑Value node to fully stringify the content. This avoids the PortableValue error that arises when Teams/Copilot expects a chat message but receives an unsupported type. The Agents in Workflows guide’s sequential agent pipeline demonstrates how message consistency ensures that downstream executors can successfully process outputs without expecting tool calls.

Once the workflow’s output path is fully normalized, republish the agent so it receives a stable endpoint and proper identity through Foundry’s publishing mechanism. Microsoft recommends verifying that users interacting with the published agent in Teams or Copilot have the appropriate Azure AI User role on the Agent Application scope to prevent runtime invocation errors. You can find these publication requirements and RBAC details in the Foundry agent‑publishing documentation - https://learn.microsoft.com/en-us/azure/ai-foundry/agents/how-to/publish-agent.

Finally, run validation tests in Teams/Copilot and monitor the conversation traces in Foundry’s observability dashboard to ensure the workflow is now returning a clean text message with no tool bindings. If using azd or hosted agent infrastructure, also verify the regional limitations and preview constraints described in the Azure Developer CLI agent extension guide: https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/extensions/azure-ai-foundry-extension. This complete alignment of workflow output type, publishing configuration, and environment constraints reliably eliminates the recurring PortableValue and missing tool‑output failures.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

0 comments

Answer accepted by question author

SRILAKSHMI C 19,005 Microsoft External Staff Moderator

Hello S K, Raghav,

Welcome to Microsoft Q&A.

Thank you for the detailed workflow description and error context. Based on the behavior and error messages, this does not appear to be a misconfiguration on your side, but rather a service-side limitation in Azure AI Foundry’s multi-agent workflow execution when invoked via Teams / Copilot.

Explanation of the issue

Although Agent 4 is configured as a text-only agent with no tools, the InvokeAzureAgent execution layer processes agent outputs in the same pipeline used for tool outputs and function calls. At the end of a multi-agent chain especially when the final agent’s output is sent directly to Teams / Copilot the runtime incorrectly expects a resolvable tool or function output.

Because Agent 4 does not emit a tool-backed response, the runtime fails with errors such as:

“No tool output found for remote function call”

“No handler found for message type PortableValue”

This explains why the failure consistently occurs at Agent 4, even though it has no tools and produces only plain text. The issue lies in how the Foundry runtime handles terminal agent responses across the remote execution boundary, not in the agent’s configuration or model selection (gpt-4.1 is supported).

Recommended approaches and workarounds

To unblock your scenario while this is being addressed, you can consider the following options:

Use Foundry agents primarily for intermediate reasoning and processing. Route the final response to Teams/Copilot through your application or Copilot layer instead of directly from the last agent.

Even if unused, this allows the runtime to receive an expected output structure and avoids the tool-resolution failure.

Add an additional agent after Agent 4 to handle the final Teams response, keeping Agent 4 internal to the workflow.

Foundry Classic does not exhibit this behavior and is recommended for trials and validation until the new workflow runtime is stabilized.

Please refer this

I Hope this helps. Do let me know if you have any further queries.

Thank you!

0 comments

1 additional answer

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Share via

Azure Foundry workflow agents deployment issue

Workflow Setup (Tools & Configuration Only)

Issue Observed

Recommended approach

References

1 additional answer

Your answer