Paper Bets on HTML and CSS as the Rendering Engine for Agent-Native Design

Paper's core architectural bet is that a design tool rendered in HTML and CSS is dramatically easier for AI agents to operate than one built on a custom rendering engine. In this short clip, a member of the Paper team explains the reasoning: agents already understand HTML and CSS from training, so pointing them at a canvas that speaks those languages natively cuts token spend, speeds up generation, and improves accuracy. The talking-head segments are intercut with a screen recording of an agent building a music app UI in Paper through MCP tool calls.

Why the rendering engine matters for agents

The argument is simple. Most design tools (Figma being the obvious example) use proprietary rendering engines with their own internal formats. An agent working against one of those formats has to learn an unfamiliar representation, which shows up as three concrete costs the speaker names directly: higher token spend, slower times, and lower accuracy. Paper flips this by making HTML and CSS the actual rendering engine, not an export target. The agent reads and writes the same representation the canvas renders, so there is no translation layer to get wrong.

The demo: an agent builds a playlist UI over MCP

The screen recording shows a terminal session in a project called overflow-app driving the Paper canvas through MCP. The visible tool calls map cleanly to design operations: get_selection returns the selected page, read_file pulls in components/playlist-page.tsx, write_html adds rows to a playlist one at a time, set_text_content renames the playlist to "Vinyl Sundays", and create_artboard spins up new frames. The agent even calls the real Spotify API (fetch("https://api.spotify.com/v1/playlists/...") returning 200 OK, 10 tracks) to populate the playlist with actual data, then reports "Playlist screen written, populated from Spotify." The result renders live in the canvas as a working-looking music app called Overflow, complete with track list, cover art, and player bar.

From desktop to mobile with one prompt

The demo ends with the prompt "now generate the mobile screens." The agent responds by generating three mobile screens at 390x844, calling create_artboard for "Mobile / Home", "Mobile / Playlist", and "Mobile / Library", then filling each with adapted layouts: a home screen with recently played carousels, a playlist detail view, and a tabbed library. This is the payoff of the architecture pitch: because every artboard is HTML and CSS, responsive variants are a generation task rather than a manual redraw. The speaker closes with context on the company: a team of about 12 designers and engineers who "started this out of love for design" and are aiming to build the best design tool for the agent era.

Key Takeaways

• Paper is an agent-native design tool that uses HTML and CSS as its actual rendering engine, not an export format.
• Custom rendering engines in traditional design tools cost agents higher token spend, slower generation, and lower accuracy.
• Agents drive the Paper canvas through MCP tool calls like write_html, set_text_content, create_artboard, get_selection, and read_file.
• The demo agent pulled live data from the Spotify API to populate a playlist UI, then generated three mobile screens (390x844) from a single prompt.
• Paper is built by a team of roughly 12 designers and engineers.

Resources

• Paper -- the agent-native design tool shown in the video, rendered in HTML and CSS with bidirectional MCP support.
• Model Context Protocol -- the open standard the demo uses to let agents read and write the Paper canvas.