February 23, 2026

a new canvas for the age of agents

Agents are shipping faster than we can think so we need a space to zoom out more than ever. The canvas will never die—it just needed to connect from canvas to code and back, and it should just work.

Paper Desktop is a thing now. I didn’t realize how much it mattered until I saw that you can connect agents to it and totally change the way you work. As one of those “designers who ship” I’ve been thinking a lot about where we actually focus when agents are doing a big chunk of the job—at least in some cases.

The buzz is that execution is becoming purely conversational: you describe a thing, an agent spins up a container, writes the code, and hands you an app. For some people, that feels like the end of the old way. No more drawing rectangles. No more mocks. Just prompt → production.

I’ve been watching that narrative a little too closely, and… come on. Agents can’t design. Sometimes it feels like we either forgot what “design” actually means, or we’ve been stuck in a marketing room for too long.

I design on a canvas because I want to find out directions before I commit. I need to hold five different approaches in my head, see them side-by-side, and collapse them into a decision. You can’t do that in a command line. You can’t iterate in a PR.

Spatial thinking beats linear thinking when it comes to design in the broader sense. Chat is linear. It keeps pushing you forward, one reply at a time. It feels productive—like a slot machine feels productive—because there’s always something happening. Space does what a chat log can’t: it keeps multiple futures visible at once.

Hope 2026 will be the year we realize that the canvas is more relevant than ever. Not just as a drawing tool, but as a thinking tool—and importantly, as a connected interface for AI workflows that sync with reality (your code and your context).

The “slot machine” trap

We are learning a new reflex: Prompt, wait, output, repeat.

It’s fast. It’s magical. You can have an army of agents now. But where’s the elephant in the room? Drift.

When execution becomes cheap, we tend to skip the “spatial” phase of thinking. We confuse “generating code” with “solving the problem.” We see teams spin up incredible prototypes in minutes, only to realize days later they built the wrong thing because they never zoomed out. They were trapped in the linear flow of the chat window.

The bottleneck has moved. The hard part is no longer writing the code; the hard part is maintaining context and coherence across a system. Some people might say that “taste is a new core skill” but it’s really more about caring for what you’re building and why.

And for that, we need space. We need a surface that allows us to see the “road not taken” right next to the one we’re building. We need to expand before we narrow.

Why the “old canvas” failed production

So, if the canvas is so important for spatial thinking, why did it lose the war for production?

The answer is abstraction. The canvas earned the right to explore, but it often didn’t earn the right to ship.

For the last decade, our design tools have been beautiful lies. Designers are leaving static mocks behind for a reason. If you’ve ever spent hours polishing “a picture” of a product that doesn’t exist yet—only to hand it off and get something slightly different back—then of course you want to design closer to reality. So, eventually, the code won. The canvas died the moment the first commit was pushed.

The old canvas is tied to its abstract layers, and even with a better screenshot pipeline, it’s still diverging from the substrate of reality.

Is there an alternative future? Will the fun of moving rectangles disappear? We don’t think so. We believe we need to get a broader perspective and think more on paper. Pun intended.

Closing the gap with a connected canvas

We need a new standard. A more connected environment where you can go from design to code and back whenever you want without much of the drama.

If the canvas is built on the same standards as the product—html, css, dom—then you’re not drawing a metaphor of a UI. You’re working in the medium.

We need tools that connect with the real thing. We want to bring the spatial power of the canvas back into the production loop so we need to solve abstractions and stop losing context in translation.

The canvas needs to be made of the same material as the product. Imagine a surface where “designing” isn’t drawing a picture of a ⁠div, but actually manipulating a ⁠div. A place where the HTML and CSS are the medium, and the output.

This is the part that changes the gravity: it goes both ways. You can pull reality onto the canvas when you need to go wide, and you can push decisions back into code when you need to go narrow—without turning either side into a dead end.

This is the world we deserved even before AI. When the gap disappears in both directions, the Canvas becomes the map: where humans provide the spatial reasoning, the taste, and the direction.

We don’t want to replace code with visual tools. It’s about acknowledging that code is a terrible interface for spatial problems, and chat is a terrible interface for systemic decisions.

Leverage, not magic, no slop

Our bet is that we are heading toward a bi-directional workflow. Even without AI, this is a world where you can pull a section of your live app onto a canvas, iterate on it spatially, probably with some help of agents, and push it back as code. Not a picture of the change, but the change itself.

This unlocks the true era of agentic work. The canvas is where humans do the part agents are bad at: holding ambiguity, comparing paths, deciding what matters. The agent becomes an extension of your hands: handling the boilerplate, the refactoring, the tedious responsive adjustments.

When your canvas speaks the same language as your code, an MCP can finally connect the dots without drift. Agents can pull live data, connect to your APIs, and read your local environment. It’s no longer a blind handoff; it’s a shared context where design, code, and data live together.

Back to Paper

We are building Paper to test this hypothesis. We decided to build a canvas entirely on web standards (DOM) because we believe that to fix the workflow, you have to respect the medium.

The era of “magical” code generation is here. But magic without a map is just chaos. The canvas gives us the map back.

It’s time to stop treating design and implementation as two different jobs, and start treating them as two different views of the same reality. When execution becomes cheap, taste becomes the bottleneck. Not taste in pixels, but taste in consequences.

Agents help you build faster. The canvas helps you remember why you are building it.