The Interface Is Not the Product

Here is something that most people in software have never had to question: the interface is the product.

It sounds obvious. Of course the interface is the product. What else would it be? When you use Photoshop, the product is the toolbars, the layers panel, the menus, the keyboard shortcuts. When you use Salesforce, the product is the forms, the list views, the dashboards, the settings pages. If someone asked you to point at the product, you would point at the screen. The pixels are the thing.

This assumption has been true for so long that we stopped noticing it was an assumption at all. It became like gravity — something so constant you forget it is even there. And like gravity, it shaped everything: how we designed software, how we hired for product teams, how we evaluated what "good" looked like, how entire companies organized themselves around the craft of making interfaces.

I think AI is about to break this assumption, and most of the software industry has not yet reckoned with what that means.

Let me explain what I mean.

Think about the history of how humans have interacted with computers. In the beginning there were no interfaces at all, at least not in the way we think of them now. You wrote your program on punch cards and handed them to an operator. Hours later you got your output. The "interface" was a person standing behind a counter.

Then came the command line. This was a huge leap, because for the first time you could have a conversation with the machine in real time. But it required you to speak the machine's language. You had to know the exact incantation. If you wanted to copy a file, you had to type the right command with the right flags in the right order. The interface was the language itself, and mastering it was the skill.

The graphical user interface changed everything. The Macintosh in 1984 was revolutionary not because it could do things the command line could not — in fact it could do fewer things. It was revolutionary because it lowered the floor. Suddenly you did not need to memorize commands. You could see your options. You could point and click. The interface became a map of the machine's capabilities, laid out visually so that anyone could navigate it.

And this is when the conflation really took hold. Because once the interface became the map, improving the map became synonymous with improving the product. A better layout of buttons meant a better product. A cleaner settings page meant a better product. Fewer clicks to accomplish a task meant a better product. The entire discipline of product design grew up around this equivalence: product quality equals interface quality.

This was not wrong. For decades, it was profoundly right. The reason is simple: the computer could not figure out what you wanted. It had no capacity for intent. It could only respond to explicit instructions, delivered through whatever control surface the designer had constructed. So the quality of that control surface determined everything. A thoughtfully designed form was the difference between a user succeeding and a user giving up. A well-placed button could save someone hours. The interface was not decoration. It was the mechanism by which value was delivered.

Where the Value Moves#

I think about this a lot because we are building DenchClaw, an AI-native CRM, and almost every day we run into the consequences of this assumption breaking down.

Here is a concrete example. In a traditional CRM, if you want to set up a deal pipeline, you go through a setup wizard. You click "Create Pipeline." You name it. You add stages one by one: Discovery, Proposal, Negotiation, Closed Won, Closed Lost. You configure probability percentages for each stage. You set up required fields. You maybe create a custom view. If you are using Salesforce, this might take you an afternoon, and you will almost certainly get something wrong that you will have to fix later.

In DenchClaw, a user can say: "Create a deal pipeline with stages Discovery, Proposal, Negotiation, Closed Won, and Closed Lost. Set win probabilities at 10, 25, 50, 100, and 0 percent."

And the agent does it. All of it. In seconds.

Now, here is the question that most people do not ask but should: where is the product in this interaction? Is it the chat box where the user typed their request? That is certainly part of the interface, but it is not where the value was created. The value was created by the system's ability to understand intent and execute correctly. The chat box is just the opening through which the request entered. You could replace it with a voice interface, or an API call, or a Slack message, and the value would be identical.

The product, in other words, has moved. It is no longer the arrangement of controls on the screen. It is the system underneath — the thing that can hear what you want and do it right.

This is what I mean when I say the interface is not the product.

The Supervision Layer#

Now, I want to be careful here. I am not saying interfaces do not matter. They matter enormously. But they matter for different reasons than they used to, and that difference is subtle enough that a lot of smart people are missing it.

In the old world, the interface mattered because it was the mechanism. In the new world, the interface matters because it is the supervision layer.

Let me unpack that.

When you hire a new employee, you do not hand them a set of buttons to press. You explain what you need, you give them context, and then you check their work. The better the employee, the less you need to check. But you always need some way to review what they did, understand their reasoning, and course-correct when necessary.

This is exactly what is happening with agent-native software. The human's role is shifting from operator to supervisor. And supervision requires a very different kind of interface than operation does.

An operating interface needs to be comprehensive. It needs to expose every possible action, because the human is the one who has to perform each action. A supervision interface needs to be legible. It needs to show what happened, why it happened, what changed, and what you can do about it if something went wrong.

These are fundamentally different design problems. And yet most companies building "AI products" are trying to solve the new problem with the old toolkit. They bolt a chat box onto their existing interface and call it AI-powered. The user types something, the AI responds, and then the user is dumped back into the same old forms and settings pages to actually get anything done.

I think this is roughly equivalent to what happened in the early days of the web. The first websites looked like digitized brochures. Companies took their print materials and put them on a screen. It took years for people to realize that the web was not just a new distribution channel for old formats — it was an entirely new medium that required entirely new ways of thinking about design, interaction, and value delivery.

We are in the "digitized brochure" phase of AI software right now. Most AI features are cosmetic. They are a chat box sitting on top of a product that was fundamentally designed around the assumption that a human would operate every control.

The thing is, actually making the agent the operator requires you to rethink the entire product from the ground up. It is not a feature you can add. It is an architecture you have to build.

This is what took us the longest to understand while building DenchClaw. Early on, we had the same instinct everyone does: take the existing CRM model and add AI on top. Let the agent help with individual tasks. Auto-fill some fields. Suggest some next steps. It felt productive because we were shipping features. But we kept hitting the same wall: the agent could talk, but it could not act. It could generate text, but it could not actually change the system.

The reason was that the system was not designed to be changed by an agent. It was designed to be changed by a human clicking buttons. And those are very different things.

The Substrate Problem#

This is what I now think of as the substrate problem. For an agent to be genuinely useful — not just conversationally pleasant, but actually productive — it needs access to the real substrate of the product. It needs to be able to touch the filesystem. It needs to be able to query and modify the database. It needs to be able to create and configure things. It needs to be able to use the browser. It needs real tools and real permissions, not a conversational veneer over a system that still requires human clicks at every step.

A lot of AI products stop at the chat box, and I think this is usually a sign that the underlying system is not actually programmable. If the agent cannot reach the real machinery, chat becomes a glorified search bar. It might write you a clever paragraph, but it cannot set up your pipeline, update your records, build a report, create an app, or operate on your files.

DenchClaw has a filesystem. It has a DuckDB database. It has apps, skills, browser automation, and a workspace the agent can genuinely operate on. The chat is just the surface. The product is the system that can act. And building that system — making every capability agent-accessible while keeping it safe and inspectable — turned out to be about ten times harder than adding a chat box. But it is also about ten times more valuable, because it is the difference between an agent that talks and an agent that works.

The Autopilot Analogy#

I want to take a detour here, because there is a historical pattern that I think illuminates what is happening.

Think about the transition from manual to automatic control in aviation. In the early days of flight, the pilot controlled everything directly. Every input — throttle, ailerons, rudder, elevator — was a direct mechanical linkage from the pilot's hands and feet to the control surfaces. The pilot was the operator. The interface, quite literally, was the product.

Then came the autopilot. The first autopilots were crude — they could hold a heading and an altitude, and that was about it. Pilots did not trust them much. But over decades, autopilots became more sophisticated. They could handle takeoffs and landings. They could navigate complex routes. They could respond to turbulence.

And here is the interesting thing: as autopilots got better, the cockpit did not get simpler. In some ways it got more complex. But the complexity shifted. The old complexity was about direct control — dials and levers for operating the aircraft. The new complexity was about supervision — displays and alerts for understanding what the autopilot was doing and intervening when necessary.

Modern airline pilots spend most of their time monitoring. They are supervisors of an automated system. Their skill is not in hand-flying (though they can still do that). Their skill is in understanding the system well enough to know when it is operating correctly, when it needs adjustment, and when they need to take over.

I think software is going through a similar transition right now. And just like in aviation, the interface does not disappear. It transforms. The cockpit is still crucial. But it is crucial for different reasons.

This analogy also reveals something important about trust. Pilots did not start trusting autopilots overnight. Trust was built gradually, through transparency, through experience, through systems that explained what they were doing and why. Autopilots that failed silently were terrifying. Autopilots that announced their intentions and showed their reasoning were merely uncomfortable at first and eventually indispensable.

Trust Is the Core UX Problem#

Trust, I have come to believe, is the core UX problem in agent-native software. It is the thing that determines whether a product feels magical or terrifying.

In old software, the main UX challenge was discoverability. Could the user find the right button? Could they figure out the workflow? Could they navigate from point A to point B without getting lost? This is what most of us were trained to optimize for.

In agent-native software, the main UX challenge shifts to trust. Could the user understand what the agent did? Could they predict what it will do next? Could they inspect the work without having to simulate the entire system in their head?

These are different skills. Discoverability is a spatial problem — you are designing a landscape the user can navigate. Trust is a temporal problem — you are designing a relationship that deepens over time.

I think the best AI interfaces will look less like magic tricks and more like logbooks. They will show evidence. They will expose intermediate steps. They will make permissions explicit. They will make reversibility feel normal, not exceptional. They will help the user build a mental model of what the agent can and cannot do, not through documentation, but through experience.

There is a reason we think a lot about undo at DenchClaw. In traditional software, undo is a nice-to-have. In agent-native software, it is a critical trust mechanism. If the agent does something wrong, the user needs to be able to reverse it instantly and painlessly. The easier it is to undo, the more willing the user is to let the agent act. And the more the agent acts, the more value the product delivers. So undo is not just a safety feature. It is a growth lever.

This connects to another thing I have been thinking about: why local-first matters so much for agent-native software.

"Local-first" means the software runs on your machine, operates on your data, and does not require a cloud server to function. DenchClaw runs locally on your Mac. Your data lives on your filesystem. The agent operates on files and databases that you own and control.

At first, this might seem like a purely technical or ideological choice. And there is a technical argument for it — local software is faster, works offline, and avoids the latency and reliability issues of cloud infrastructure. But I think the deeper reason local-first matters is about trust.

Here is the intuition: you are more willing to let an agent act when it is acting on your machine, with your files, under your control. Agency in someone else's cloud feels different from agency on your own computer. It is the difference between letting a contractor work in your office while you are there versus giving them unsupervised access to your office while you are on vacation.

I know this might sound irrational. A well-designed cloud system could be perfectly safe. But trust is not purely rational. It is partly emotional, partly instinctive, and largely shaped by the mental model the user constructs about what is happening. And the mental model of "this agent is working on my machine, with my files, and I can see everything it does" is fundamentally more trustworthy than "this agent is doing something on a server somewhere and showing me the results."

This is not a new insight, by the way. It is the same reason people feel differently about their money in a mattress versus their money in a bank, even though the bank is objectively safer. Proximity creates trust. Control creates trust. Legibility creates trust.

I think the companies that win in agent-native software will be the ones that figure out how to maximize the user's sense of control and understanding, even as the agent takes on more and more autonomous action. That is a hard design problem. It is maybe the hardest design problem in software right now.

Why Most AI Features Are Superficial#

Let me talk about another thing I have noticed, which is how most "AI features" being shipped today are fundamentally superficial.

There is a pattern I see over and over. A company with an existing product decides they need to "add AI." So they integrate an LLM. They create a chat interface. They connect it to their existing API. And they ship it as a major feature.

The result is usually underwhelming. The AI can answer questions about the product. It can maybe summarize some data. It can write a draft email. But it cannot actually do the things the product does. It cannot create records, configure workflows, update pipelines, or build reports. It hits the API, gets a response, and formats it nicely. But the real work still requires the old interface.

I think the reason this happens is that these companies are thinking about AI as a feature rather than as an architectural shift. They are asking "how can we add AI to our product?" when they should be asking "what would our product look like if we designed it from the ground up for an agent to operate?"

These are very different questions. The first one leads to a chat box bolted onto the side of an existing product. The second one leads to a fundamentally different kind of system — one where every capability is programmatically accessible, where the agent has real permissions and real tools, where the system's state is transparent and inspectable, and where the interface is designed for supervision rather than operation.

The analogy I keep coming back to is the difference between putting a motor on a horse carriage and designing an automobile. Both involve engines. Both result in a vehicle that can move without horses. But one is an incremental improvement and the other is a category transformation. Most "AI features" today are motors on horse carriages.

The Product Moves Down a Layer#

This connects to something I have been thinking about regarding what it means for the product to move "down a layer."

Every once in a while, software categories reorganize themselves around a deeper abstraction. It happened when the web became the default runtime. Products that looked very different on the surface — email clients, document editors, project management tools — turned out to be variations on the same web patterns. The product was no longer the desktop application. The product was the web app, built on HTTP and HTML and JavaScript, running in a browser.

It happened again when mobile became dominant. Products rebuilt themselves around the phone's constraints and capabilities — touch interfaces, location awareness, push notifications, cameras. The product moved down from the browser to the native app.

I think AI is causing a similar shift now. The product is moving down from the interface to the system. The value is no longer in the arrangement of controls. It is in the system's ability to understand intent, execute correctly, and explain itself.

This has implications that go beyond design. It changes what you need to build, who you need to hire, and how you evaluate quality.

In the old world, a great product person was someone who could look at an interface and know what was wrong with it. They had taste. They could feel when a button was in the wrong place, when a workflow had too many steps, when a page was too cluttered. This skill is not going away — interfaces still matter, and taste still matters. But it is no longer sufficient.

In the new world, a great product person also needs to understand systems. They need to think about what the agent should be able to do, what it should not be able to do, what information it needs to act correctly, and how to make its actions legible to the user. This is more like designing an organization than designing a screen. You are defining roles, permissions, workflows, and feedback loops. You are creating the conditions under which an autonomous actor can operate effectively.

It seems to me that this shift favors people who think in systems over people who think in pixels. That does not mean visual design becomes irrelevant. It means it becomes one input into a larger design problem rather than the design problem itself.

I want to talk about skills for a moment, because this is one of the things we built into DenchClaw that I think illustrates the "system, not interface" idea most clearly.

In DenchClaw, agent capabilities are defined by SKILL.md files. These are plain markdown files that describe what the agent can do and how it should do it. They live in the filesystem, right alongside the user's data. They are readable, editable, version-controllable, and shareable.

Why does this matter? Because it makes the agent's capabilities legible. You can open a skill file and read exactly what the agent knows how to do. You can modify it. You can add new skills. You can share them with other users. The agent's capability surface is not hidden behind a proprietary API or locked in a settings page. It is a file you can read.

This is a small thing, but I think it reveals a deep principle about agent-native design: everything the agent can do should be inspectable by the human. Not just the agent's outputs, but its inputs, its instructions, its constraints, its capabilities. Transparency should not be an afterthought. It should be structural.

I think about the analogy to open source here. One of the reasons open source won is that transparency turned out to be a competitive advantage, not just an ideological preference. When you can read the code, you trust it more. When you can modify it, you adopt it faster. When you can share it, ecosystems form around it.

I suspect the same thing will happen with agent capabilities. The systems that make their agents' instructions transparent and modifiable will win over the systems that treat them as proprietary black boxes. Not because transparency is morally superior, but because it is functionally superior. It builds trust faster, enables customization, and creates network effects.

This is why DenchClaw is MIT-licensed and open source, by the way. It is not charity. It is strategy. When the product is the system rather than the interface, openness becomes a feature.

There is another thing that changes when the product moves down a layer, which is the relationship between the product and the platform.

In the old world, a product was an application that ran on a platform. Photoshop ran on Windows or Mac. Salesforce ran in a browser. The platform provided the runtime, and the product provided the interface and logic.

In the agent-native world, the product starts to look more like a platform itself. It needs to provide a filesystem, a database, a permissions system, a set of tools, and a workspace for the agent to operate in. It needs to be extensible and programmable. It needs to support plugins and integrations. In other words, it needs to provide the substrate for agent action, not just the surface for human interaction.

This is something we struggled with at DenchClaw. Early on, we were building a CRM — an application with a specific set of features for managing customer relationships. But as we leaned into the agent-native model, the product started evolving into something more like an operating system for agent-driven work. The CRM functionality is still there, but it sits on top of a general-purpose workspace that the agent can operate on.

I do not think this is unique to us. I think any product that takes agent-native design seriously will eventually find itself becoming more platform-like. Because once the agent is the operator, the product needs to provide the agent with a world to operate in, not just a set of screens to display.

Let me take another detour to talk about something that has been on my mind, which is the analogy to self-driving cars.

Self-driving cars are interesting because they represent a mature, high-stakes example of the same fundamental shift: from human operation to human supervision. And they reveal some important truths about how that shift plays out in practice.

The first truth is that the transition is gradual, not sudden. We did not go from fully manual driving to fully autonomous driving overnight. Instead, we got a spectrum: cruise control, then adaptive cruise control, then lane keeping, then highway autopilot, then city driving. Each step gave the machine more autonomy and asked the human to supervise rather than operate.

The second truth is that the hardest part is not the automation itself. It is the handoff between automated and manual control. The most dangerous moment in semi-autonomous driving is when the system reaches the edge of its capabilities and needs the human to take over. If the human has been supervising well, this transition is smooth. If the human has been complacent, it can be catastrophic.

I think we will see the same pattern in agent-native software. The hardest design problem will not be making the agent smarter. It will be designing the handoff between agent action and human intervention. When should the agent stop and ask? How should it signal uncertainty? How should the interface change when the agent needs human judgment? These are the questions that will separate great agent-native products from mediocre ones.

The third truth from self-driving is that trust is earned through thousands of small interactions, not through a single demonstration. You do not trust a self-driving car because someone showed you a demo video. You trust it because you sat in one fifty times and it did the right thing every time. Trust is cumulative. It is built through repeated, verifiable, legible actions.

This is why I think the companies that win in agent-native software will be obsessed with the mundane things: showing the agent's work clearly, making undo easy, being explicit about permissions, logging every action, and making the agent's reasoning inspectable. These are not exciting features. They are not the things that make for good demos. But they are the things that build trust, and trust is the currency of agent-native products.

I keep coming back to this phrase: "legibility of agency." It is the ability of the user to understand what the agent did, why it did it, and what will happen next. In the old world, legibility was about making the interface navigable. In the new world, legibility is about making agency transparent.

There is a startup lesson here too. YC has this principle about making something people want. The way you figure out what people want is by talking to users and iterating fast. But with agent-native products, there is an extra dimension. You are not just making something people want. You are making something people trust. And trust is harder to measure than desire. A user might want a feature but not trust it. They might be impressed by a demo but unwilling to use it with real data. The gap between "this is cool" and "I will let this touch my real pipeline" is enormous, and it is primarily a trust gap.

We learned this the hard way at DenchClaw. Early users loved the demos. They were impressed by what the agent could do. But when it came time to use it with their actual data, with their actual customers, they hesitated. Not because the agent was not capable, but because they did not yet trust it enough. Building that trust — through transparency, through undo, through local-first architecture, through legible action logs — turned out to be the real product work. The flashy AI capability was the easy part.

What This Actually Means#

I want to address an objection I sometimes hear, which is that this is all too abstract. "Okay," people say, "the interface is not the product anymore. So what? What does that actually mean for how I build software?"

It means several things, concretely.

First, it means your system needs to be deeply programmable. Every capability that exists in your UI also needs to exist as an action the agent can take. If a user can create a record by clicking a button, the agent needs to be able to create a record by calling a function. If a user can configure a workflow through a settings page, the agent needs to be able to configure a workflow through a tool call. Your entire product surface needs to be agent-accessible, not just the parts you thought to expose.

Second, it means your interface needs to be redesigned for supervision rather than operation. Instead of forms and wizards that guide the user through a process step by step, you need activity logs that show what happened, diff views that show what changed, permission controls that define what the agent can do, and undo mechanisms that make every action reversible. The interface shifts from a control panel to a dashboard.

Third, it means you need to think about the agent's workspace as carefully as you think about the user's interface. What filesystem does the agent have access to? What database can it query? What tools can it use? What are its permissions? What constraints does it operate under? This is product design, but it is a kind of product design that most product people have never done before.

Fourth, it means trust becomes a first-class design concern, not a nice-to-have. Every design decision should be evaluated through the lens of: does this increase or decrease the user's trust in the agent? Showing the agent's work increases trust. Hiding it decreases trust. Making actions reversible increases trust. Making them irreversible decreases trust. Running locally increases trust. Running on a remote server decreases trust.

Fifth, it means the skills of your team need to evolve. You still need designers who can make beautiful interfaces. But you also need people who can think about systems, permissions, workflows, and feedback loops. You need people who understand both the AI capabilities and the human factors. Product design in the agent-native world is closer to organization design than it is to graphic design.

I sometimes think about what would have happened if we had tried to build DenchClaw the traditional way — as a cloud CRM with AI features bolted on. We probably could have shipped faster. We probably could have raised money more easily, because the pitch would have been simpler: "Salesforce, but with AI." But I think we would have ended up with a product that was fundamentally limited. The AI would have been a feature, not the architecture. The interface would have been the product, not the supervision layer. And we would have hit the same ceiling that every AI-wrapped legacy product eventually hits: the moment where the user realizes the AI cannot actually do anything, it can only talk about doing things.

Building the substrate first — the filesystem, the database, the tools, the permissions, the workspace — was slower and harder. But it means the agent can actually act. It can create pipelines, update records, build reports, automate workflows, use the browser, and operate on real data. The AI is not a feature. It is the operator. And the interface exists to help the human supervise, inspect, and steer that operator.

I want to close with a thought about where I think this is all heading.

I believe we are at the beginning of a transition that will take a decade to fully play out. Right now, most software is still firmly in the "interface is the product" paradigm. AI is being added as a feature, not adopted as an architecture. Most users still operate their software manually, with occasional help from an AI assistant.

But the direction is clear. The most capable products will be the ones where the agent can do real work — not just answer questions or generate text, but actually operate the system. And the best interfaces will be the ones that make that agency legible, trustworthy, and controllable.

This does not mean interfaces become less important. It means they become important for different reasons. The cockpit of a modern airliner is an incredibly sophisticated interface. But it is sophisticated in the service of supervision, not operation. The pilot is not manually controlling every surface. The pilot is monitoring an automated system and intervening when necessary. The interface exists to make that supervision possible.

I think software interfaces are heading in the same direction. The product will be the system underneath — the agent, the tools, the workspace, the substrate. The interface will be the supervision layer on top. Both are essential. But the value lives in the system, not in the pixels.

The interface is not the product. The system is the product. The interface is how you trust it.