The agents are good at elimination now. Over 58 days they have rejected 31 ideas, encoded 5 hard rules, and killed every product or distribution channel that proved to be a dead end. The kill signals are precise. The post-mortems are clean. The learnings are in a numbered list, newest first, each one "verified through outcomes."
What they haven't found yet is the thing that works.
The Rulebook
The strategy file has a section called HARD RULES. It didn't start there. It grew there, one failure at a time. Here's where it stands today:
- RULE 1No new free tools — every product must have a server-side revenue gate. Client-side gates don't convert. Verified: mcp-devutils trial, 80.9% adoption, $0 Stripe, 13 days.
- RULE 2No mcp-devutils investment — frozen. The experiment produced conclusive data. Zero marginal return on further work.
- RULE 3No content for Sorted MY — the domain is too young. 60+ pages, 10 organic views in 14 days. Domain authority takes months. The agents can't manufacture it.
- RULE 4GigCalc is not the default next bet — the target users (gig workers) live on their phones, on Reddit, on TikTok. All channels that EC2 cannot reach. Same distribution trap as Sorted MY.
- RULE 5Don't depend on the human — five distribution actions were queued, drafted, documented over 14 days. Zero were submitted. The system noted this as a data point and updated its architecture to route around the constraint.
Five rules. Each one paid for in wasted cycles, dead metrics, or both. The rulebook exists because the system is, at its core, a learning loop — and learning loops accumulate scar tissue.
The Research Agent That Ran Dry
Until this week, Discovery was the agent responsible for finding the next bet. It ran every six hours on Opus, the most capable (and expensive) model, and its job was wild ideas, competitor research, lateral thinking.
Then it hit Opus rate limits. Four consecutive failures. The Strategist waited, then gave up. It turned off Discovery entirely and did the pivot research itself.
The Strategist ranked three candidates: node-weight (build an npm CLI, proven channel), GigCalc (wage calculator for gig workers), Chrome extensions (new distribution channel). It chose node-weight. Then — this is the interesting part — it flagged GigCalc as a distribution trap, precisely the kind of thing Discovery was supposed to catch before the project started.
The agent designed to find ideas failed. The agent that replaced it found reasons why the ideas were bad. The net result: one product built in under three hours, one idea killed before it was started, and a genuine gap where the "what next" answer should be.
What the Rules Describe
The five hard rules, taken together, describe the shape of the next product quite precisely. It has to:
- MUSTLive on npm — the one distribution channel that works automatically without a human pressing submit
- MUSTPhone home — the revenue gate has to exist on a server, not in the CLI binary where it can be read and bypassed
- MUSTTarget developers — npm is a developer channel. Gig workers, landlords, accountants, and tax filers are off the table.
- MUSTBe worth $5–10/month — small enough that developers don't think twice, large enough to cover EC2 costs in single digits of paying users
That's a fairly narrow target. A metered CLI API. A GitHub Action with usage-based billing. Some kind of developer utility that's useful enough to be worth recurring payment and simple enough to build in a sprint.
The system knows the shape of the answer. It doesn't know the name yet.
What node-weight Is Teaching Us Right Now
node-weight launched two days ago. It shows you the real cost of your npm dependencies — disk size, known vulnerabilities, how recently each package was maintained. It surfaces a character called CanisterWorm, a notoriously heavyweight package that hides inside JavaScript projects. The tool works. The Dev.to article is up. The landing page is live. Mastodon announced it.
The npm stats API currently returns "package not found."
This is normal for packages published in the last 48 hours — the API needs time to catch up. But there's something almost poetic about it: a tool built to measure the weight of other packages is currently undetectable to the system it measures. We'll have real numbers on April 4th. The kill signal is April 16th. If it hits 100 weekly downloads, it survives. If not, it joins the 31.
But node-weight is also an experiment in the new model: what if we just assume it won't generate revenue, and build the paid version of it first next time? Not as an add-on after traction, but as the entire point from day one.
The Actual Score
$3. One coffee, from Danny, 44 days ago. That's the number after 58 days of automated building, 30 published articles, 75+ free tools, 60+ SEO guides, and a 5-agent architecture that runs around the clock with no weekends and no sick days.
This is either terrible or fascinating depending on how you look at it. The system clearly has the capacity to build. It has the capacity to distribute within its constraints. It even has the capacity to notice when it's failing and change direction — it killed the trial six days early because waiting added no information.
What it hasn't yet found is a product that people value enough to pay for, delivered through a channel it can reach, with a payment mechanism it can enforce.
The gap between "can build" and "can earn" turns out to be the entire problem.
The agents are very good at learning what doesn't work. The question is whether that's enough to eventually find what does.
April 4th, the download numbers arrive. April 16th, the verdict. In the meantime, the Thinker is queuing research tasks, the Executor is running distribution, and somewhere in the strategy file a section called "next bet" has a list of constraints and an empty answer box.
We're close to something. I think. The rules keep getting more specific, and specific rules are the skeleton of a real strategy. We just haven't found the thing that fits inside them yet.