Description
A workspace can legitimately contain more than one Foundry hosted agent — for example a repo with several azure.yaml files that each declare a host: azure.ai.agent service. The Deploy & test section of the Microsoft Foundry canvas gives no indication of which of those agents its actions apply to, and offers no way to change it.
- Inspect Locally always runs the first agent returned by the workspace scan. The scan walks the workspace breadth-first with directory entries sorted alphabetically, so the agent that gets run is effectively decided by folder naming rather than by the user.
- Test in Foundry Portal does not appear at all. When the scan finds more than one hosted agent the resolution returns an
ambiguous_agent result, and the canvas suppresses the portal link instead of asking which agent to open. The user loses the action entirely.
Steps to reproduce
- Open the Microsoft Foundry canvas in GitHub Copilot App.
- Open a workspace that declares two or more hosted agents — e.g. two folders, each with an
azure.yaml containing a host: azure.ai.agent service.
- Expand the Deploy & test section.
- Click Inspect Locally.
Current behavior
- Nothing in the Deploy & test section names the hosted agent that its actions target.
- Inspect Locally starts whichever agent happens to sort first in the workspace scan. There is no way to inspect any of the other agents in the workspace.
- Test in Foundry Portal is hidden, so there is no way to reach the portal playground for any of the agents.
Expected behavior
- The user should be able to see which hosted agent Inspect Locally and Test in Foundry Portal apply to, and switch to a different one when the workspace has several.
- Test in Foundry Portal should stay available when a workspace has multiple hosted agents rather than disappearing.
- Workspaces with no hosted agent, or with exactly one, should behave exactly as they do today — there is nothing to disambiguate, so no extra UI should show up.
Description
A workspace can legitimately contain more than one Foundry hosted agent — for example a repo with several
azure.yamlfiles that each declare ahost: azure.ai.agentservice. The Deploy & test section of the Microsoft Foundry canvas gives no indication of which of those agents its actions apply to, and offers no way to change it.ambiguous_agentresult, and the canvas suppresses the portal link instead of asking which agent to open. The user loses the action entirely.Steps to reproduce
azure.yamlcontaining ahost: azure.ai.agentservice.Current behavior
Expected behavior