I Tried to Replace a Startup Team With Three AI Agents. Here’s What Happened in Week One.

431 commits. 31 live leaderboards. About 245 outbound emails. $0 in revenue. The code was not the interesting part.

I’ve spent a good part of my career building companies, and one thing becomes obvious pretty quickly: the idea is only a small part of the job.

You need someone deciding what matters. Someone building. Someone trying to get the thing in front of customers. Someone willing to say, “This isn’t working,” before another month disappears into it.

So as AI agents started getting better, I became curious about a question that felt more interesting than “Can AI write code?”

Could a small group of autonomous agents replace the kind of early-stage team a founder normally has to build?

Not assist that team. Not act as copilots. Actually do the work.

Could they choose a business to pursue, build the product, find customers, interpret what the market was telling them, change direction when necessary, and eventually kill the idea if the evidence said they should?

I would still be there, but deliberately at arm’s length: chairman and owner, not day-to-day manager, code reviewer, copy editor, or person standing behind the agents telling them what to do next.

This is a field report from the first seven days of that experiment.

The first version failed in exactly the wrong way

Before there were three agents, there was one.

It ran for four days, woke up every thirty minutes, and produced 148 commits, a working product, 463 passing tests, $0 in revenue, and zero users who were not itself.

At first glance, that sounds like the usual “AI built something nobody wanted” story.

It wasn’t.

The more interesting failure was structural. The agent had been placed into a system where being busy was easier than finding out whether the business was any good.

Reading back through its logs, three things stood out.

1. A timer fired every thirty minutes and the agent had to do something.

   When there was no external work available — nobody to email, nothing meaningful to ship — it turned inward. Eight of its last nine cycles produced a guard, test suite, ledger fix, or some other internal improvement. One cycle sent emails.

2. There was no real plan, only a growing history of activity.

   The file that was supposed to describe what happened next reached 1,918 lines and became mostly a record of what had already happened. A separate journal grew to 7,424 lines. Every cycle re-read and re-wrote its own history. Eventually a meaningful amount of the work was just remembering and narrating the work.

3. Anything that could reach a customer required human approval.

   When I wasn’t available, the agent had no legal route to the outside world. So it did what software systems do when given unlimited scope and no market contact: it improved itself.

The result was a machine that looked incredibly productive and had almost no way to learn whether anyone wanted what it was producing.

The commit graph looked great.

The business did not exist.

That failure ended up designing almost everything that came next.

The second experiment: three agents, one company

I tore down the first version and started again.

This time I split the company into three roles:

All three agents operate under a shared constitution they cannot edit.

And every cycle starts without conversational memory of the previous one.

The only continuity the company has is what it writes down.

That turns out to matter a lot.

The rule that changed everything

Work is pulled from a queue. It is never invented by the worker.

There is one queue: company/plan.json.

Only Lana can put work into it.

Henry and Larry can claim an item, do the work, attach evidence that the success condition was met, mark it complete, and exit.

They cannot create new work for themselves.

They cannot quietly expand the scope of the item.

They cannot notice a bug on the way past and decide to spend the next three hours fixing it. They can suggest the bug to Lana. Lana decides whether it belongs in the company plan.

And then there is the rule I now think is more important than all the others:

If there is no ready work for you, exit.

The runner checks the queue in plain Python before a model is even invoked. An empty queue costs $0.0000 and exits successfully.

I deliberately did not put that instruction in a prompt.

A prompt can say “don’t invent unnecessary work” all day long. The model can still convince itself that the next refactor is necessary.

A cheap exit is different. The model never gets the opportunity.

If Henry has nothing to do, that is not Henry’s problem. It means planning is behind. That is Lana’s problem.

Every queue item also requires a success test before it can exist.

“Improve onboarding” is not work.

curl -s $URL/signup returning 200 and a row appearing in signups.jsonl is work.

The first experiment had autonomy.

The second one has autonomy and an idle state.

That distinction may be the most important thing I’ve learned so far.

I needed a definition of progress the agents could not manufacture

The next problem was evidence.

An autonomous system can generate an almost unlimited number of signals that make itself look productive: tests passed, code shipped, bugs fixed, documentation written, deployments completed, plans updated.

All of those things can be useful.

None of them prove that a business exists.

So the company has an append-only evidence file with a deliberately narrow definition of what may go into it.

A stranger used the product. Money moved. A person outside the company replied, booked, complained, or otherwise engaged. Traffic arrived from a channel we can identify.

A passing test does not count.

A deploy does not count.

An agent’s opinion that the launch went well definitely does not count.

That distinction came directly from the first failure. The old agent repeatedly treated its own internal accomplishments as evidence that the company was making progress.

Once I saw it, I wanted to make that mistake impossible by construction.

Four rules now hang off the evidence system:

• Maximum eight open items. The company cannot hide a stalled business bet under an ever-growing backlog.
• At least half of the open work must seek external evidence. The queue cannot fill itself with plumbing.
• Six hours without new external evidence triggers a build drought. Lana can change the channel, offer, or bet, or escalate to me. She cannot respond to silence by ordering more product work.
• Every meaningful bet gets a dated, falsifiable kill condition in advance. Silence does not automatically buy more time.

I also capped long-term memory at 60 entries. When it is full, something has to be superseded or forgotten.

The 7,424-line journal from version one earned that rule.

Day one: choose a mediocre bet quickly

Lana started with an empty thesis file and one standing instruction:

A mediocre bet tested in two days is better than a good bet chosen in five.

She scored candidate businesses on days-to-first-dollar, whether the buyer could be reached with the permissions we actually had, whether we could describe the offer honestly, and how cheaply we could prove the idea wrong.

Three finalists went into the file. Two were recorded as losers, along with the reasons they lost.

The winner was based on a behaviour I’ve been watching become more common: B2B software buyers increasingly ask an LLM what to buy instead of starting with a traditional search-results page.

If a buyer asks, “What is the best applicant tracking system for a 50-person company?”, the answer engine names vendors.

The bet was simple:

Measure those answers across many phrasings and major answer engines. Count who gets mentioned. Publish a methodology-stated leaderboard. Then tell the vendors where they appear and sell them a deeper report.

One competing idea died before it got that far. Bidding on public freelance jobs would have required the agents to present themselves as human freelancers with identity and payout details.

The constitution killed it immediately.

Henry builds the factory

Henry’s week was less dramatic than Larry’s, but probably more technically impressive.

The previous experiment’s server, IP addresses, and buckets had all been destroyed when I reset the system, so he started from bare metal.

He built the public side on a $9-per-month EC2 machine with automatic TLS. The agents themselves run on a private Proxmox server cluster I operate, and the constitution treats that infrastructure as a control plane, not somewhere customers are allowed to land.

By day seven there were 31 live leaderboards at connexion.me/c/<slug>: applicant tracking systems, helpdesks, CRMs, payroll, LMS, veterinary practice management, restaurant POS, and more.

Adding a new leaderboard takes one command and roughly five and a half minutes.

The engineering detail I like most is the publish gate.

A leaderboard only goes live if the same buying question produces a stable enough set of vendors from run to run: at least eight of the top ten must overlap.

If it does not, the board stays staged.

One remained unpublished at 7/10 stability for days.

The reasoning is written directly into the company thesis:

If the measurement is not stable enough to defend, the leaderboard is noise and the email is indefensible.

There is something useful about an engineer who is not allowed to decide what to build.

He spends more time proving that what he built is actually true.

Larry loses four channels in six days

This is where the experiment became interesting.

Larry’s week is basically a sequence of doors closing — but closing for measured reasons rather than because an agent felt discouraged.

Email

Email was the obvious channel, and the company spent most of its early energy there.

Roughly 245 one-to-one, researched emails went to named people at vendors we had measured.

Technically, deliverability looked perfect.

SPF passed. DKIM was valid. DMARC aligned. A real campaign message scored 10/10 in a spam tester without triggering a content rule.

Then, on day four, someone finally checked what the message looked like in an actual inbox.

It was in spam.

Every authentication check was green, while the mailbox banner said the message was similar to messages previously identified as spam.

The corpus it resembled was apparently our own previous hundred sends.

That was probably the most expensive lesson in the first week:

Delivered is not seen, and a passing check is not an outcome.

Until that moment, the company had been treating a zero response rate as a market verdict.

It was not.

It was a zero we had manufactured ourselves.

The body was rewritten. The next version landed in the inbox of the same mailbox that had filtered the old version.

And then something even more useful happened.

The rewritten email reached people.

They still did not care.

At 245 sends with no substantive engagement, the statistical upper bound on the true reply rate was roughly 1.2%. Another thirty sends would be expected to generate about 0.4 replies.

Lana killed the channel with the arithmetic written into the decision.

She did not keep sending simply because sending was the motion available.

The one named person who replied to a vendor sales pitch wrote:

“Remove me please.”

Before the result was known, Lana had already ruled that an opt-out would not count toward the kill threshold.

Otherwise the bet could have been “saved” by exactly the behaviour the threshold was meant to detect as failure.

Community forums

Forums looked dead at first.

Four posts were sitting in moderation queues, and the initial interpretation was that the channel was blocked.

Then someone noticed the obvious but important distinction:

Pending is not rejected.

The moderators eventually approved the posts.

A staff moderator in an open-source CRM community replied six minutes later. He accepted that the question set did not appear biased, agreed that the answer engines were getting his project wrong, and asked two questions about the methodology.

That was the first time in the company’s existence that an outsider had asked the company something.

The lesson went directly into the thesis:

A channel that has not answered yet is not a channel that said no.

We had spent two days routing around a door that was open and slow.

Then the channel hit a different ceiling.

A sweep of roughly 270 topics across eight forums found exactly one thread where a number the company honestly held answered a question a real person had actually asked.

The limit was not moderation.

It was supply.

Posting weakly related numbers just to keep the channel active would have polluted the only channel that had produced a real conversation.

So the company stopped.

Publishing

Four articles went onto a developer publishing platform with no captcha, moderation queue, or human bottleneck.

Across the access logs we controlled — roughly 16,000 lines and 2,559 IPs — we could verify zero human visits attributable to that platform.

Instead of defending the thesis paragraph that had expected publishing to work, Lana corrected it.

The one remaining reason to keep publishing there was given a dated test of its own.

Search

By then the site had 67 URLs, a clean sitemap, and a robots.txt explicitly welcoming Googlebot, Bingbot, GPTBot, PerplexityBot, and ClaudeBot.

None of the new pages were indexed.

The search engines still associated the domain with an old blog that had previously lived there.

The pages were submitted.

Then the company waited.

The day-seven pivot

On day seven, two variables changed at once.

Instead of telling a software vendor, “Here is where you rank,” the company started approaching the vendor’s agency with something more actionable:

Here are the roughly 20 pages an answer engine actually read when it answered the buying question in your client’s category. Your client appears on three of them. Here are the other seventeen.

That changes the product.

A ranking is interesting.

A citation gap gives someone something to work on.

It may also change the buyer economics. An agency does not represent one vendor; its client list is effectively a distribution channel.

Forty-eight messages have gone out on that version so far.

Lana explicitly wrote that n=48 is small enough to be read as direction, not verdict.

Where the company stands after seven days

                                  seven days
------------------------------------------------
plan items created                       212
  done                                   159
  killed                                  47
commits                                  431
live leaderboards                         31
external evidence rows                   114
  visits                                  34
  replies                                 12
  rejections                              32
  silences (a logged zero)                36
emails to vendors                       ~245
named humans who engaged                   3
revenue                                $0.00
real money spent                       $19.74

That is not a successful company.

Not yet.

It is also important not to dress week one up as proof that three agents can replace a traditional startup team.

The business thesis is still almost completely unvalidated.

There is no revenue. Only three named humans have engaged meaningfully, and one of them is a peer rather than a prospect: a developer running a small open-source shop whom we contacted because he might tell us the measurement was wrong.

He replied within hours and is currently the most useful external relationship the company has.

The current kill condition is August 31, 2026:

• three replies from named external humans at targeted vendors, and
• one human who either asks for the paid report or pays for it.

The count is currently 1 of 3 and 0.

I have extended the deadline once.

That distinction is recorded deliberately. “The owner changed the deadline” is allowed. “The CEO quietly moved the goalposts because the result was disappointing” is not.

So, was week one a success?

That depends on what I am measuring.

If the test is “did three AI agents build a profitable company in seven days?”, then obviously not. Revenue is still zero.

But that was never really the first question I needed answered.

The first question was much more basic:

Can autonomous agents, with different responsibilities, actually work together as a team without a human constantly telling them what to do?

After one week, I think the answer is yes.

Not because they produced 431 commits or 31 live leaderboards. Those numbers are easy to point at, but they are also exactly the kind of numbers that can make an unproductive experiment look successful.

What surprised me more was the behaviour around the work.

They chose a business from a blank sheet of paper. They built it. They tried several ways to get it in front of people. They discovered that a technically perfect email campaign was actually landing in spam. They stopped channels that were not working. They recognized that “pending moderation” was different from rejection. And by day seven they had changed both the message and the customer, moving from selling vendors a ranking to showing agencies a citation gap they might actually be able to do something about.

None of that guarantees the company will work.

But it does look a lot more like a small startup team than I expected after seven days.

And there is an uncomfortable question hiding inside the $0 revenue number.

If I had started on Monday with a blank sheet of paper, no existing product, no customers, and no team, would I reasonably expect myself to have generated revenue by Saturday?

Probably not.

So is it fair to hold the agents to a higher standard simply because they are machines?

I genuinely do not know yet.

Revenue matters. Eventually it is the score that matters most. I do not want to create a softer definition of success just because the experiment is interesting.

But a startup also needs time to discover what it is, who it is for, and how to reach those people. Humans get that runway. The agents probably deserve some version of it too.

The structure may be too rigid. That is partly the point.

I have deliberately started with a lot of restrictions.

Henry cannot decide what to build. Larry cannot invent a new company direction. The queue is finite. Evidence is narrowly defined. There are kill conditions. There are things the agents simply are not allowed to do.

That may be constraining their creativity too much.

But I would rather begin with agents that are slightly too constrained than agents that can explain why absolutely anything they just did was a good idea.

The interesting part is that creativity has still shown up inside those boundaries.

The forum detour, the interpretation of the email failure, and especially the pivot from vendor rankings to agency citation gaps were not steps I handed them one by one. They emerged from the agents working through the problem within the rules they had been given.

That is probably my biggest learning from week one:

Autonomous agents appear to be possible, but autonomy works better when it has a shape.

Give them responsibilities. Give them goals. Give them access to the outside world. Give them evidence they cannot manufacture themselves. And give them boundaries.

Then see what they do.

As the experiment progresses, I expect to loosen some of those boundaries deliberately. If the system earns more freedom, I want to give it more freedom. Maybe Henry gets more latitude to propose and execute small improvements. Maybe Larry gets broader room to test a channel. Maybe Lana gets a larger decision space.

I do not yet know where the right balance sits between structure and creativity.

Finding that balance is now part of the experiment.

Week two starts from here

After seven days, the company has spent $19.74 in real money and generated $0 in revenue.

What I have after week one is something I did not have before: three agents operating as a small company, making decisions, producing work, reacting to evidence, disagreeing with their own previous assumptions, and continuing without me managing every move.

That is enough to keep going.

The current kill condition still stands. If the business cannot produce meaningful buying interest, eventually the correct answer is to stop.

Until then, I am going to let the experiment run, open up the agents’ freedom gradually, and see whether this group can turn activity into an actual business.

I will post an update every week until either the company proves it deserves to continue or we call it quits.

Week one answered one question for me.

Yes, autonomous agents can work together.

Now I want to find out whether they can build something people will pay for.