microsoft / microsoft/foundry-dev-tools
Define a shared Chat and canvas workflow for hosted-agent creation
@qinezh is already working on this.
Since Jul 28, 2026.
- Dominant language
- JavaScript
- Stars
- 2.1k
- Forks
- 260
- Avg merge
- 42m
- Merged PRs (30d)
- 29
Description
Description
Copilot Chat and the Foundry agent canvas do not currently behave as two views of one hosted-agent workflow. Users may start from Chat or open the canvas directly, but intent, progress, deterministic choices, and deployment state are not shared coherently. The signed-out canvas also exposes later steps too early, while creation does not offer clear routes for samples or existing local agents.
This parent issue should establish the product and interaction contract before the system-level findings are decomposed into implementation work.
Decision required
- Define which surface owns intent, progress, confirmation, generated files, deployment state, and recovery at each step.
- Define the state shared bidirectionally between Chat and canvas.
- Use progressive disclosure based on authentication, project selection, task progress, and agent readiness.
- Decide the supported entry routes: start from intent, start from a sample, or continue an existing local hosted agent.
- Define when deployment becomes available and what “ready to deploy” means.
Record the review outcome as Adopt, Needs design, Defer, or No action. Create implementation work only for adopted routes and contracts.
Findings
C59 — Chat–canvas interoperability
When a prompt started from the chat, the agent cannot interchangeably operate with Foundry agent canvas.
I think some users would start from opening Foundry agent canvas manually and click through the buttons to create agents, but others would feel more comfortable to start from the chat.
The gap here is that the chat -> foundry agent canvas is not working well, the canvas must be operated deterministically on the canvas.
What I would expect to have as a smooth experience is, the canvas remains as a supporting role, showing the progress, illustrating clear steps, and operate deterministically when user needed it. Otherwise, it should interchangeable work between agent chat and canvas, e.g., if I open a word canvas, I can ask agent to edit the content in the word, and it does show the changes in real-time on the canvas side.
C60 — Progressive first-run workflow
Problem: All steps are linearly displayed, although the very first step might be signing in.
Problem: Deploy to Foundry seems to be highlighted but it should not be the primary action in the beginning.Can we perhaps show the UI according to the step? For example, for first-timers, we show sign in exp, and ask them to either create a new hosted agent or pick up from existing ones..
C61 — Creation and continuation routes
Problem: No option to select existing hosted agent
Problem: No samples
Source reply:
Suggestion: Show three options; start with intent, provide samples, pick up from the existing hosted agents (local)
Follow-up work items
- C62: Keep the workflow focused on the active step.
- C63: Show selected hosted-agent configuration.
- C64: Gate deployment until prerequisites are complete.
Size
L — Cross-surface product, interaction, and state-contract decision.
Source
Internal UX audit, July 27, 2026. FigJam evidence. POC report: vscode/extension/ai-mlstudio/docs/experience-audit/agent-canvas-2026-07/report.md (not yet published upstream).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.