API is the UI

The fastest-growing users of our products are agents. And agents don’t need interfaces.

Agents do not need buttons, visual hierarchy, hover states, or spinners. They need APIs, structured data, and predictable endpoints (and to know about them).

What matters underneath is the primitive: block schemas, data models, structured content. The formats they produce (markdown, HTML, JSON) are addressable, diffable, and writable by both humans and machines. Most interface chrome is just a convenience layer on top.

You can already see this shift in code editing.

A year ago, writing software meant living inside a code editor, manually creating and editing files. Today, tools like Codex, Claude Code, and Telex have moved much of that primary workflow into a chat interface.

The code editor still exists, but its role has changed: you’re often reviewing, fine-tuning, and steering while the editor becomes secondary.

The same shift is happening in website building: an agent does not need a block inserter or drag-and-drop chrome. It needs a clear schema for what a page can be and a stable way to write to it (cue the block model for WordPress).

The visual editor becomes the place where a human reviews what the agent built and fine-tunes from there. Which means we’re now designing for two audiences.

The primary audience is increasingly the agent: give it clean APIs, predictable structures, and fast execution paths.

The secondary audience is the human: they need controls to edit, review, refine, and redirect, but most of all they need confidence. Did the agent do something that supports their goal? Did it meet their standards? How do we communicate what the agent did and why? How do we help humans and agents stay aligned? And when they’re not aligned, how do we make it easy to redirect?

We’ve always treated the human interface as the product, the shape of buttons, the depth of shadows, the flow from connecting accounts to purchasing to completing the job. The API was often an afterthought for integrations or technical requirements.

Human interfaces are not going away, but they are becoming less central. I’ve spent my career building interfaces, but now the most important work I do is what happens beneath them.

API is the new UI.

Response

  1. Dave Smith Avatar
    Dave Smith

    Nice post, Rich. You’ve articulated something I’ve been turning over in my head for a while.

    The way I see it, we’re moving towards two distinct interfaces for every product: the API, and the human UI. They’ve always both existed, but historically the human UI was the primary interface – the API was a bonus for developers. That’s flipping.

    One thing I keep coming back to: people probably won’t use agent UIs provided by the services they’re using. The more likely future is that people build and sculpt their own personal agents – carefully tuned to their preferences and workflows – and those agents interact with tools and APIs exposed by third-party services.

    Nobody’s navigating to your website to use your chatbot. They’re bringing their own agent and asking it to use your service.

    That makes opening up clean, well-structured APIs even more critical.

    For those of us working on WordPress and Gutenberg, this feels like validation of a lot of the foundational work. Block schemas, the REST API, structured content – these aren’t just developer niceties any more. They’re how agents will build and manage sites. Coupled with Abilities and all the new AI work going in to Core I’m excited to see where this leads.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may also enjoy…