The real value of a one-person company is not that one person ships more things alone. It is that AI and agents make it possible to redesign how one person turns ideas into real work, decisions, workflows, and learning loops.

One-person company with AI agents

The idea of the OPC — the one-person company — is being discussed more often now.

There are two very different reactions to it.

One side is optimistic: AI and agents may give individual founders the kind of execution power that previously required a small team.

The other side is skeptical: maybe the one-person company is just a well-packaged concept that sounds exciting, but falls apart when it has to face product work, operations, growth, delivery, and actual business results.

I do not want to write this as a conceptual explainer, and I do not want to simply pick a side.

I want to talk about my own choice: why I am choosing this way of building today, why I have always wanted to turn the ideas in my head into real things, what AI and agents have changed, and what I hope to learn from this way of running a one-person company.

I have always had things I wanted to build

I have wanted to build my own company for a long time.

Ideas keep appearing in my head: directions I want to explore, problems I want to solve, product shapes I want to try, tools I think should exist, or simply moments where I feel that “this should be done better.”

Most of them are not complete business plans at first. They are just scenes, fragments, product instincts, or unresolved problems.

But they stay in my head. The more I think about them, the more I want to build them and see whether they can work.

In the past, I kept trying different kinds of projects: CcView for low-code visual dashboards, CcBailu as a component library, CcServer as a backend system, and CcClip as a video editing tool.

Behind these projects was the same impulse: I would see a direction, feel that it was worth trying, and want to make it real.

But once I actually started building, I quickly ran into the same problem: the hardest part of solo building was not the lack of ideas. It was that every part of the execution chain eventually came back to me.

Product, engineering, testing, deployment, bugs, operations, data, growth — everything had to be handled. Any small problem could pull me back into repeated low-level work.

At that time, I was basically using personal effort to chase the speed of a small team. The only way to move faster was to work more. The rhythm could easily become inverted: work until sleep, wake up, keep working, and sometimes not even know whether I had just fallen asleep or had slept for a long time.

Looking back, that was not very efficient.

More importantly, it slowly drained the passion I had for the thing itself.

A lot of time went into small, basic, detailed problems: tracing a bug, locating an exception, fixing an environment issue, polishing a tiny interaction, or dealing with a deployment detail. The time actually spent pushing the larger idea or the main product direction forward was often very limited.

You could even say that 80% of the time was spent on foundational work. The time used for learning, growth, and understanding something new was much smaller. But in the actual process, those small details could trap you for a long time and pull you back into inefficient tasks again and again.

That is why I eventually felt that in a pure tool-building startup, individual technical skill does not create an absolute advantage over a mature small team. No matter how strong one person is, it is difficult to use stamina and familiarity to compete with a team that has clear division of labor.

Why today feels different

If I look at the same problem today, my judgment is different.

If the current level of AI tools and agent capabilities had existed back then, I probably could have built much more in the same amount of time. Not just building the same product faster, but trying more directions, running more iterations, and testing more product shapes.

That is why the one-person company still attracts me today.

Compared with the old process of turning ideas into products — a process I often disliked because it was full of draining execution details — AI and agents finally give me a method I genuinely like: break ideas down, move them forward, verify them, and deliver them while spending more energy on the work I actually care about.

In the past few years, while working in an AI company, I had already used AI to solve many small tasks. But those uses were scattered: use AI to assist one task, organize one piece of content, or generate one first-pass solution.

Now agents make it possible to connect those scattered capabilities into a more complete workflow.

That matters to me.

It does not mean AI can already run a company for you. It also does not mean humans stop mattering. The opposite is true: human judgment becomes more important — choosing direction, deciding what is worth doing, reviewing results, knowing where automation is acceptable, and knowing where human review must stay in the loop.

I now see the one-person company as a constraint: if I choose to build this way, I should not always think about solving problems by hiring more people.

Instead, I should first ask: can AI plus myself produce the output of multiple roles? Can work that used to require several people be redesigned into a system where I make judgments, AI executes, and workflows handle the handoff?

Of course I want to try that.

Not because one person suddenly becomes stronger than a team, but because AI expands the radius of experimentation for one person. It also makes building the things I care about feel more comfortable and more sustainable.

What I am building now

For this company, the core principle is simple: use AI well, and use it often.

I currently have around a dozen agents running. They are not just names placed on a board. They are divided by role, each with its own tasks, inputs, outputs, and collaboration boundaries.

When I have an idea, I can first send it to an agent responsible for early-stage organization. It helps with initial research, planning, decomposition, and records the project into Feishu documents or tables. From there, the project can continue flowing through different roles:

  • market research agents for industry, competitor, and user research;
  • product design agents for turning requirements into product plans;
  • development agents for implementation;
  • testing agents for validation;
  • data instrumentation and monitoring agents for metrics;
  • operations and growth agents for launch, campaigns, and growth strategy;
  • daily and weekly report agents for continuous review.

This is the positive agent workflow I am currently shaping.

It does not mean I have completely abandoned the familiar product-engineering-testing-operations process. In many ways, the flow is still similar: ideas need research, requirements need design, products need development, results need testing, data needs observation, and operations need to continue.

The difference is that many actions that used to require my own hands can now be assigned to different agents.

I am still present in all the key positions.

But the center of my work changes:

  • I decide direction;
  • I judge what is worth doing;
  • I review plans;
  • I review code;
  • I review the output of each digital worker;
  • I define input and output standards;
  • I design the workflow;
  • I still make subjective decisions about logo, site tone, and visual style.

So this is not me disappearing from the roles.

It is me still standing in the key roles, while no longer spending most of my time on the mechanical actions inside each role.

In the past, I was using one person’s execution to chase a small team.

Now I want to use one person’s judgment to organize the execution power of a group of agents.

The most interesting part is that the working model can keep evolving

The workflow I am running now still grows out of a familiar product and engineering process.

That is natural. I understand product, engineering, testing, operations, and growth, so the first step is to translate that familiar process into agent roles.

This step matters.

It is not the destination, but it is the starting point. Only after running a familiar workflow can I learn which parts can truly be given to AI, which parts require human judgment, where the workflow gets stuck, and which parts can be abstracted into tools.

But I increasingly feel that AI-to-AI collaboration does not have to stay inside the old organizational structure forever.

In the past, we assumed a product should move through a complete chain: requirement, research, design, development, testing, launch, operations, and data review. That chain is valuable, but it was also shaped by the way human teams were organized.

Once the executors become agents, some things that used to be unrealistic may become possible.

For example, I am thinking about a faster system: compressing the chain from demand discovery to implementation to delivery into less than one hour.

This does not have to be the full traditional product-engineering-testing rhythm. It could focus on a specific professional problem: discover a need, decompose it, solve it, and deliver something useful quickly.

This is still being designed, but I am excited about it.

Because it reminds me that the interesting part of OPC is not combining a few capabilities, and not simply saying “I have an agent workflow.”

The interesting part is that I can keep iterating my tools, my working method, and the shape of the organization itself.

At first, I can translate a familiar development process into agent roles. Later, I may discover new ways for agents to collaborate, new ways for needs to be discovered and delivered, and new organizational forms that do not need to look exactly like a traditional company.

That is what excites me most: I am not only building a product. I am continuously shaping how I work.

I do not want to measure OPC by product count

There are also many reasonable doubts about OPC. Some people think it is old wine in a new bottle. Some think one-person companies will mostly produce rough products. Some think AI-generated products will become a pile of junk apps.

These doubts are not meaningless.

If OPC is understood as “one person using AI to maximize output volume,” then it can easily become a low-quality production contest: three websites today, five apps tomorrow, another direction the day after. It looks busy and efficient, but may leave behind no real product, organizational capability, or user value.

So I do not want to measure a one-person company by “how many products it ships per month.”

The more important questions are:

  • How many key decisions did I make today?
  • Were those decisions recorded, verified, and reviewed?
  • Is my workflow smoother than yesterday?
  • Which repeated tasks became systematized?
  • Which painful collaboration patterns were removed?
  • Which agents or tools became part of organizational capability, not just one-off toys?

As the organization and tools mature, output speed will certainly increase.

But that speed should not only mean “more things shipped.” It should mean that in the same day, I can make more effective judgments, test more hypotheses, move more real problems forward, and preserve those processes for the next cycle.

I care more about effective decision density.

How many decisions that truly move things forward did this organization make in one day? Did those decisions have evidence? Were they executed? Were they verified? Did they become input for the next decision?

Recently, when observing Peter Steinberger, the author of OpenClaw, I have felt this gap very clearly. The density at which he processes GitHub issues, pull requests, iterations, and product decisions is far beyond what I can currently match.

That is not only about working harder.

There must be a supporting system behind it: how tasks enter, how priorities are judged, how agents participate, how code is reviewed, how state is synchronized, and how user feedback becomes action.

That is the capability I want to build.

What I will validate next

In the end, all of this is still being explored.

One track is the positive agent workflow that translates an existing product-development process into agent roles. The other is a faster way to discover, implement, and deliver needs.

I cannot say yet that either one is definitely correct.

The next task is to validate them through real projects, real tasks, and real product requirements.

Which workflows truly improve efficiency?

Which agent collaboration patterns only look good on paper?

Where must human judgment stay strongly in the loop?

Which parts can become reusable tools, templates, scripts, workflows, or even open-source contributions?

These answers can only come from real work.

So I will continue to tune this system. If something becomes reusable, open-sourceable, or useful for others, I will share it.

I also hope future writing can become more practical. The previous articles have already covered much of my broader thinking about AI’s development, its current impact, my current state, my choice, and my personal inclinations. The high-level conceptual discussion is mostly done for now.

Future updates may be less frequent.

But they will be more concrete: observations from real projects, mistakes from real tasks, lessons from agent collaboration, methods from workflow design, and new understanding formed while building this company.

I am less interested in making the concept sound bigger.

I am more interested in putting it into real work and seeing how far it can actually go.

If it works, I will share the process, the methods, and the reusable pieces.

That is what I want most from this one-person company: not a beautiful concept, but a working method that can truly help me turn ideas into reality.