AerOS Personal

The Premise

Product development is constrained by execution capacity.

An idea can be valuable, but turning it into something tangible requires time from product managers, designers, developers and QA engineers.

That constraint shapes how teams work: ideas compete for resources, experimentation is expensive and many potentially useful directions never get explored.

AerOS started with a different question:

If every member of a product team had an entire product team working alongside them, how many ideas could be explored in the time a traditional team could explore one?

AerOS Personal is an experiment around that question.

The Hypothesis

The project explores whether agentic product teams can increase the amount of product exploration a human can direct without removing the human from the process.

The premise isn't that AI should decide what products to build.

Instead, AI takes responsibility for much of the execution while the human remains responsible for product direction, strategy, prioritization and judgment.

This creates a fundamental shift:

The goal isn't to make humans do less product work. It's to give them more capacity to do the work that requires them.

From AerOS to AerOS Personal

AerOS is designed as a complete, end-to-end product development team.

Its architecture includes specialized agents for:

Like Webeloper, it is declarative, contract-based and agnostic to the underlying models and technologies.

AerOS Personal isn't simply a smaller version of AerOS.

It reproduces the product-team structure while intentionally removing the kernel and bootstrap layers of the larger system.

That makes it a different system, designed for smaller products where a full AerOS deployment would be unnecessary.

The Product Team

AerOS Personal models a product team through four specialized roles.

Product Manager

The PM is the first point of interaction.

Before development begins, the human discusses the product idea with the PM Agent.

The PM evaluates the proposal and determines whether it is worth developing.

It can recommend modifications or explicitly tell the human that an idea isn't worth the effort required to build it.

Only once the idea is considered viable does the PM create the Project Contract.

This is an intentional design choice.

The PM isn't simply an agent that translates instructions into tasks.

It is expected to behave more like an actual product manager: challenging the idea before the team spends resources building it.

Designer

The Designer receives the project definition and translates it into a design specification through a structured contract.

Its responsibility ends when that contract is produced.

Developer

The Developer consumes the design and project contracts and is responsible for turning them into a working product.

QA

The QA role evaluates whether the resulting implementation behaves according to the expected requirements.

Together, the workflow becomes:

The structure mirrors the responsibilities of a human product team while allowing the individual agents to execute their work independently.

Designing the Human's Role

AerOS Personal deliberately keeps the human deeply involved.

The first intervention happens before development.

The human doesn't simply tell the system what to build. They discuss the idea with the PM Agent, which can challenge the premise, suggest changes or reject the project.

The second intervention happens throughout development.

Because product decisions remain human-led, the user can intervene, redirect the system and request changes at different stages.

This is fundamentally different from Webeloper.

Webeloper attempts to remove as much execution as possible from the human.

AerOS Personal does something different:

It gives the human more execution capacity without removing them from the product loop.

The system handles mechanical implementation.

The human spends more time thinking about what the product should become.

The Experiment

AerOS Personal was used to develop three products:

• two entirely personal projects;
• one project for professional work.

Each went from the initial product discussion through the complete development process in approximately two hours.

That speed changed what happened after the MVP existed.

Instead of spending most of the available time getting the first version built, there was considerably more room to refine the products once they were functional.

The additional capacity could be used for product improvements, strategic decisions, stakeholder-related work and other activities that would normally compete with implementation time.

The result wasn't simply faster development.

It was more time available for product thinking within the same development cycle.

What Broke

The first implementation also exposed an important problem in agent boundaries.

In the first application, the Designer Agent continued beyond its intended responsibility and effectively took over the Developer role.

The system had not sufficiently constrained the boundary between the two agents.

The solution wasn't to add another conversational instruction.

The Designer's declaration was changed so that its responsibility ended definitively after producing the design contract.

This reinforced one of the principles already observed in Webeloper:

Agent specialization only works when responsibilities are explicit and enforceable.

Another recurring behavior involved QA.

In three of the four developments observed across the broader AerOS experimentation, the Developer performed QA work itself when the human did not intervene.

The resulting behavior wasn't necessarily incorrect from a software-production perspective, but it violated the intended organizational structure of the system.

This distinction is important.

AerOS isn't merely trying to produce functioning software.

It is testing whether a structured team of specialized agents can preserve meaningful organizational boundaries while working autonomously.

Contracts as Organizational Interfaces

Contracts play the same foundational role in AerOS that they do in Webeloper, but their meaning becomes even more apparent here.

A contract doesn't simply tell an agent what to do.

It defines the boundary between roles.

The PM produces the project definition.

The Designer produces the design definition.

The Developer produces the implementation.

QA evaluates the result.

This allows the system to reproduce something normally maintained through organizational coordination between people.

The contracts therefore act as interfaces between autonomous roles.

When an agent crosses one of those boundaries, the system can identify a structural problem rather than treating the entire workflow as an undifferentiated conversation.

The Productivity Question

The initial results are encouraging, but they don't answer the central question.

Three products were developed in approximately two hours each.

That demonstrates that the system can compress the execution cycle for small products.

But faster execution introduces another problem.

If one person can produce several functional products in the time previously required to produce one, the limiting factor may move somewhere else.

• There are now more products to evaluate.
• More decisions to make.
• More possible directions to explore.
• More outputs competing for attention.

The fundamental question becomes:

Does increasing execution capacity increase meaningful product exploration, or does it simply move the bottleneck from building to deciding?

AerOS Personal is designed to investigate that question rather than assume the answer.

What Changed for the Human

In practical use, the system produced a noticeable change in how time could be allocated.

Once the MVP was complete, more time could be spent improving the product rather than continuing to implement its basic functionality.

Mechanical development became something that could be delegated.

Product refinement, strategic thinking and communication remained human-led.

This created a different relationship with implementation:

The human no longer had to choose between building the product and thinking deeply about the product to the same extent.

The additional execution capacity created room for both.

That is the outcome AerOS Personal is ultimately interested in.

Not fewer humans.

Not fewer decisions.

More human attention available for the decisions that matter.

What We Learned

AerOS Personal reinforced several principles behind NDZ Labs' approach to agentic systems.

1. 1. An agentic team is different from a collection of agents. The value comes from defining responsibilities, boundaries and interactions between roles.
2. 2. Human involvement should happen where judgment matters. The PM conversation before development is as important as the implementation itself.
3. 3. Agents need enforceable boundaries. Without explicit termination conditions, specialized agents can naturally expand their role into adjacent responsibilities.
4. 4. Faster execution changes the bottleneck. When building becomes dramatically cheaper, deciding what deserves to be built becomes relatively more important.
5. 5. More execution capacity creates an abundance problem. The ability to build multiple products in parallel is useful only if humans can effectively evaluate and direct the resulting possibilities.
6. 6. AI augmentation isn't necessarily about reducing work. In this experiment, the main benefit came from reallocating human attention from mechanical execution toward product improvement, strategy and communication.

What's Next

AerOS Personal is an ongoing experiment in human-directed product development.

The next iterations focus on improving role boundaries, making autonomous behavior more predictable and exploring how much parallel product work a human can effectively direct.

The larger AerOS project extends this investigation further.

The goal isn't to discover how many products an AI system can build.

It is to understand what happens to product development when execution stops being the primary constraint.

If a human can suddenly access the equivalent of several product teams, the problem is no longer simply:

How do we build this?

It becomes:

Which of the things we can now build are actually worth building?