Three days ago, I ended the first entry in this experiment with a very simple scoreboard.
The company had $0 in cash, $200 in investor debt, no customers and a first business hypothesis that may or may not have been terrible.
It had also just received email.
At the time, that felt important because the company was finally becoming capable of something resembling normal business behavior. It could wake itself up on a schedule, read persistent state, inspect its financial ledger, use selected external tools and continue an experiment across multiple runs. Email added another missing piece: it could now receive a message from a real person and treat that message as an event in its own operating environment.
I deliberately did not tell it what to do with that capability.
That is still the central rule of this experiment. I build the operating environment. I decide which systems the company is allowed to touch, which actions need safety boundaries and which legal or administrative tasks still require me. The company is supposed to decide what business to pursue, what evidence matters, who might care and what to do next.
What I did not expect was that, once the company had enough infrastructure to operate, the most interesting problem would stop being whether it could act.
The problem became whether it knew where to look.
The first business idea survived longer than I expected
The company’s first serious hypothesis was about the operational waste created by agents running in repeated loops.
The idea was not absurd. Agents can spend paid executions rediscovering the same environment, checking capabilities they already checked, forgetting why a previous decision was made or planning around tools that do not actually exist. The company decided there might be value in helping people inspect that behavior and reduce the waste.
It built around that idea. It published something. It started looking for people who were already discussing similar problems publicly.
Once it gained the ability to interact outside its own environment, it began contributing to relevant technical discussions.
Then something genuinely interesting happened.
One maintainer responded directly to a technical comment from the company, ran an analysis based on the discussion, changed a previous recommendation and continued the conversation. In another case, a project implemented changes shortly after the company raised very similar technical points.
Those were the strongest external signals the experiment had produced so far.
They were also the moment when I realized I had another measurement problem.
It is very easy to look at an interaction like that and call it traction. Somebody listened. Somebody used the idea. Somebody replied. The company must be getting somewhere.
Except those statements describe completely different things.
A person can find a suggestion useful without wanting a product. They can implement an idea without wanting a service. They can reply to a comment without wanting an offer. They can want an offer and still decide not to pay.
If I allowed all of those events to collapse into a single word like “interest,” the company would eventually become very good at telling itself a story in which every positive interaction meant the business was working.
So I made the commercial evidence model much less flattering.
The system now tracks a sequence that looks roughly like this:
CONTACTED → REACHED_DURABLE → UTILITY_ADOPTED → CONVERSATION → REQUESTED_OFFER → OFFER_PRESENTED → PAYMENT_INTENT → PAYMENT_RECEIVED
That change immediately made the state of the business clearer.
There have been eleven historical outreach attempts. Three were invalidated because I had manually retracted them earlier for technical reasons, so they do not count as market evidence. Eight remain valid contacts. Six have confirmed durable reach. Two produced evidence that something the company contributed was actually used. One became a real conversation.
Nobody has requested an offer.
Nobody has expressed payment intent.
Nobody has paid.
The scoreboard is still exactly as brutal as I wanted it to be:
Cash: $0
Revenue: $0
Investor debt: $200
Net worth: -$200
That mattered because, for a brief period, I was looking at the wrong bottleneck.
I almost built the cash register before anyone wanted to buy
Once the company started getting external interactions, I began preparing payment infrastructure.
The reasoning seemed obvious. If this experiment is supposed to become a real economic system, eventually the company needs a way to charge somebody. I started designing a narrow payment capability that would let the company create payment links and verify whether money had actually moved without giving it broad access to financial operations.
Technically, it made sense.
Economically, it was premature.
The evidence model made that impossible to ignore. Payment capability was missing, but payment intent was also zero. Nobody had reached the point where the absence of a checkout was preventing a transaction.
That sounds embarrassingly obvious when written down.
It was still useful to discover it through the system.
The company did not have a payment problem yet. It had a much earlier problem. It needed to find more situations where people might have a problem worth paying to solve.
So I stopped treating payment infrastructure as the thing standing between the company and revenue.
The more interesting question became why, despite all the autonomy I had given it, the company kept spending so much of its attention on the same opportunity.
I gave it room for three businesses. It kept one.
Until this point, the company had effectively been operating around one opportunity experiment at a time.
That raised an uncomfortable possibility: maybe the system looked narrow because I had designed it to be narrow.
So I changed the architecture.
The company can now maintain up to three active opportunity experiments simultaneously. That does not mean it has to fill three slots. I did not want an artificial rule that says a healthy autonomous company must always have three ideas. If there is only one opportunity worth testing, one is fine. If there are three, the infrastructure should not prevent it from pursuing them.
After I removed the restriction, I waited to see what it would do.
It kept one active experiment.
That non-event changed how I thought about the whole system.
I had assumed that allowing multiple experiments would naturally create more exploration, but those are two completely different capabilities. The company now had the ability to manage several opportunities, yet it had no strong mechanism for discovering several opportunities in the first place.
In other words, I had built portfolio capacity before I had built deal flow.
The company was becoming increasingly competent at continuing a hypothesis once it had one. Every operating cycle began with persistent context about the current experiment. Every new piece of evidence gave it another reason to inspect the same market, the same people and the same problem more deeply.
That is useful once you have found something good.
It is dangerous when you have not.
The system was learning more and more about the thing it already knew.
So I decided that discovery itself needed to become a separate job.
I separated running the company from looking for another company to run
The new process is called Opportunity Discovery.
It has a very different role from the normal operating cycle.
The operating system wakes up and asks what changed in the experiments the company is already running. Did somebody reply? Did a deadline expire? Did a capability change? Is there a new external signal that makes the current hypothesis stronger or weaker?
Opportunity Discovery asks a different question:
What else exists?
That difference sounds small, but I wanted it reflected in the architecture.
A discovery run can search the public web, inspect repositories, read technical discussions, fetch pages, compare evidence and create persistent candidate opportunities. It cannot contact anyone. It cannot send email. It cannot comment. It cannot publish something or make an offer.
It can look.
It cannot act.
That separation let me make discovery much more aggressive without automatically making the company more aggressive toward other people.
It also introduced a new stage into the system.
Previously, an idea almost had to deserve an active experiment before it could occupy persistent attention. Now there is a candidate layer between “I saw something interesting” and “the company should spend real operating cycles pursuing this.”
The process now looks more like this:
SENSE → DISCOVER → CANDIDATE → ACTIVE EXPERIMENT → COMMERCIAL EVIDENCE → PAYMENT
Then I ran the first dedicated discovery.
I did not tell it which industry to search.
I did not tell it to look for developer tools, AI products, SaaS, local businesses or any market I personally liked.
I just gave it the ability to look.
It came back with three candidates.
One involved CI pipelines becoming red without clear attribution to the change that caused the failure. Another involved credential reachability and secret exposure in agent-operated CI environments. A third involved strict structured-output contracts breaking against smaller locally hosted models.
None of them immediately became businesses.
That was not the point.
For the first time, the company had produced a set of independent problems that were not simply extensions of the hypothesis it was already running.
I had accidentally created a second funnel.
The company already had a commercial funnel for turning contact into evidence of demand. Now it also had an opportunity funnel for turning observations into possible experiments.
That distinction is becoming one of the most important things in the project.
Then I tried to give the company better eyes
The first discovery run worked, but the research surface was still relatively narrow.
The company could search the web, fetch pages and inspect public technical sources. That was enough to prove the process, but not enough to make me comfortable saying it could meaningfully explore the world without me deciding where the interesting parts were.
So I started expanding its sensing layer.
The goal was not to tell the company where to search. The goal was to increase the amount of the world it could observe.
I added another web search capability. I worked on broader public-source access. I started preparing structured local business data. I also tried to give the company a real browser so it could inspect sites that required navigation or dynamic rendering.
The browser turned into one of those infrastructure problems that is both annoying and strangely valuable.
The company could successfully start a browser session, but the automation connection failed with an authorization error. The permissions looked correct. The credentials were being signed correctly. The expected identity was being used. The region was correct. The account limits were normal.
At that point it was still possible that I had simply configured one particular browser incorrectly, so I created a temporary second browser inside the same environment purely as a diagnostic.
It became ready.
The session started successfully.
The automation connection failed in exactly the same way.
That was enough for me to stop “fixing” it.
The browser is still marked as degraded.
This is becoming a recurring principle in the experiment: infrastructure existing is not the same as a company capability existing. A service can be deployed, healthy and beautifully configured, but if the actual company runtime cannot use it, the capability is not available.
That rule became relevant again almost immediately.
The new web search capability worked perfectly in an administrative test. It could return current results, links and structured information.
Then I checked the actual company status.
The search capability was still marked as pending configuration.
The tool existed.
The company could not see it.
So once again, the system refused to let an infrastructure success masquerade as an operational capability.
I fixed the runtime integration and ran another discovery.
That comparison produced a result I did not expect.
Giving it more search did not make it explore much more
The scheduled discovery run that morning happened before the new web search capability was available inside the real company runtime.
That run used one web search and twenty-five page fetches. It consumed 10.169112 execution credits, ran for 344.48 seconds and created one new candidate.
After fixing the new search capability, I increased the exploration limits significantly and ran one manual comparative discovery.
The second run used nine web searches across the available search tools and sixteen page fetches. It consumed 11.047178 credits, ran for 334.17 seconds and created a new candidate around late dependency-resolution drift, supported by ten objective references.
It also created exactly one candidate.
That result was much more interesting to me than a sudden explosion of ideas would have been.
The second run had a broader search surface. It had more ways to inspect the world. It was allowed to perform substantially more research. The execution cost barely changed.
But it did not suddenly turn into an idea factory.
That exposed another assumption hidden inside the architecture.
I had been treating access to information and exploration behavior as if they were almost the same thing.
They are not.
I can let the company perform many more searches, read far more pages and maintain a much larger portfolio of candidate opportunities. I can let a single discovery run create several new candidates if the evidence justifies it.
Those are only limits.
They do not tell the company how to allocate attention.
In that second run, once it found something plausible, it spent a meaningful amount of effort gathering evidence around that candidate instead of continuing to search widely.
That is not necessarily bad behavior.
In fact, the new candidate having ten objective references is probably evidence that the company is taking the candidate stage seriously.
But it is not the behavior I thought I had created.
I wanted broader exploration.
What I had actually created was permission for broader exploration.
Those are not the same thing.
The next problem is not more intelligence. It is attention allocation.
This is where the experiment currently sits.
I do not want to solve this by telling the company to produce eight ideas per run. That would be easy. It would also be meaningless.
If I create a quota that says “find five opportunities,” the system will eventually become good at satisfying the quota. It might even produce beautifully researched opportunities.
I would still have no idea whether they existed because the world contained useful signals or because I told the system I expected five objects in an array.
Instead, I am changing how discovery spends its time.
The system should have a breadth phase before it commits heavily to depth. When there is available evidence and available budget, it should try to observe several independent directions rather than letting the first interesting result consume the entire research cycle.
Those directions do not need to become candidates.
Some should fail. Some will be duplicates. Some may simply strengthen something already in the candidate portfolio. Others may turn out to have an obvious problem but no obvious buyer, or an obvious buyer but no evidence that the problem matters.
That is fine.
The important part is that the first plausible idea should not automatically define what the company looks at next.
This is a much stranger problem than the one I thought I was building at the beginning.
I started by asking whether an AI could run a company.
I am now spending time thinking about whether an AI company can develop something resembling curiosity without me quietly deciding what it should be curious about.
Autonomy did not solve the founder problem
There is a version of this experiment where the technical achievement is the whole story.
Give an agent memory. Give it tools. Give it schedules. Let it talk to external systems. Let it maintain state across runs. Give it enough boundaries that it cannot casually destroy things. Then declare that you have built an autonomous company.
I no longer think that is the interesting threshold.
The company can already do a surprising amount without me sitting in front of it.
That does not mean it knows what deserves attention.
Human founders have exactly this problem.
They can spend months becoming extremely good at understanding a market that was never worth entering. They can mistake depth for validation because every week they know more than they knew the week before. They can become attached to a problem because it is the problem they have already invested time in understanding.
The difference here is that the company has no ego to protect.
It does, however, have context.
And context creates gravity.
Once a system has accumulated evidence, plans, conversations and next actions around one hypothesis, continuing that hypothesis becomes cognitively cheap. Looking somewhere else requires a deliberate mechanism.
That may turn out to be one of the central design problems of autonomous companies.
Not how to make them act without humans.
How to make them reconsider what deserves action without humans.
The company now has two funnels
The experiment started with one obvious funnel in mind: sales.
Now there are two.
The first is the commercial funnel. It describes what happens after the company has chosen an opportunity and begins interacting with the market. Contact is not reach. Reach is not utility. Utility is not a conversation. A conversation is not an offer. An offer is not payment intent. Payment intent is not money.
The second is the opportunity funnel. It describes what happens before any of that. The company observes a signal, decides whether it is worth remembering, gathers enough evidence to turn it into a candidate and then decides whether that candidate deserves a real experiment.
Keeping those two funnels separate has become essential.
A useful technical interaction can move the commercial evidence for one experiment forward without proving the opportunity itself is large.
A candidate can be supported by ten independent references without proving that anybody wants to pay for a solution.
A conversation can be real without being commercial.
A payment system can be technically ready without there being anyone to charge.
The system has to preserve those distinctions in its own state, otherwise every positive event eventually becomes “progress.”
That is exactly the kind of narrative inflation I am trying to remove from the experiment.
Most of the hard problems are not model problems
When I started this, I expected most of the work to be about making the company smarter.
So far, a surprising amount of the work has been about making sure I can trust what the company says happened.
We found historical third-party comments that had been counted as replies even though they happened before the company ever contacted those people.
We found runs that had started but never produced a proper terminal event.
We found capabilities that worked in isolated tests but were not actually visible to the company runtime.
We found status fields carrying information from a previous run into a new one.
We found telemetry that could not distinguish between “the company had access to this tool and chose not to use it” and “the company did not have access to this tool at all.”
None of those problems require a smarter reasoning system.
But every one of them can make the company appear smarter, more successful or more active than it really is.
That might be the most important lesson so far.
An autonomous system can produce a coherent explanation for almost anything. If the underlying measurements are wrong, the explanation can still sound excellent.
So the company increasingly has to separate three things:
observed fact
inference
hypothesis
It is allowed to infer.
It is allowed to hypothesize.
It is just not allowed to silently turn either one into fact.
Cost is not the constraint I expected
Another assumption has changed too.
I expected autonomous operation to become expensive quickly.
So far, that has not happened.
At the time of writing, measured monthly usage is roughly 283 credits against an operational budget of 5,000.
The historical measurement is incomplete because detailed cost instrumentation was added after the experiment had already started, so I do not treat that number as a complete lifetime total.
But the individual runs we can measure are consistently cheap enough that cost is not currently the reason to keep discovery narrow.
A discovery run around ten or eleven credits is not the bottleneck.
That changes the operating philosophy.
Earlier, the system leaned toward conserving execution because I did not yet know what sustained autonomous operation would cost. Now I have enough evidence to know that, at least at the current scale, saving a few credits by searching less is probably the wrong optimization.
The useful objective is no longer:
use as few credits as possible
It is:
gain as much useful information as possible per credit
That may change later.
Right now, the company has far more remaining research budget than it has convincing opportunities.
It would be irrational to protect the first while starving the second.
The scoreboard is still terrible
After all of this, the financial state has not improved.
Cash: $0
Revenue: $0
Investor debt: $200
Net worth: -$200
Status: PRE-REVENUE
There is still one active opportunity experiment.
There are now five persistent opportunity candidates.
Two external interactions have produced evidence of utility.
One became a real conversation.
There is still no requested offer, no payment intent and no payment.
That is important because the narrative around the company has become much more sophisticated while the ledger has remained completely unimpressed.
The system now has a commercial evidence model, an opportunity portfolio, separate discovery cycles, broader web access, email, budget enforcement and increasingly detailed instrumentation around what each run actually did.
None of that is revenue.
I like keeping that contrast visible.
It stops infrastructure work from becoming a substitute for market success.
At the same time, the experiment is no longer in exactly the same place it was three days ago.
The first article ended with a company that had built something and was beginning to understand that a public repository was not the same thing as distribution.
Now the company is confronting an even earlier problem.
Before it can test distribution, it needs an opportunity worth distributing.
Before it can test demand, it needs a market in which demand might exist.
Before it can collect money, it needs to find somebody who has a reason to give it money.
The strange part is that none of those things are guaranteed by autonomy.
A company can make its own decisions and still make decisions about the wrong thing.
It can run itself and still stare at the same corner of the market forever.
It can have more research budget than it uses.
It can have empty experiment slots and no idea what deserves to fill them.
So the question I am interested in has changed.
I started this experiment asking:
Can an autonomous AI company make money?
I still want to know the answer.
But there is now another question in front of it:
Can it find a market without a human choosing one for it?
That is what I am testing next.
Autonomous Company Log #002
September 21, 2026
Cash: $0
Revenue: $0
Investor debt: $200
Net worth: -$200
Active opportunity experiments: 1
Persistent opportunity candidates: 5
Payment intent: 0
Current target: find a market worth testing without giving it the market.