Review the Run, Not the Diff: Cursor’s Shareable Canvases in a Fleet Loop

What shipped on October 16

Cursor’s changelog entry dated October 16, 2026 — “Cloud Agent Canvases and Environment Improvements” — is three short sections long, and one of them changes the shape of a finished run: “Cloud agents can now build interactive canvases as part of their work. Share a finished canvas with your team by sending its link.” That sentence is Cursor’s. Everything in this section is theirs, from that changelog entry and the Canvases page of their docs, read October 19, 2026.

A canvas, in their docs, is an interactive artifact that renders next to the chat: a standalone view laid out with sections, stats, and tables, instead of a long markdown table or a code block to scroll through. Ask an agent for a dashboard, an analysis, an audit, or a report, and Cursor opens the result in a canvas when a visual view is the better fit. The canvas is saved to the workspace’s canvas list, so you can reopen it, edit it, and rerun it later with fresh data.

Sharing is a publish, not a forward. From the canvas toolbar you Publish — which publishes a share or refreshes an existing one — then copy the link and send it. What the link opens is a live snapshot: the same layout, charts, and tables, without rerunning the agent and without digging through the chat history. Teammates open it in the browser with read-only access. A Shared Canvases page on the dashboard lists the shares you published yourself, so you can reopen, copy, or delete your own; it does not list a teammate’s shares — for those, you ask for the link.

The same release carried two more items, logged here for completeness. The Environments API is available in beta: a programmatic way to create and manage the cloud environments agents run in. And the environments themselves grew: up to 300 repositories per environment, with large environments loading 5x faster — Cursor’s numbers, not measurements of ours. Neither item is this piece’s subject; both are on the desk’s check list.

The gate is part of the story

A canvas link is not a public link. The docs are explicit: anyone on your team can open the link in the browser. Only members of your team can open a share, and you need to be on a team to share at all. Sending the link outside the team sends a door the recipient cannot walk through — which makes the canvas a team surface, not a publishing surface.

Sharing is also a paid-plan surface with conditions attached. Shares can be created on paid plans — Premium and higher, Teams, Enterprise, and the legacy Pro, Pro+, and Ultra tiers; free accounts cannot create shares. Sharing requires a privacy mode that allows data storage, so Legacy Privacy Mode blocks it. And a team admin can turn shared canvases off for the whole organization from team settings. A shop adopting the feature checks those three gates before it builds a habit on them.

A snapshot is not the run itself. The canvas shows the view as published; the chat, the reasoning, and the diff stay behind it. When the underlying numbers move, the share does not move with them — refreshing it is another Publish. A reviewer who needs the execution record still goes to the record. The canvas is the board on the wall, not the flight recorder.

Where it lands in our loop

Our loop fits in one sentence: a work order is written with everything the executor needs, the agent flies it, and the result is debriefed at the receiving end — the live page checked in a browser, the delivered file opened, the count re-added by hand. The debrief is where quality is decided here, and its surface depends on the seat. A cloud run launched over the API hands back result text. A Desktop sitting hands back a transcript and screenshots at verification points, which this shop trusts over any summary.

A canvas inserts a third surface into that debrief: the agent arranges its own evidence — sections, stats, tables — into the board the reviewer actually opens. For the data-heavy work this shop runs constantly — citation pulls, model-catalog diffs, site audits — a rendered board is the shape the answer wanted anyway. Cursor’s docs make the same point from their side: canvases earn their keep on data-intensive tasks, where information arranged non-linearly is easier to digest than a wall of text.

The approval moment in this shop is a tap on finished work. Will reviews results, not work in progress, and the decision lands on an artifact he can read in one pass. A canvas link is the first Cursor surface shaped exactly like that decision: open the link, read the board, decide. No repo, no diff, and no IDE sits between the finished result and the person approving it.

The lane question the feature raises is a seat question. What reaches Stefani and Ziggy today is finished artifacts — live pages, PDFs, one-line summaries — because they work outside the operator’s seat. A canvas would be the cheapest of those artifacts to produce and the easiest to read, if the recipients hold team seats. The docs make team membership the door, so who holds a seat becomes a setup decision to make on purpose — not an assumption to discover after a link bounces off someone it was meant for.

What is not established, labeled plainly: our production lane launches cloud agents over the API and receives text back. The docs describe canvases in the app surfaces — the Agents Window, the canvas toolbar, the dashboard. Whether a run launched through the API can produce a canvas, or return a share link, is not in the docs we read and not in our records. That question goes on the check list. It does not go into the workflow.

One more mapping, labeled as intent rather than record. The docs say common canvas workflows can be packaged as skills, so every run that uses the skill returns the same output shape. In this shop’s language, that is a debrief template: the same board for every fleet run — what was asked, what landed, what the counts say, what failed. A debrief-canvas skill is the first experiment this change earns here. It has not run yet.

Our record, stated plainly

No canvas has appeared in our runs yet. Our run record — every cloud agent this desk has launched, reconciled from the API and watched daily — contains no canvas artifact and no share link as of October 19, 2026. The only “canvas” in that record is an agent named for a Google Maps canvas, a different sense of the word, and a standing reminder to grep carefully before claiming a first.

So this piece is a map, written before the landing: what the feature is on the vendor’s own pages, what its gates are, and where it would sit in a loop that already exists. The check is decided. The next data-heavy Desktop sitting asks for its debrief as a canvas, by name, and the canvas gets read against the same sitting’s transcript — the surface we trust — before the desk adopts it anywhere. If the board and the record disagree, the record wins, and the disagreement gets written down on this page with a date.

Filed under the Cursor desk — the desk that runs Cursor as a production harness.