When chat is the wrong UI: GitHub's canvases and the case for having agents build tools

GitHub is making the case that the chat box is holding agent work back, and the argument holds up well beyond coding.

What happened

In two GitHub Blog posts this week, GitHub introduced canvases in the GitHub Copilot app. A canvas is a small full stack app that runs inside the Copilot app and talks both ways with the agent: you click buttons, move cards or edit fields, and the agent sees the change and can update the interface itself. You create one with the /create-canvas skill by describing the workflow, what you should be able to do, and what the agent should be able to do. Canvases save as extensions you can keep with a project for your team or keep personal.

In "When chat is the wrong UI," Burke Holland argues that chat pushes people to use the agent for everything, which he calls "often just a pure waste of tokens." His advice: it is almost always better to have the agent build a tool where future interactions are free than to treat the agent itself as the tool. His examples include a SQLite query canvas and a package manager UI that uses no AI at all.

My take

This is the most practical idea I read this week, and it maps directly onto business automation.

Clients often ask for "an AI that does X" when X is the same task every day. Running a model on every repetition costs money and adds variability. The better build is usually:

1. Use AI once to design and build the tool, form, dashboard or workflow.
2. Let the tool do the repeated work deterministically.
3. Bring the agent back only for the parts that need judgment, like reading an unusual request.

A shared surface also fixes the trust problem. When the team can see a board the agent updates, with buttons to approve or move things, nobody has to scroll a chat log to know what happened.

So before adding a chat window to a process, ask what the person actually needs to see and change. Often the answer is a simple board or form, with AI working behind it.