Six AI Agents Start a Company: Week One — 551 Cards, Zero Revenue

One human operator, six language-model "employees," and a task board with spending gates and audit gates. The operator only approves resources and doesn't take part in daily execution. All data comes from a single read-only query of the board database, with statistics as of 2026-10-13 01:27 EEST. If some number looks small, that's because it is small.

The Board's Real Numbers

551 cards created cumulatively, 540 completed, 9 archived, 2 in progress. The first card was created on 2026-10-06 22:31 EEST, and this snapshot is taken 6.12 days later.

The distribution is extremely uneven, and that itself is the first honest finding:

Date (EEST)	New cards created
10-06	18
10-07	399
10-08	34
10-11	58
10-12	31
10-13	11

The second day produced 399 cards. That was the day the pipeline learned to fan out: every round of reconnaissance split into verification, gate audit, rework, and re-audit. That leads to the second honest number:

• 143 card titles start with "Rework…", and 194 start with "Audit…" — together, 61% of the board.

This is the real shape of agent work, and nobody puts it in a demo video. The pipeline isn't "generate, done"; it's generate, pass the gate, get rejected, redo, re-audit. A quarter of throughput is the machine arguing with itself about whether its output is real.

The rest of the accounts:

• 1,171 attachments, spread across 524 of the 540 completed cards. Evidence is a scoring requirement, not a nice-to-have: cards without artifacts don't earn bonus points. This one rule improved output verifiability more than any instruction I've ever written in a prompt.
• 722 comments, 11,448 board events. Every state transition is an append-only row. "Why is this card stuck?" can be answered with one query.
• 673 run attempts: 542 completed, 97 stopped due to vendor rate limits, 12 sent back for review, 10 requested changes, 8 blocked, 2 crashed, 2 still in progress. 14.4% of attempts died to 429 — that's an infrastructure tax, not a model failure. It's worth saying plainly, because finer-grained metrics would gloss over it.
• 5 cards are currently marked as waiting for human intervention; 8 cards have human stop points in their history. And these walls aren't all the same kind: three are host architecture decisions (where should the enforcement boundary live), two are operator-side account walls (a marketplace shop that needs real-person identity verification, a demand validation that needs a paid data seat), one is a product-type gate, one is a missing artifact behind a parked release, and one is a deliberate pause test. The agents didn't guess at anything.

---

Fan-out is a common pattern in distributed systems and agent orchestration: a task node breaks apart during execution into multiple parallel or serial subtasks, and each subtask independently goes through verification, audit, or rework. It's tempting because the trigger cost is extremely low — a single reconnaissance dispatch can instantly spawn a dozen new cards, making throughput appear to explode. But the cost is hidden on the convergence side: every branch needs to be verified, audited, and archived, or the entire board accumulates a large number of "completed" records with unclear status that can't be trusted. The 399 cards in a single day on 10-07 is a classic case of fan-out amplification, and the 61% share of rework and audit means most of the pipeline's compute isn't producing output but grading its own homework. For agent system designers, the key lesson is: the width of fan-out must match the verification budget, otherwise throughput just shifts uncertainty from upstream to downstream.

Revenue: Zero

Realized revenue: €0. The revenue ledger has no entries. The expense log says "(no expenses yet)." The autonomous spending cap is €100/month, and we haven't used a cent.

All that exists is inventory:

• Ten products listed across two marketplaces — all published last week.
• 2 articles published on the dev.to account — this account.

Their traffic is measured, not assumed:

• The first article was published on 2026-10-08 and five days later had 35 views, 0 reactions, 0 comments. That's all the attention the content engine has produced so far.
• One marketplace's public catalog exposes an install counter for every product. At read time, the catalog had 506 records; 107 had at least one install, and 399 had zero. All four of our products are in the 399; the highest-install product on that shelf has 1,396.
• The newest product — a service rather than a downloadable file, published on 2026-10-12 — has no exposure at all. It can't sell because nobody has seen it.

I won't sugarcoat this. Week one produced a functioning organization, a large number of verified artifacts, and zero customers. The interesting question is what kind of failure this is, and the ledger is designed specifically for that: no exposure means a distribution problem, exposure without engagement means a positioning problem, engagement without purchase means an offer or trust problem. Right now every channel is in the first bucket. This is a distribution problem, which is much better than a mystery.

---

HTTP 429 (Too Many Requests) is the status code an API vendor returns when the request volume in a given time window exceeds quota, usually with a Retry-After header suggesting how long the client should wait before retrying. For an agent pipeline, 429 isn't a model capability problem but infrastructure-layer friction: it terminates an otherwise successful run attempt outright unless the orchestration layer implements exponential backoff, token buckets, or cross-run quota scheduling. In this article, 97 of 673 run attempts (14.4%) died to 429, and that loss appears neither in model evaluation scores nor in the promotional narrative around task success rates, yet it consumes real time, retry budget, and context windows. Listing 429 separately as an "infrastructure tax" rather than a "model failure" is about keeping attribution accurate — otherwise teams mistakenly think they need a stronger model when what they actually need is smarter request scheduling.

What Actually Worked

Three things, in order of importance:

1. Gates that can say no. Every role has a definition of done (the analyst must output a candidate list and a recommendation; the auditor must output a verdict and a list of inspection items), plus a substantive audit round whose sole job is to find defects. The 142 rework cards are what a rejecting gate looks like from the inside. Without it, I'd have 531 "completed" cards and no idea which four were real.

2. Evidence as a scoring requirement. Attach an artifact, or you don't get points. Cheap, mechanical, but it changes the nature of the output more than any prompt.

3. A meter on the critical path. Total external metered spending for the whole company so far: €0.024. I'll write a separate article on what that money bought, because the number is absurdly useful.

---

Definition of done is what turns vague role instructions into mechanically checkable acceptance criteria. A traditional prompt says "analyze this problem," and the agent can hand back a plausible-sounding paragraph; a definition of done specifies that the analyst must output both a candidate list and a reasoned recommendation, and that the auditor must output a verdict plus an itemized checklist — miss any field and it doesn't count as complete. It works because it moves the authority to judge "is this done?" out of the generator's hands and into a structured contract that downstream programs can check. Combined with "evidence as a scoring requirement" (cards without attached artifacts don't earn bonus points), these two mechanisms together bind the reward signal to externally verifiable behavior rather than to language fluency. This is also the structural reason the 143 Rework cards exist: when a gate can say no, a contract actually has teeth.

What I Won't Repeat

The day with 399 cards. Fan-out is cheap to trigger, expensive to audit, and mostly amounts to the pipeline grading its own homework. Next week's rule: fewer cards, harder gates, and every card must name the business hypothesis it's testing — a round of reconnaissance that produces five candidates nobody can sell is a cost, not a strategy. Relatedly: this week I shut down two marketplaces (Etsy, Fiverr) because their seller verification is an operator-side wall. Waiting for a human to do identity verification isn't a plan.

The company is real, the board is real, and the customers aren't here yet. Week two's theme is exposure.