Challenging the Chatbot

AI apps need new interaction patterns

The chatbot is genuinely an incredible interface.

I personally love using chatbots. I use Cursor for coding every day. I use ChatGPT for querying things, exploring ideas, and getting unstuck. Even a lot of the products we build for ourselves are conversational in nature.

What makes them so compelling is how well they capture intent. You can show up with a vague thought, a half-formed question, or a messy goal, and the system can still meet you there. That is a real shift in how people interact with software.

I heard Naval describe Large Language Models (LLMs) as something like natural language computing. That phrase has stuck with me because it captures what makes chatbots feel so powerful. They let you compute with open-ended language. Instead of learning a command syntax, searching through menus, or translating your intent into the shape of an application, you can just say what you mean.

From a product design perspective, though, especially for the operational products people use every day, this is where things get more complicated.

Tools like CRMs, email clients, dashboards, workflow builders, and collaborative systems have a lot of value in their fixed, deterministic interfaces. They expose state. They make repeated actions fast. They let teams look at the same object and understand what is happening. They give users buttons, filters, tables, timelines, approvals, and views that are optimized for the work.

Chatbots have excelled in single-player use cases, especially when the user is exploring, writing, searching, or asking for help. But they struggle more in collaborative, high-frequency, operational workflows.

You would not want to use a conversational chatbot at a checkout kiosk. In that context, the job is not to explore ambiguous intent. The job is to finish a repeated workflow with as few mistakes and as little friction as possible. A deterministic interface, optimized around the right sequence of actions, is simply better for that kind of work.

That is the tension. Chat is an amazing way to express intent, but it is not always the best way to represent state, coordinate action, or run a product workflow.

What Exactly Is Software?

To understand where chatbots fit, it is worth asking a more basic question: what exactly is software?

One useful way to look at software is through a systems design lens: inputs, process, and output.

The product gives users a way to provide information or intent. The system stores and transforms that information through some process. Then it produces an output the user can consume, trust, or act on.

For decades, a lot of the software we use every day has followed a fairly deterministic pattern.

We build interfaces that gather information from users, store that information as core entities or data models, apply some business logic on top, and then produce an output the user can rely on.

Take payroll software. The product gives you an input surface for defining employees, compensation, bank details, tax information, and pay schedules. Underneath that interface, the software applies the calculations and business rules required to run payroll. The output is not a message in a transcript. It is a durable artifact: payroll that has been processed, recorded, and can be returned to later.

That pattern shows up everywhere. The interface collects structured information. The system applies logic. The product produces state or an artifact that users can inspect, trust, and act on again.

Before software, people managed a lot of this with pen and paper.

The input surface was a piece of paper. The output surface was a piece of paper. The logic was either written down somewhere else or carried around in the head of the person who knew how the process worked.

Software changed the medium, but not the underlying shape of the work. To represent the input surface, we settled on visual user interfaces. In practice, this often became form hell: fields, dropdowns, tables, checkboxes, required inputs, validation states, and long flows designed to collect the data the system needed.

The business logic moved into code. We created programming languages and frameworks to capture the rules that used to live in manuals, spreadsheets, paper trails, or someone's memory.

The output also became a software surface. Instead of a printed payroll sheet, an invoice, or a file in a cabinet, the product produced dashboards, reports, records, notifications, documents, and workflow states.

No-code platforms are useful to understand in this context. They are a thin layer on top of the deterministic languages and systems we use to define interfaces, logic, and outputs. Workflow builders made it possible for people who could not write code to still assemble the same pattern: collect data, apply rules, produce an output.

In other words, a lot of software history has been abstractions on top of abstractions on top of abstractions, all trying to make it easier for people to input data, for applications to process that data, and for other people to consume the result in a predictable way.

What Chatbots Unlocked

This is where chatbots changed the input surface of software.

In a traditional application, the user has to know where to go before they can do the thing they want to do. They navigate to the right page, find the right workflow, open the right form, and then translate their intent into the fields the product exposes.

Chat changes that sequence.

Instead of navigating through the product first, the user can describe what they want. The system can interpret that intent and route them toward the relevant workflow. The user no longer needs to know exactly where the product hid the action. They can start with the goal.

It also changes how information enters the workflow. The user does not always need to fill out a form field by field. They can narrate what they mean, and the system can extract the relevant inputs.

That is the paradigm shift. The input surface is no longer only a deterministic form. It can be open-ended language.

The user can say what they want to do, and the system can figure out where that belongs. The user can describe the information they have, and the system can turn that into structured data.

This gets even more powerful when the chatbot has access to more than the immediate message. If it can search the web, look across an internal database, retrieve documents, remember past context, or understand the user's history, the input process becomes personalized. The user is not filling out a blank form from scratch. They are collaborating with a system that can infer context, retrieve missing details, and ask for clarification only when it needs to.

This is why chat feels so magical. It collapses navigation and input into one natural language surface.

It also changes the shape of the workflow itself.

In the past, companies had to define rigid deterministic pipelines for getting things done. They could not capture any possible user intent, so they settled on a fixed number of input fields required to execute a fixed workflow. Once the product had access to that data, it could run the application logic and produce the output.

That is still useful. A lot of software should be deterministic. But LLMs are unusually good at joining the dots between things. They can understand how pieces of context relate to each other, decide which capabilities are relevant, and assemble a path through a larger surface area.

This is the argument we made in Primitives over Pipelines: instead of forcing agents through rigid backend workflows, give them modular capabilities they can compose.

Chatbots make that idea visible at the product level. Instead of building only narrow vertical tools with one prescribed workflow, products can expose primitives to an LLM and let the model assemble the right path for the user's intent.

Take something like Notion. In the past, it was primarily a document editor and workspace. But once you expose its primitives to an LLM, it can start to feel like more than a document editor. It can become an application builder, an internal operating tool, or a flexible layer for assembling workflows across the information already inside the workspace.

The product does not need to anticipate every possible form factor up front. If the model can accept open-ended input and the system exposes the right primitives, the model can assemble workflows and application logic at runtime.

So the chatbot paradigm shifts two parts of the old software loop. It changes the input surface, because users can describe intent in language. And it changes the application logic surface, because the system can compose primitives instead of only executing predetermined pipelines.

It also changes the output surface.

In traditional software, the output was usually a deterministic artifact or state that everyone consumed in roughly the same way. A report, a record, a dashboard, an invoice, a payroll run, a task list. The product decided the shape of the artifact, and the user consumed it.

LLMs make that output more malleable. The system can assemble an artifact that depends on a specific person's use case, context, role, or intent. One user might need a summary. Another might need a table. Another might need a workflow, a draft, a dashboard, a checklist, or a diff.

That means the full lifecycle of software is changing. How we capture input intent, how we process application logic, and how we represent the output to the user can all become more adaptive.

The chatbot is the most obvious expression of that shift, but the deeper change is not the chat box itself. The deeper change is that every part of the software loop has become more flexible.

Chatbots are taking off because they are an incredible form factor for open-ended work. They are especially strong for coding, writing, research, and general-purpose assistants where the user is exploring intent as they go.

But much of the software we use every day is not primarily exploratory. It is operational. Payroll, checkout, inventory, scheduling, CRM, analytics, support queues, and approval workflows all depend on visible state, repeated actions, and shared artifacts. In those contexts, the best interface is often not a conversation. Sometimes it is a table, a scanner, a dashboard, a diff, a form, a calendar, or a button. Sometimes, like the Uniqlo checkout, the best interface is almost no interface at all.

So if chat is not the whole interface, what else should we design?

Interaction Patterns Beyond Chat

There are several patterns intelligent applications can use that are not simply a chatbot.