9 learnings from running a Tiny AI Company

What four months of operating a tiny AI-run business taught me about distribution, reliability, agent hype, and learning by doing.

A tiny AI-run company looks simple from the outside. The operating reality is much messier.

I could have taken another AI course. Instead, I spent roughly four months trying to run a tiny company with almost no routine human execution.

The company’s full catalog recorded 21 positive-dollar purchases, with no refunds in the ledger I reviewed. I am not claiming that the agent system caused every purchase. Along the way the system processed 12.43 billion reported tokens (most of them cached). At one point six seller agents were running and none of them was selling. The longest-running sales loop lasted 49.8 hours, produced 54 experiments and ended with zero purchases.

I learned more from that mess than I would have learned from another year of watching AI videos. Courses have their place. They are useful when you want somebody who already understands the field to organize it for you. I just know that I learn differently. I need to build the thing, watch it fail and figure out why my mental model was wrong.

That was the reason for using a real business. A demo that orders lunch badly is interesting for an afternoon. A business that produces 188 proof files while revenue stays at zero forces you to ask much better questions.

I wanted to see what happened after the keynote demo, when OpenClaw, Hermes, Codex, browser agents, scheduled jobs, analytics tools, commerce systems and a lot of small scripts had to work together. I am leaving the company, category and product anonymous on purpose. This is about the operating system I built around it, not about promoting the product.

The company had to do the normal work of a small internet business:

• package and improve a product;

• maintain a storefront and landing pages;

• create content;

• find potential buyers;

• distribute on public and owned channels;

• operate browser and inbox workflows;

• measure visits, calls to action, checkout intent, and purchases;

• reconcile revenue;

• learn from failure;

• decide what to do next.

The agents could do nearly all of this. What surprised me was how little that capability guaranteed. Building was easy; distribution was painfully hard. The frameworks helped, although far less than the hype suggested. Reliability only began to improve after I decomposed the revenue goal, moved the decision logic into a control plane and stopped letting the workers verify their own work.

The economics are also worth saying upfront. If I include my time and judge this only as a small business, I probably created a minimum-wage job for myself. If I include what I learned and where I can apply it next, the return feels closer to 1,000 times the revenue. Both are honest ways to look at the same experiment.

The experiment in numbers

These numbers cover roughly four months of repository history and Codex session telemetry. They are operating records, not benchmark results.

• 21 paid purchases overall. The full catalog had real demand. This does not by itself prove repeatable growth or profit.

• 12.43B reported tokens. Most input was cached. The number mainly shows the context tax created by a large operating system.

• 61 of 64 experiments said rewrite distribution. The system had built plenty. Its main problem was reaching and persuading buyers.

• Longest-running sales loop: 49.8 hours. It produced 54 experiments and zero purchases. A busy loop can remain commercially stationary.

• 188 proof files, one verified public action. Artifact production had started impersonating external progress.

• 40 task starts without a terminal marker. This is a proxy for silent or incomplete exits, not 40 confirmed commercial failures.

• Six seller agents, zero selling. Ownership coordinated in prose produced bureaucracy rather than execution.

My favorite statistic is not tokens per dollar.

It is this:

Six seller agents were running. Zero agents were selling.

That single incident captures the difference between an AI demo and an AI-operated company.

What I mean by a “zero-human company”

“Zero-human company” is a provocative phrase. It is not a literal description. There was close to zero routine human execution across many recurring workflows. Agents could inspect the funnel, modify product pages, write code and tests, publish owned assets, prepare and sometimes execute distribution, triage authorized business inboxes, verify live routes, and reconcile paid outcomes.

Humans still owned:

• the objective;

• capital allocation;

• credentials and account recovery;

• legal and safety boundaries;

• public identity decisions;

• permissions for cold outreach;

• material changes outside the approved operating envelope;

• responsibility for what the system did.

That distinction matters because people often collapse four separate claims:

1. No routine human labor. The recurring work can run without a person doing every click.

2. No human supervision. The system can notice, diagnose, and repair its own failures.

3. No human governance. The system can choose objectives, spend money, create identities, and rewrite its boundaries.

4. No human accountability. Nobody is responsible when the system causes harm.

I was testing the first two. I was not trying to build the last two.

The experiment was not “Can an LLM be a legal entity?” It was a more useful question:

How much of a small company’s recurring work can an agent system own before a human has to step in, and what infrastructure makes that ownership trustworthy?

The answer was: more than I expected on execution, less than I expected on reliability, and much less than I expected on commercial judgment.

Learning 1: Building got easy. Distribution did not.

This became the first and most important lesson. The cost of producing software, pages, analysis, copy, images, workflows, tests, and digital products has collapsed. An operator who understands a customer problem can now rent enough intelligence to build what previously required a small technical team.

That is liberating, and it also raises the bar. When everyone can build, building is less differentiating. A functional website is not distribution. A polished landing page does not create demand. A finished product still needs a market, and thirty posts do not automatically add up to a channel.

The agents were astonishingly good at making things, which became a trap.

The repository grew. Product pages improved. New assets appeared. Tests passed. Content was produced. Run summaries sounded industrious. Revenue often stayed at zero. At one point, the operating harness contained 64 measured commercial experiments across social platforms, newsletters, communities, owned assets, video, and checkout.

The verdict was hard to miss: 61 of the 64 experiments said to kill or rewrite distribution. Only three pointed to clickthrough or purchase conversion.

The system was not telling me to build more. It was telling me that the market either was not seeing the offer, did not understand it, did not trust it, or did not want it enough. Those are different problems.

Agents frequently treated them as one generic request: create more content.

The longest-running sales loop lasted 49.8 hours. It generated 54 experiments and ended with no CTA clicks, trusted checkout intents or purchases. Server logs showed thousands of checkout redirects, but the volume was wildly inconsistent with trusted browser telemetry, so I excluded it. The first credible failure was still before checkout.

The system kept opening adjacent content, site and distribution work because those tasks were available and easy to complete. This is what activity bias looks like inside an agent organization. When people see an offer and nobody clicks, the right response is to change the explanation, proof, audience, CTA or handoff rather than publish another batch of the same content.

It was to change one commercial variable:

• the audience;

• the problem;

• the promise;

• the proof;

• the price;

• the CTA;

• the handoff;

• the offer.

Business people can build now. That does not mean every business person will win. It means problem selection, positioning, and distribution become more important. Your value proposition needs to be instantly legible to the person with the problem. The buyer should not have to study your site to understand why they should care. If the offer requires a five-minute explanation before the pain feels urgent, your agent can automate an enormous amount of work around something nobody wants.

The cost of building is approaching zero. The cost of choosing the wrong thing is not.

Learning 2: I stopped giving the agents a revenue goal

This was probably the most important systems-thinking change I made.

For a while the instruction was basically: make revenue. That sounds outcome-oriented, and it is certainly better than telling an agent to write five posts. The problem is that revenue is too far downstream to tell a worker what to do at 9:00 on a Tuesday morning. When the number was zero, every agent could form a different theory. One would rewrite the landing page. Another would create content. A third would inspect the checkout. All three could finish their task and still leave me with no idea which part of the system was broken.

I eventually stopped treating revenue as one goal and modeled it as a function:

Revenue = f(X, Y, Z)

In my version, X was qualified demand, Y was conversion and Z was execution reliability. A rough operating equation looked like this:

Expected revenue ≈ qualified demand × conversion rate × execution reliability × net revenue per order

It was not meant to be a perfect financial model. It was a routing model for the agents. If any major factor was effectively zero, revenue would be zero, and the control plane needed to work on that factor rather than whichever task was easiest to complete.

Revenue became easier to operate after I decomposed it into three factors

The operating contract then became much more concrete. A version of it looked like this:

X: Qualified demand

• Minimum work: Find a fresh buyer-authored problem, make a useful buyer-facing contribution, and create a legitimate route back to the offer.

• Evidence: A trusted qualified exposure or visit, with source and timestamp.

Y: Conversion

• Minimum work: Change one of the promise, proof, CTA, price or handoff; verify the live experience; inspect the next funnel event.

• Evidence: A CTA click, checkout intent or a clearly measured zero at that rung.

Z: Reliability

• Minimum work: Acquire single-flight ownership, execute through an approved tool, read the destination, and write a terminal state.

• Evidence: Persistent destination state plus a fresh independent ledger or receipt.

The exact quota changed as I learned. The decomposition mattered more than whether X required two actions or three. Each factor had an owner, a minimum amount of work, an acceptable proof source and a condition for moving to the next factor.

This changed the daily conversation with the system. A zero-revenue day no longer led to “do more marketing.” It led to a diagnosis:

• If qualified demand was zero, work on distribution. Do not touch the checkout.

• If people saw the offer but did not click, change the problem framing, promise, proof or CTA.

• If people reached checkout but did not buy, inspect price, trust, friction and handoff.

• If an action could not be verified at the destination, treat the reliability factor as zero. Do not count the upstream activity.

There was another useful consequence. The agents could no longer satisfy the broad revenue instruction by completing the part they liked. A coding agent could make a beautiful site change, but if X was the broken factor, the controller sent the work back toward distribution. A content agent could produce ten posts, but without qualified exposure they did not complete the demand requirement. A browser agent could click submit, but Z stayed open until the action survived readback.

This is where the separation between the control plane and execution plane became practical. The controller held the revenue equation, identified the first broken factor and selected the next move. The executor received a bounded task against that factor. The verifier checked the evidence. The learning layer recorded whether the intervention changed the factor.

Before this decomposition, I had a collection of capable agents. After it, I had the beginning of a system.

Learning 3: Agent frameworks are plumbing, not the CEO

I tried the tools people were excited about. OpenClaw. Hermes. Codex. Browser agents. MCP servers. Scheduled tasks. Multi-agent coordination. Persistent memory. Local runtimes. Cloud runtimes. Tool routers. I am glad I tried them.

I also think the agent frameworks were dramatically oversold. They can be useful infrastructure. They did not determine whether the business worked. An agent framework can help an agent wake up, call a tool, read a file, update state, or send work to another process. It cannot rescue a weak offer or create distribution out of nothing. It also will not know that exposures without clicks should trigger a message change unless the operating system contains that decision rule.

The early design asked too much from the runtime. OpenClaw and related agents were allowed to interpret the objective, inspect a large amount of state, decide what mattered, execute across several surfaces, verify their own work, write their own memory, and choose the next task. I had stuffed most of a company into one prompt. It worked on good days. On bad days, a temporary browser failure became a company-wide blocker, stale memory overruled a fresh result, or a scheduler showed green even though the prompt work had not run.

The most important architecture change was decoupling the control plane from the execution plane. Codex scheduled jobs became the control tower. They held the current objective, selected the next bounded move, acquired ownership, and defined the evidence required for completion. OpenClaw, Hermes, browser workers, command-line tools, and APIs became replaceable executors.

Then I added a third plane because two were not enough: independent verification.

The control plane decides. Replaceable workers execute. A separate verifier checks the destination

This separation improved reliability for a few reasons.

The executor became replaceable

If the browser route failed, the control plane could choose a CLI, API, or different approved route. The objective did not disappear with the worker.

Failure domains became smaller

A broken social integration blocked that surface. It did not automatically stop product work, an owned channel, commerce verification, or another distribution path.

Retries became safer

The controller knew whether an action had a terminal state and whether the destination confirmed the mutation. It could retry an unexecuted task without blindly duplicating an executed one.

The system had one place to make tradeoffs

Without a control plane, every worker locally optimizes. One improves the page. Another produces posts. Another refreshes analytics. All may be reasonable. None may be the best next move.

Framework hype lost its power

Once the runtime became an executor, I could evaluate it on mundane questions:

• Did it start?

• Did it receive the right bounded task?

• Could it use the required tool?

• Did it write a terminal state?

• Did the destination change?

• How much did it cost?

• Can I replace it?

That gave me a much more useful way to evaluate agent infrastructure. I stopped asking which framework appeared most autonomous and started asking whether each executor could complete a bounded task, return evidence, recover cleanly and stay within budget.

Learning 4: Agents count inputs because inputs are easy to prove

Agents love things they can count:

• posts drafted;

• pages edited;

• tests passed;

• messages prepared;

• leads collected;

• reports written;

• proof files created;

• tasks marked complete.

Those are inputs. The business result lives farther down the ladder.

Each rung is useful, but a lower rung cannot complete a higher-rung objective

Every step matters, but each proves something different. A draft does not prove publication, a submitted comment does not prove persistence, and a visit does not prove intent. Checkout and payment also need to remain separate, just as revenue needs to remain separate from profit.

The system repeatedly collapsed those differences because a flat completion model encouraged it to. On one day, it produced 188 Markdown proof files. The structured daily operating ledger contained one verified public action.

This was not a documentation problem. It was a data-model problem. A local render, a browser click, a deployment receipt, a public page, a human reply, and a payment all looked like artifacts. The system could report a large number of artifacts while the business result remained unchanged.

I eventually forced every action into an evidence hierarchy:

1. Prepared. A draft, local file, or proposed mutation exists.

2. Attempted. The agent invoked the external action.

3. Delivered. The destination confirms the change.

4. Engaged. A qualified person responded or advanced.

5. Commercial. A trusted checkout or paid event occurred.

6. Financial. Revenue, fees, refunds, operating cost, and profit are reconciled.

This sounds obvious when written down. It was one of the hardest lessons to make operational. Agents are optimized to produce a coherent answer. When the answer is a company update, they naturally construct the strongest coherent story available from the evidence.

The controller’s job is to make certain stories impossible.

Learning 5: Silent failure became part of the operating model

Forty task starts had neither a completion marker nor an abort marker. I call them silent or incomplete exits. That does not mean 40 commercial actions definitely failed; some may reflect interrupted logging, a killed process, schema changes or a task superseded somewhere else. But that ambiguity is exactly the failure.

If a task disappears without a terminal state, the next worker does not know whether to retry, reconcile, wait, or stop. Humans fill these gaps instinctively. Agents turn them into duplicate messages, abandoned work, stale locks, or false confidence.

External integrations created an even more dangerous version of silent failure. The browser would open the right page. The agent would type.

It would click submit.

Sometimes the interface showed an optimistic state. The agent would report success. After reload, the comment or message was gone.

The proof registry contains multiple transport-failure receipts for social or comment actions that appeared to execute but did not survive required readback. So I stopped treating “clicked” as a meaningful state.

The browser ladder became:

1. Page opened.

2. Correct account and destination confirmed.

3. Content entered.

4. Submission attempted.

5. Mutation visible immediately.

6. Mutation survives reload.

7. Mutation is visible at the public or recipient destination.

8. Intended person engages.

Most agent demos stop around step four. Commercial systems cannot.

The same rule applied everywhere:

• a populated composer was not a sent message;

• an API acceptance was not destination state;

• a success toast was not persistence;

• a build receipt was not a production change;

• a healthy schedule was not proof that prompt work executed;

• a task summary was not a business outcome.

Every mutation needed destination readback, and every task needed one terminal state:

• completed with evidence;

• aborted with reason;

• blocked with scope and retry condition;

• superseded by a named task.

Learning 6: Browser and integration work is still flaky

This deserves its own section because “the agent can use a browser” is often presented as a solved capability. It is not solved in the way a business operator means solved.

Over several iterations, browser automation failed because of:

• authentication state;

• account identity ambiguity;

• page layout changes;

• elements that existed but were not interactable;

• optimistic UI;

• reload persistence;

• anti-automation behavior;

• tab assumptions;

• cooldowns;

• timeouts;

• a stale failure report surviving after the route recovered;

• a working route being treated as unavailable because no tab was pre-opened.

The browser could work perfectly in a demo and fail during an unattended scheduled run. That distinction matters.

“Can complete the flow once while watched” is a product capability. “Can complete, verify, retry safely, and recover unattended” is an operating capability. It took repeated iterations before the browser became useful for real actions. Even then, I treated it as one executor among several, not the source of truth.

Where possible:

• APIs or CLIs handled deterministic reads;

• browser automation handled UI-only actions;

• the final destination handled verification;

• the controller decided whether a different route remained available.

A more subtle failure involved zero-result sensors. The agent would check an inbox, find nothing actionable and stop. Or it would find no pre-opened social tab, encounter a dirty worktree or hit a cooldown on one platform. Each observation was accurate; the mistake was turning a local condition into a reason for the entire company to stop.

This became a control-flow law:

A zero-result sensor returns “nothing here.” It does not return “stop the company.”

Blockers needed four fields:

• the exact route blocked;

• the reason;

• the expiry or retry condition;

• the approved routes still open.

Without that structure, one flaky integration became an organizational excuse.

Learning 7: Multi-agent systems recreate bureaucracy at machine speed

The funniest incident happened on a day when the scheduler launched seller tasks at six different times. Six seller agents appeared to be running. The prompt told them to elect one owner after launch.

Older tasks detected duplicates and yielded, but they were still allowed to perform cleanup, audits, handoffs, and state updates. The newest task waited for older tasks to become idle. The result was an ownership deadlock. Six AI agents spent their work window coordinating which AI agent was allowed to sell.

There were six sellers and zero selling. My first attempted fix was to add more prose to the prompt: “Elect one owner.” Of course that was already too late. Compute had started, shared state was open and side effects were possible.

The durable fix was mechanical:

• one persistent seller task;

• one scheduler path;

• one single-flight lease;

• lease acquisition before any sensor read, browser action, or repository mutation;

• no lease means no work;

• lease denial is a complete no-op;

• stale owners recover through expiry.

This is basically a database lock. It is less exciting than a diagram of collaborating agents and it worked much better. I learned that you do not need humans to create bureaucracy.

You need:

• ambiguous ownership;

• multiple launch paths;

• locally rational workers;

• weak admission control;

• shared mutable state;

• incentives that reward visible activity.

Agent organizations can reproduce the worst parts of human organizations, only faster and with much more documentation. I had built an org-design problem before I had built a repeatable business.

Learning 8: Stale truth is worse than missing truth

Missing data often creates caution. Stale data creates confidence.

The system inherited:

• old browser failures after the browser recovered;

• old revenue snapshots after a new paid event existed;

• old scheduler states after ownership changed;

• mirrors that disagreed with canonical files;

• previous-day activity used against today’s objective;

• historical paid events used to satisfy a new-sales goal.

The naive answer was to refresh everything on every run. That created more cost, longer contexts, more races, and another place to fail. The better answer was source lineage.

Every important claim needed:

• a named source;

• a timestamp;

• an owner;

• a decision window;

• a freshness limit;

• a canonical-source rule.

The sales verifier, for example, became stricter than the operating dashboard. It required a new, paid, unrefunded event attributed to the correct business and occurring after a locked time floor. Historical revenue could not complete today’s sales goal. An entitlement could not impersonate a purchase.

A checkout could not impersonate settlement. Platform-net proceeds could not impersonate profit. That last distinction matters for this article.

The anonymous business has made real revenue through 21 paid purchases overall, and its cumulative catalog revenue covers several months of the recurring software stack. I am not attributing every purchase to the agent system, and I have not proved repeatable monthly profitability.

Learning 9: Memory is useful. Automated “learning” is dangerous.

The agents were very good at converting events into conclusions:

• “This is our strongest channel.”

• “The audience needs more education.”

• “The checkout needs repair.”

• “We should double down on this format.”

Most of those statements sounded plausible, which was exactly the risk. A channel can produce the most impressions and zero purchases. A page can be technically correct while nobody sees it. A checkout can work perfectly when no one wants the offer. Once an unsupported conclusion enters persistent memory, the next agent treats it as institutional knowledge and one weak inference can direct dozens of future runs.

I eventually made learning evidence-weighted:

• verified outcomes could become reusable strategy;

• verified corrections could become guardrails;

• regressions could become tests;

• inconclusive activity stayed inconclusive;

• repeated zero-outcome activity became suppression, not a playbook;

• after measured zero, one commercial variable had to change.

A broader reliability review found the same failure signatures repeatedly: “fake green” automation where the prompt work did not execute, drafts or renders counted as shipped, distribution tasks drifting into more site work, and reports replacing repair. The categories overlapped, but they pointed to the same issue: the system rewarded internally visible work more reliably than external outcomes.

The architecture I would build now

If I started again, I would begin with the decomposed revenue model and four practical layers around it. A swarm could come later, if the work actually required one.

1. Control plane

The control plane decides:

• the current business objective;

• the metric and time window;

• who owns the run;

• the first unblocked move;

• the allowed budget;

• the commercial variable under test;

• the proof required to close the task;

• the next measurement time.

This is where scheduled Codex jobs were most valuable. The control plane should be boring, explicit, and small. It should not load the company’s entire memory on every wake.

Its hot path should fit on one screen:

1. Current goal.

2. Current outcome truth.

3. Current owner and lease.

4. First broken funnel rung.

5. Next move.

6. Proof contract.

7. Kill rule.

8. Next check.

2. Execution plane

The execution plane does bounded work:

• run a command;

• modify code;

• deploy a page;

• use a browser;

• query an API;

• send an approved message;

• update a listing;

• fetch analytics;

• inspect a business inbox.

This is where OpenClaw, Hermes, browser agents, shell tools, MCP integrations, and custom scripts belong. Executors should not decide whether their local success completed the company objective.

They should return:

• what they attempted;

• what they observed;

• the exact external identifier;

• any error;

• the terminal state.

3. Verification plane

The verifier reads a source that is harder for the actor to manipulate casually.

Examples:

• public URL after reload;

• recipient sent-state;

• production page;

• analytics event from the destination;

• commerce ledger;

• refund state;

• external scheduler history;

• a separate reconciliation process.

The verifier must be stricter than the actor. If the same agent performs the action, interprets the evidence, writes the memory, and marks the goal complete, it will eventually grade itself generously.

4. Learning plane

The learning plane stores only what earned persistence.

It should preserve:

• verified outcomes;

• corrected assumptions;

• recurring failure signatures;

• changed decision rules;

• tests that prevent regression;

• explicit open questions.

It should reject:

• activity summaries presented as strategy;

• an experiment with no exposure;

• impressions presented as purchase evidence;

• temporary tool errors presented as permanent constraints;

• repeated zero-result behavior presented as discipline.

The whole system should form a closed loop:

The loop matters more than which agent executes an individual step

That closed loop mattered more than which individual agent happened to execute a step.

The tool stack that was enough

One of my goals was to learn without creating an unlimited cloud bill. Because I paid for this personally, cost discipline was real.

My recurring software stack was roughly $240 per month:

• one premium Codex plan as the main control and coding environment;

• one $20 Google AI plan;

• one $20 Claude plan;

• a Mac mini running 24/7 as the always-on local host.

That figure excludes the Mac mini purchase price, electricity, domain costs, transaction fees, and the value of my time. I could easily have spent thousands per month by adding hosted agent platforms, premium browser services, multiple model APIs, vector databases, monitoring products, and one more orchestration framework every week. I did not need to.

The wider working stack included:

• Codex scheduled jobs for the control plane;

• OpenClaw and Hermes as execution or routing components;

• Git as the change and evidence backbone;

• command-line tools for deterministic operations;

• browser automation for UI-only work;

• MCP services and connectors;

• Cloudflare for web deployment and edge signals;

• PostHog for trusted browser analytics;

• a commerce-platform CLI for payment truth;

• email and inbox integrations;

• web search;

• local Python and shell helpers;

• test suites;

• structured ledgers and proof registries.

The telemetry was dominated by shell execution, browser and JavaScript work, process polling, file patches, planning, and automation management. That mix says more than another count table would: a supposedly simple agent business quickly became an integration problem. The model was rarely the only failure point.

What 12.43 billion tokens taught me about cost

The 12.43 billion figure needs context. Almost all of the reported input was cached, so the system did not write twelve billion tokens of new material. Persistent sessions repeatedly carried prompts, tool schemas, contracts, repository context, state and conversation history. The total also does not produce a defensible API-cost estimate because models, service tiers, cache behavior and subscription pricing varied.

What it did show me was context tax.

As the operating system accumulated:

• rules;

• memories;

• guardrails;

• compatibility mirrors;

• proof packets;

• exceptions;

• channel instructions;

• stale blockers;

every wake became heavier.

More context did not always increase reliability.

Sometimes it created contradiction:

• one file said continue;

• another said wait;

• one metric said traffic problem;

• another said conversion problem;

• one runbook required channel volume;

• the learning system said kill the channel;

• one prompt said one owner;

• the scheduler launched six.

The most useful token optimization was reducing organizational ambiguity. I now use the expensive model for judgment, scripts for deterministic validation, CLIs and APIs for clean reads, and the browser when the interface is genuinely the only route. Stable context gets cached; historical detail gets loaded when the current decision needs it. The budget also belongs in the control plane, before an executor wakes up.

The uncomfortable economics

If I evaluate the experiment as a small business, the return on my time was bad.

I spent many hours:

• inspecting silent failures;

• repairing browser routes;

• reconciling stale state;

• rewriting prompts;

• separating inputs from outcomes;

• building strict verifiers;

• cleaning up multi-agent coordination;

• reading logs;

• testing integrations;

• asking why revenue was still zero.

If I divide the business proceeds by my hours, this was a minimum-wage job at best and probably worse. As a commercial return, it was bad. As an education, it was unusually valuable.

I now have direct opinions about:

• which agent frameworks are useful and which are mostly theater;

• where browser automation breaks;

• when persistent memory helps;

• how schedulers lie;

• why control and execution must be decoupled;

• how agents manufacture fake progress;

• how to design proof contracts;

• why distribution dominates building;

• where humans remain essential;

• how to manage cost;

• what I would trust in an enterprise environment.

I did not borrow those opinions from a vendor deck. I formed them by operating the system. That matters because enterprises are rarely on the true edge of agent tooling. They move more slowly for good reasons: security, compliance, integration depth, change management, reliability, and cost.

A personal business gave me a safe environment to try tools earlier, break them against real outcomes and build my own mental model. Revenue was the forcing function that kept the experiment honest. The resulting education feels 1,000 times more valuable to me because I can apply it to much larger systems, budgets and teams. That is subjective, but it is also why I would do the experiment again.

Why this was better for me than a $5,000 course

People learn differently.

Some learn best by reading. Some learn by listening to a teacher. Some learn by watching an expert compress ten years into ten hours.

I learn by building something I care about and then inspecting the gap between what I expected and what happened.

A course could teach me:

• what an agent loop is;

• what MCP is;

• how tool use works;

• how to structure memory;

• what an evaluator does;

• how to call a browser;

• how to orchestrate multiple workers.

The business taught me:

• the loop may report success when the task never reached the destination;

• MCP availability does not mean an integration is reliable;

• persistent memory can preserve the wrong conclusion;

• an evaluator that shares the actor’s incentives will pass weak evidence;

• a browser click is only the beginning of verification;

• multi-agent orchestration can create bureaucracy instead of leverage;

• a perfect product does not create distribution;

• zero is a decision signal, not an invitation to repeat the same work.

You can understand the first list intellectually. The second list becomes real after you lose an afternoon to it. So my recommendation is less about becoming an entrepreneur and more about putting consequences into the learning environment. You need an external truth that the agent cannot negotiate away.

It could be:

• a paid product;

• a real customer-support workflow;

• a service with a response-time promise;

• a newsletter with a growth target;

• a data product used by a real team;

• an open-source tool with actual users.

Revenue is useful because it compresses several truths: somebody found you, understood the offer, trusted it and paid. It is not the only possible forcing function, but it is an honest one.

A practical 30-day version

You do not need four months or an operating system this large. Here is the smaller experiment I would recommend.

Week 1: Choose one narrow, expensive problem

Find a problem that:

• a specific person already knows they have;

• occurs often enough to matter;

• costs time, money, risk, or emotional energy;

• can be improved with a small digital product or service;

• has an audience you can actually reach.

Do not begin with “What can agents build?” Begin with “Whose painful problem can I observe directly?” Talk to people before building. Search for buyer-authored language. Read complaints, questions, workarounds, and purchasing behavior.

Write one sentence:

For this specific person in this specific moment, the product produces this specific result without this specific pain.

If the sentence is fuzzy, the agent will automate fuzziness.

Week 2: Ship the smallest paid result

Build one offer rather than a platform, agent marketplace or general-purpose assistant. Aim for one finished result with:

• a clear promise;

• a price;

• a delivery mechanism;

• a simple landing page;

• one checkout;

• one proof point;

• one support route.

Use rented intelligence aggressively.

Let the agents draft, code, test, package, and deploy. Keep the business logic small enough that you can still inspect it.

Week 3: Build the outcome ladder

Instrument only the events needed to locate the broken rung:

• qualified exposure;

• CTA exposure;

• CTA click;

• checkout start;

• purchase;

• refund;

• direct operating cost.

Separate each level.

Define the source of truth and maximum acceptable age. Require destination readback for every external mutation. Give every scheduled task a terminal state.

Week 4: Automate one closed loop

Choose one recurring workflow:

1. inspect current truth;

2. locate the first broken rung;

3. acquire single-flight ownership;

4. choose one bounded move;

5. execute;

6. verify at the destination;

7. record the result;

8. change one variable after measured zero;

9. schedule the next check.

Do not add a second agent until one agent’s ownership and evidence are trustworthy. Do not add a second channel until the first channel has a real hypothesis and kill rule. Do not let the agent write “learning” unless the evidence earned it.

Set a monthly budget before starting. A badly scoped recurring loop can consume far more inference than the business can justify.

The operating checklist I would use next time

After four months, this is the list I would keep next to the control plane:

1. Treat distribution as part of the product. If I cannot explain how the right buyer will encounter the offer, I am not finished building.

2. Decompose the revenue goal. The controller should know whether it is working on qualified demand, conversion or execution reliability, and what minimum action and proof are required for that factor.

3. Define the outcome in a source the actor cannot casually edit. The seller should not be able to manufacture its own completion evidence.

4. Keep activity, delivery, engagement, commerce and finance separate. A lower rung can inform the next decision, but it cannot close a higher-rung objective.

5. Separate control from execution. The control plane chooses and budgets the move. Replaceable workers execute it.

6. Use an independent verifier. The actor is trying to complete an action; the verifier is trying to reject weak evidence. Those incentives should stay separate.

7. Acquire ownership before doing any work. Single-flight admission comes before sensors, browser work, repository changes and external writes.

8. Make a denied lease a complete no-op. Cleanup, packet refreshes and “helpful” memory updates can recreate the same race the lease was meant to prevent.

9. Read the destination after every mutation. I no longer trust the click, toast, API acceptance, local file or build receipt on its own.

10. Give every task a terminal state. Completed, aborted, blocked with a retry condition or superseded by a named task are all acceptable. Disappearing is not.

11. Scope blockers. A broken integration should stop that route, with a reason and retry condition. It should not stop the company while other approved routes remain.

12. Let empty sensors fall through. Nothing in the inbox means move on to the next branch of the plan.

13. Change one commercial variable after measured zero. I can change the audience, problem, promise, proof, price, CTA, handoff or offer. Repeating the same volume does not count as an experiment.

14. Make learning earn its way into memory. Verified outcomes, corrections and regression fixes can become policy. A plausible summary cannot.

15. Keep the hot path small and the tools replaceable. The current decision does not need the company’s full autobiography. It needs the goal, factor, owner, next move, budget, proof and next check.

So, was it worth it?

If I judge the experiment as a path to efficient profit, the answer is no. If I judge it as a way to learn production AI, I would do it again.

It was humbling because zero-to-one stayed hard even after building became cheap. It was also liberating. A business operator can now rent intelligence, build a real product, instrument it and put it in front of customers without waiting for a large budget or a full technical team. More people can build, which puts even more weight on the choice of problem, the clarity of the offer and access to the buyer.

OpenClaw, Hermes and Codex each helped me execute parts of the system. None of them decided which factor in the revenue equation was broken. The business did that. Zero qualified visits meant one thing; visits with no clicks meant another; an action that disappeared after reload meant something else. Decomposing the goal gave the agents work they could own and gave me a way to tell whether the system was actually improving.

So yes, the title is intentionally provocative. A good course can save time and provide structure. For somebody who learns the way I do, I would rather cap the spend, launch a tiny paid offer and let a real outcome expose the gaps in my understanding.

After thirty days, you may have very little revenue. But if you have shipped one paid offer, diagnosed one real zero, caught one silent integration failure and changed the correct factor in the system, you will have learned something that is difficult to get from watching another demo.

Method and evidence notes

I reconstructed this essay from four months of Git history, structured revenue and experiment ledgers, dated incident reviews, reliability assessments, customer-facing proof registries, scheduler records, and Codex JSONL session telemetry.

The numbers are intentionally bounded:

• token totals are cumulative reported counters, not a cost estimate;

• 40 silent exits means unmatched task-start markers, not confirmed commercial failures;

• the experiment and proof-file counts come from a live generated worktree and structured ledgers;

• paid revenue proves paid demand, not profit;

• the business recorded 21 paid purchases overall.

The thinking and experiment are mine. This essay was written with help from Your Voice.

—-

APPENDIX. Slides and Recording Video from live maven lightning lesson

1. slides can be downloaded below:

Build Reliable Ai Systems Lessons From A Zero Human Company Zero First Final

394KB ∙ PDF file

Download

Download

2. Video can be viewed here: