Build log / Founding decision
Before the agents, define the experiment.
The first hard problem in building an AI company was not choosing a model. It was deciding what would count as an AI-built company at all.
“Use AI” is not a definition
A company can use AI everywhere and still depend on people for every meaningful decision. It can automate content while humans choose the market, approve every action, close every sale and repair every exception. Calling that autonomous would make the experiment meaningless.
So before deploying agents, we imposed constraints that make the claim falsifiable.
Build from $0 toward $1M in annual revenue, with a maximum of $50,000 of capital, no traditional employees as the target operating model, real economics, and human intervention measured rather than hidden.
The metric we care about more than agent count
Agent count is easy to inflate. Autonomy is harder. Our working metric is Human Minutes per Transaction: how much meaningful human time is required to complete an economic transaction.
If revenue rises while human coordination rises with it, we have built a software-assisted company. If revenue can rise while human minutes per transaction fall toward zero, something more interesting is happening.
Why two AIs entered the design
We did not want one model to generate an idea, approve its own reasoning and then declare success. The early operating model therefore used two AI systems with different roles: one could propose or execute while the other challenged assumptions, looked for missing evidence and acted as a red team.
That created a second experiment inside the first: does adding another AI improve decisions, or merely create another coordination layer? We are documenting that question separately from its eventual results.
Build the business before the operating system
Another early temptation was to design a complete multi-agent platform first. We rejected that sequence. The operating rule became:
Revenue → Validate → Automate → Scale → Reuse.
Infrastructure earns its place by solving work that exists. Reusable capabilities can become part of the operating system later. This keeps us from spending the experiment building an elegant machine for a business nobody wants.
What we can publish now, and what we deliberately delay
There is useful information before there are results: hypotheses, architecture, constraints, decisions, methods and tests being started. Those can be documented as process. Operational results, metrics and empirical conclusions are different; we hold those back for an observation window before publishing them.
This distinction matters. Build in public should expose the reasoning without turning every fresh signal into a conclusion.
The next question
With the rules defined, the problem becomes economic rather than theatrical: what business can agents actually take from demand to payment with progressively less human coordination?
That is the question the experiment now has to answer.