Why I Started Building Lumen

Lumen did not begin as a complete platform.

When I started the project, I did not have a detailed product plan, nor had I imagined how many capabilities it would eventually contain. Three direct reasons pushed me to begin: I was interested in AI Agents and could see how they might genuinely help in my life; I was dissatisfied with the Agent products I was using at the time; and I needed a place where I could freely implement and test new ideas.

The first reason was a practical need

Before I began developing Lumen, I had already been following Agents for some time. Compared with chat models that only answer questions, an Agent is closer to a system that can keep working toward a result. It can read files, search for information, call tools, make a new judgment from what it finds, and carry a task from its beginning to its end.

For me, this was more than an interesting technical concept.

I regularly need to handle schoolwork, personal projects, research, code, and large numbers of files. Often, what I lack is not a model that tells me what I should do, but a working environment capable of connecting the steps for me. It needs to understand the task, while also knowing when to search, read a file, run code, or continue checking the result.

So I did not start Lumen to prove that I could build an AI application. The more direct reason was that I genuinely needed a tool like it.

The second reason was my dissatisfaction with OpenClaw

Before building Lumen, I used OpenClaw for some time. It gave me a more concrete understanding of Agent products, and confirmed that systems like these could become part of everyday work rather than remain one-off technical demonstrations.

But the longer I used it, the harder I found its interface design to accept.

This was not simply a matter of one unattractive button or one unfinished page. The deeper problem was that the product never felt fully organized. Elements competed with one another, the information hierarchy was unclear, and many features seemed to have been added one after another rather than placed together through a consistent design judgment.

To me, this did not match the resources and technical ability behind the project.

I found it difficult to understand why an Agent product built by experienced developers, with substantial investment behind it, would still face ordinary users through something that felt close to a development panel. When the mobile version later launched, I saw the same concerns about its interface and interaction repeated in many discussions.

The underlying system can certainly be complex, but that complexity should not simply be handed to the user.

An Agent may contain models, tools, memory, permissions, and task state, and it may need to present a large amount of information. That does not mean it has to feel chaotic. The interface is not decoration applied after the technical work is complete. It determines how people understand those capabilities, and whether a complex system can actually be used over time.

I gradually realized that I did not only want a more capable Agent. I also wanted it to appear in a way that was clear, natural, and pleasant enough that I would want to open it every day.

If I could not accept the existing answer, I would build my own.

The earliest version of Lumen was very simple.

At the time, it was still called Local Intelligence Console. It contained only basic model chat, a conversation sidebar, a Context panel, and an input box. It was closer to a personal workspace for running local models, and still far from what would later become an AI platform.

Even then, however, I did not treat the interface as something to address at the end.

The size of the input box, the density of the sidebar, the visual weight of a button, the hierarchy of the settings page, the background of dark mode, and even whether several icons sit on the same line all affect whether software feels comfortable. Each adjustment may seem small, sometimes only a difference of a few pixels, but together they determine whether a project remains a temporary tool or becomes something that can stay on the desktop for a long time.

The third reason was experimentation

I regularly encounter new ideas in videos, articles, and other projects. Sometimes it is a new Agent architecture; sometimes it is a different approach to memory, tool planning, research workflows, or interaction design.

When I see something like this, I often have the same question: would it actually be useful if it were placed inside a real system?

The problem is that this kind of experiment is usually difficult inside mature environments such as Codex or OpenClaw.

Codex is a powerful development tool, but it is not an AI product whose behavior I can freely change. OpenClaw has already formed its own architecture, design judgments, and product boundaries. Adding a new runtime idea to either system often requires much more than implementing the idea itself: first I would need to understand a large existing structure, then work around its constraints and compatibility requirements.

Often, the part I actually want to test makes up only a small fraction of the work. Most of the time goes into adapting to decisions that someone else has already made.

I therefore needed an experimental environment of my own.

Inside Lumen, I can encounter an idea and try to implement it directly. If it proves valuable, it can become part of the system. If it does not work, I can remove it, rebuild it, or try another approach. New models can be connected and tested; different ways of planning tools can be compared; search results can gradually become a fuller evidence system; and an Agent can grow from a single tool call into a task loop that continues to plan, act, and check its work.

None of these capabilities was completely planned when the project began.

Lumen developed more as a sequence of problems that demanded answers.

Model responses lacked reliable sources, so I began building a web-evidence system. File handling was not stable enough, so more complete parsing and retrieval were added. As the number of features grew, manual testing became difficult, which led to a separate Test workspace. A normal request could not carry a long-running task, so I began designing a runtime that could pause, resume, cancel, and retry work.

Every solved problem exposed another one.

Lumen gradually moved from a simple local chat interface into three distinct workspaces: Chat, Test, and Agent. It gained document handling, visual understanding, web search, code execution, research workflows, a task runtime, memory, and safety boundaries.

Looking back at the development process, I can see that Lumen has always served three roles at once.

First, it is a tool I need to use myself, so its capabilities cannot stop at the level of a demonstration. Second, it is my response to existing Agent products, so interface and user experience cannot be treated as secondary. At the same time, it is an experimental platform, which means new ideas need to be placed inside it quickly, tested in real use, and then either kept or removed.

Those three reasons gradually became the direction of the project.

Lumen does not need to imitate existing platforms in order to look mature, nor does it need to accept disorder merely to contain more features. It can absorb good ideas from other projects without inheriting their entire structure. Its underlying capabilities can be complex, while that complexity remains as quiet as possible in the interface.

When I started the project, I did not know what it would eventually become.

I only knew that the available tools did not truly meet my needs, and that many of the ideas I encountered had no suitable place in which they could be implemented.

So I built that place.

It later gained its own conversation system, tools, research architecture, runtime, and desktop application, and gradually developed a relatively stable visual language. None of those changes, however, altered the original reason for the project.

Lumen still comes from one simple judgment:

If a tool can genuinely help my life, but the existing versions do not satisfy me, then instead of waiting for someone else to build it well, I would rather begin building it myself.