GitHub Copilot just shipped canvases. On the surface, it looks like a UI refresh. Under the hood, it signals that chat-only interfaces cannot handle long-running agent work.
Chat is good for intent. It is bad for state. When an agent spends thirty minutes across a branch, a browser, a terminal, and a pull request, the transcript becomes archaeology. Somewhere in the scroll is the plan. Somewhere else is the reason it changed direction. Somewhere else is the test failure. That is not a serious review surface.
Canvases are the architectural answer. They turn agent work into an inspectable object with persistent state, not a pile of messages.
Why Chat Breaks Down for Multi-Step Work
Chat works when tasks are small and synchronous. “Explain this function.” “Write a test.” “Change this prop.” The human holds the goal, context, and result in their head. The transcript is messy but tolerable.
Long-running agent work is different:
- The agent makes a plan, then revises it based on test output.
- It opens files, edits them, runs commands, reads errors, and edits again.
- It might pause, wait for human input, then resume.
- The final diff is the result of twenty intermediate decisions.
The chat transcript captures all of this as a linear stream. You can scroll. You can search. You can ask the agent to summarize itself, which is both useful and absurd. But you cannot inspect the decision tree. You cannot fork from step twelve. You cannot see which file edits are pending versus committed.
Chat is stateless by design. Every message is context for the next message. There is no durable object representing “the work in progress.”
What a Canvas Actually Is
A canvas is a persistent, inspectable work surface. It is not a chat window with better formatting. It is a separate object that holds:
- The current plan or checklist.
- File diffs that are staged but not yet applied.
- Tool call history (terminal commands, browser actions, API requests).
- Decision points where the agent branched or backtracked.
- Human annotations, approvals, or rejections.
The canvas lives outside the chat transcript. The agent writes to it. The human reads from it. Both can edit it. The state is serialized so you can close the app, reopen it, and pick up where you left off.
This is not a cosmetic change. It is a state management boundary.
State Serialization and Rollback
The hard part of a canvas is deciding what to persist and how to version it.
A naive implementation stores the entire agent memory: every tool call, every intermediate file state, every LLM response. That balloons storage and makes rollback expensive.
A better approach treats the canvas as a commit graph:
- Each agent action is a node (edit file X, run test Y, read error Z).
- Nodes link to their parent nodes.
- The canvas UI shows the current head, but you can inspect or revert to any ancestor.
This is similar to Git, but at a finer granularity. Instead of commits, you have agent steps. Instead of branches, you have decision forks where the agent tried two approaches.
class CanvasState:
def __init__(self):
self.nodes = [] # List of state snapshots
self.current_head = None
def append_action(self, action_type, payload, parent_id):
node = {
"id": generate_id(),
"parent": parent_id,
"action": action_type, # "edit_file", "run_command", "llm_call"
"payload": payload,
"timestamp": now(),
"approved": None # None, True, or False
}
self.nodes.append(node)
self.current_head = node["id"]
return node["id"]
def rollback_to(self, node_id):
# Replay all actions from root to node_id
path = self._build_path_to(node_id)
self.current_head = node_id
return self._reconstruct_state(path)The canvas does not store full file contents at every step. It stores deltas. When you roll back, it replays the delta chain.
Concurrent Edits and Conflict Resolution
A canvas introduces a new problem: what happens when the agent is writing to the canvas while the human is also editing it?
Chat avoids this because the human and agent take turns. The human sends a message. The agent responds. The human sends another message. There is no shared mutable state.
A canvas is shared mutable state. The agent might be modifying a file diff while the human is annotating it or rejecting part of it.
You need a conflict resolution strategy:
| Strategy | Behavior | Trade-off |
|---|---|---|
| Agent Wins | Human edits are discarded if agent writes to same region | Simple, but frustrating for humans |
| Human Wins | Agent waits or skips regions human has touched | Safe, but slows agent progress |
| Operational Transform | Merge edits like Google Docs | Complex, requires CRDT-like logic |
| Explicit Locking | Agent requests permission before editing | Clear, but adds latency and interrupts |
GitHub likely uses a hybrid: the agent proposes changes, the human approves or rejects them, and approved changes lock that region until the agent moves on.
Observability Without Overwhelming the User
A canvas needs to expose tool calls, file diffs, and decision points. But if you show every LLM token, every API request, and every file read, the UI becomes noise.
The observability layer needs filtering:
- Collapsed by default: Show high-level actions (“Edited 3 files”, “Ran tests”). Let the user expand to see details.
- Severity levels: Errors and warnings are always visible. Info-level logs are hidden unless the user asks.
- Searchable history: The user should be able to search for “when did the agent call the database” or “show me all failed test runs.”
The canvas is not a log viewer. It is a work surface with an audit trail underneath.
Memory Management and Context Windows
A long-running canvas accumulates state. After an hour of agent work, you might have:
- 200 file edits
- 50 terminal commands
- 30 LLM calls
- 10 decision forks
That is too much context to fit in a single LLM prompt. The agent cannot load the entire canvas into memory every time it acts.
You need a context window strategy:
- Recency bias: Always include the last N actions.
- Relevance filtering: Include actions related to the current file or task.
- Summarization: Compress old actions into a summary (“Earlier, the agent refactored the auth module and fixed two tests”).
The canvas stores everything. The agent sees a filtered view.
Deployment Shape
A canvas-based agent needs more infrastructure than a chat-based one:
- State store: A database (Postgres, SQLite, or a KV store) to persist canvas nodes.
- Diff engine: A library to compute and apply file deltas (libgit2, diff-match-patch).
- Conflict resolver: Logic to merge or reject concurrent edits.
- Snapshot scheduler: Periodic checkpoints so rollback does not require replaying 1,000 actions.
If you are building this yourself, start with SQLite for the state store and a simple append-only log. Do not build operational transform until you have real users hitting conflicts.
Likely Failure Modes
Canvases introduce new ways to fail:
- State corruption: If the delta chain breaks, the canvas cannot reconstruct the current state. You need checksums or periodic full snapshots.
- Runaway storage: A canvas that runs for days can accumulate gigabytes of deltas. You need pruning or archival.
- Replay bugs: If rollback does not perfectly reconstruct the old state, the user sees phantom edits or missing changes.
- Race conditions: If the agent and human both edit the same line at the same moment, one edit might be silently dropped.
Test rollback aggressively. Simulate concurrent edits. Measure storage growth over long sessions.
Technical Verdict
Use a canvas when:
- Your agent performs multi-step work that takes more than five minutes.
- Users need to inspect, approve, or reject intermediate steps.
- You need rollback or branching (try approach A, then try approach B).
- The agent modifies files, runs commands, or makes API calls that have side effects.
Avoid a canvas when:
- Tasks are short and synchronous (chat is simpler).
- You do not have the infrastructure to persist and version state.
- Your users are comfortable with chat transcripts and do not ask for better inspection tools.
Canvases are not a replacement for chat. They are a layer on top of it. The chat is still the intent surface. The canvas is the state surface. If your agent is doing real work, you need both.