Why You Can Still Build Agent Products Today

When you already have Codex and Claude Code, why should — or how can — you still build agent products? In principle, anything your agent product can do, Codex and Claude Code can do too. In particular, when your agent product is itself written by Codex/Claude Code, it's easy to reach an abstract inference: even if the products you build somehow add some value, since they were written by Codex/Claude Code, couldn't those tools simply generate them dynamically, entirely from user intent? Even if there are still some technical limits today, this clearly holds in principle. So why can — or should — you still build your own agent products? And if you do build one, what basic form should it take?

I think this is a very deep question.

Here is how I think about it. The essence of a product is not merely to implement some combination of functions in the objective world (whether the digital world or the world of atoms). It is first of all an interface through which the human being — human consciousness — reaches the "objective world." This means it is first a concept, a tool our cognition uses to organize our life and our activity. Take "data analysis." Data analysis is not a category of the objective world; it is a category of cognitive organization, because the objective world has no way to define what data analysis is. Data analysis is basically a combination of arithmetic, logic, statistics, and machine learning under the organization of our intent. The packaging of this kind of conceptual activity is itself a conceptual product. In what sense is it a "product"? Because people say: do some "data analysis," use "data analysis" to support a decision — our thinking is invoking it as a tool.

Once we have such a conceptual product, we materialize it in the real world. The simplest data-analysis product is the table. This product was at first merely a conceptual form: arranging information into cells so that the same column and the same row share some semantics — that's it. This is the basic form of UI (originally it was on paper). Then, around this basic form, people attach all sorts of functions, automating and simplifying the basic operations around the table, and so created the greatest software in history: Excel, the relational database, and so on. What is my point? Looking back from today, it is easy to see these products as functions sitting on top of the table. But at the most basic level, in the deepest sense — first, the table itself — we have these products not, in the first place, because we need to complete these tasks, but because human beings organize their cognition of the world in the form of the table. Precisely because our thinking invokes the form of the table to do things, the conceptual forms and physical functions around the table emerged.

Mathematics, statistics, and logic — these more general tools — in some sense contain data analysis, and yet we still need data analysis. We need a conceptual tool to organize a specific set of tasks in a specific context; without this tool, we cannot even roughly understand or communicate what it is we want to do. This is why human organizations have data departments, and why software products include a "data analysis" product — though the granularity of software products is even finer than data analysis, a limitation of what the physical world could do in the past. Today our physical world has evolved into the agent world, which lets a physical world independent of the human being complete, to a large degree and end-to-end, certain intelligent tasks. So we arrive at these questions:

Are there still agent products? If we understand an agent as a tool for achieving human intent, then to what degree will it be "end-to-end"? Is more "end-to-end" always better? Does it still have some division into domains? Or is it one agent for everything? Is the chatbot its basic form?

I think these are all very hard questions. Answering them requires knowledge of two kinds. One is knowledge of the forms of human conception — less knowledge, really, than understanding. Everything I argued above was meant to show that a product is first an interface between the physical world and the conceptual world, a design for how the human being cognizes and manipulates the world; therefore, understanding the human being is the first side of understanding these questions. The second side is the physical constraints of the world. When we ask to what degree it can be "end-to-end," that obviously depends on AI's capabilities; the basic form of an agent product also depends on AI's capabilities. For example, today's data-analysis agent products (such as Data Copilot) do not take the explicit table as their basic product form, because AI's dynamic UI-generation ability is good enough that it can produce a table UI within the dialogue at any moment. All of this changes the design of products and the boundaries of products.

Based on my understanding, here are my answers to these questions.

First, there will be agent products today, and tomorrow as well. Whether there will be in the more distant future — I don't know.

Why will there be?

First, giving an agent a name and a domain boundary is, first of all, a cognitive interface. Our Data Copilot is exactly this: it gives a concept, a place, where users go to do the "data work" they have already conceived in their heads. In this sense it is a reuse of brand and of concept. Just as, at a convenience store, we say "buy a Coke," not "buy sweet water" — we no longer even form the thought of buying sweet water, because "Coke" is an effective, successful cognitive compression. Data Copilot is the same: your day begins with Data Copilot, and you know exactly what you are going to do; the name has already given your thinking a boundary, a shape. Starting from another, general agent, you have to give your own thinking a boundary and a shape — and that is not how most human beings are designed to work.

Second, a general agent has all capabilities, which also means it has all perspectives; it works in a much larger task space. This means that when we need it to do "data analysis" or some other specific task, we have to supply it with extra context. A domain agent, by contrast, is a pre-defined task space (a relatively limited set of tasks), a pre-defined angle, a pre-defined UI form — we call these the domain agent's UI. Without this UI, the user would have to imagine and invent these UIs ad-hoc, which does not work and is inefficient. I could give many examples here; nearly every question a user asks on Data Copilot is one. On a general agent it would surely get a different answer, and that answer, with model capability held equal, almost always drifts further from the user's intent. At the most basic level, the user almost always has to specify how the general agent should display the data, how to visualize it, how to organize the data-related information — all of which can of course be done, but it is a great deal of work, and by the time the user has done it, they have in fact built a data-analysis agent on-the-fly, an agent that then exhibits unwanted UI on other tasks.

Therefore, as long as the concept of data analysis itself still exists in people's heads and in human organizations, the data agent as a product holds. It need not be a standalone product, but it is necessarily an irreducible part of the product structure — because human thought has not yet reduced this concept away.

These UIs look trivial, but they are exactly the gap between a user using and not using a given agent product today. For example, Data Copilot built very good Asana and Slack integrations — you can bring data-analysis capability into the place where you already work, the nearest place; sounds like it makes sense, right? In fact users use it from there very little, myself included: I would rather open Data Copilot in the browser and paste the Asana link in than use Data Copilot directly inside Asana. The first reason is the burden on the cognitive path — our brains do not actually prefer the shortest operational path; we prefer the shortest, most certain cognitive path. There is also a UI factor: some people avoid using it inside Slack/Asana because those tools render tables and charts poorly. Small UI differences really matter.

Third, as I have pointed out before, domain intelligence = general intelligence + domain knowledge + capability set. The generation and organization of domain knowledge, and the construction and orchestration of the capability set, are domain-specific — this is the third reason an agent product needs to be built.

For reference, my essays:
https://blog.dreambubble.ai/posts/from-agent-to-domain-intelligence-a-self-evolving-knowledge-engine
https://blog.dreambubble.ai/posts/environment-as-a-service-agent-as-the-interface

Put simply: domain intelligence is the set of tasks general intelligence cannot do well out of the box, and the gap between general intelligence and domain intelligence is precisely domain knowledge and the capability set. In the SEKE essay I argue that a self-evolving knowledge engine (SEKE) is domain intelligence's answer to the knowledge problem. That, of course, is my own view; but I think everyone will agree with my formula — domain intelligence = general intelligence + domain knowledge + capability set — and will also agree that domain knowledge will be organized in the way domain knowledge is organized, so that domain knowledge, as a kind of infrastructure, will exist as long as the domain exists. And of course, to do domain-related work an agent also needs a set of capabilities — for a data agent, say, the ability to access databases, the ability to access data warehouses, the ability to access data pipelines, and so on. Capabilities and knowledge packaged together are the infrastructure of domain intelligence; whether or not we expose it through a UI, it has to exist and be invoked — and this, in a certain sense, is also called a product.

So I believe there will still be agent products today and tomorrow — and by agent products I mean domain agent products.

On the form of UI. The far future I don't know; for today and tomorrow, I think the chatbot is the most basic form, because the chatbot is the most natural form human beings have had for organizing communication over thousands of years — it satisfies continuity and the isolation of context, and it fits very naturally the basic fact that human cognition has a context window. Another line of thinking is to build the UI of an agent matrix on the model of human collaboration, so that it might end up looking like some task-management platform or workflow platform; but I would not bet on this direction. I do not think such orchestration has long-term product value, because a product is ultimately about the human being, not about the physical world itself — just as HTTP and TCP are not products, agent orchestration is not itself a product, even though it may be important infrastructure.

Finally, the degree to which an agent is end-to-end is determined by the degree to which humans can verify it. My conjecture is that in the short term it may be less end-to-end than we imagine. On a data-analysis task, for instance, we probably cannot count on "analyze this question for me and decide the next step," because such an end-to-end task is not only a problem of intelligence but also a problem of organizational intent: the same question, the same data, in a different context (a different organizational background), may carry completely different expected results, and getting organizational intent to flow into the AI is hard. This is what makes the agent of this era more an executor than a leader.

Will this change? I think a new generation of organizations and products may change it — because a new generation of products and organizations will, from the very beginning, be designed for end-to-end optimization around how to give the AI all of the context. This kind of paradigm revolution is exactly the revolution that destroys old domains and creates new ones. And in the new domains we will see new product forms. We of course do not know today what they are, but they will surely be very different — so different that only what we consider wrong today could possibly be right in the future.