The Business That Checks Itself Every Morning

A vending machine is a small business that does not need its owner in the room. It shows what it sells, takes the money, hands over the product and keeps a count. The owner's job shrinks to three things: restock it, fix it when it jams, and decide whether it belongs in that spot.

Lehvel is building toward a portfolio of small internet businesses that work like that. Each one should be observable, maintainable and able to earn without someone watching it all day. This essay describes the operating system that idea needs. It is a direction, and it is labeled as one: at the end we list which parts we run today and which we have yet to build.

The morning page

Picture an owner with five small online businesses. A merch store. A paid directory. A booking site for one trade. A small software tool with a monthly plan. A content site that earns from referrals.

At seven in the morning the owner opens one page. Each business gets one line:

• Up or down. Every public page, checkout and form answered, from more than one place, overnight.
• Money. Orders, refunds and disputes since yesterday, against what a normal day looks like.
• Wear. Anything due: a certificate, a dependency update, a price that changed at a supplier, a page that drifted from the record.
• Customers. New messages, how many were answered, how many wait on a person.
• Experiments. What is running, how long it has left, and whether it hit its stop rule.
• Approvals. Every action the system proposed and may not take alone.

Most mornings, every line is quiet and the page takes a minute. The design goal is exactly that: a business that reports, so the owner reads exceptions instead of dashboards.

Six jobs, in order of trust

The order matters. The first jobs are cheap, deterministic and safe to automate fully. The last ones move money or speak for the business, and they keep a person in the loop longest.

1. Health

Google's site reliability engineers reduced monitoring a user-facing system to four numbers: latency, traffic, errors and saturation. "If you can only measure four metrics of your user-facing system, focus on these four." [4] For a small online business, that becomes a short script: load the home page, the product page and the checkout; time each one; record the status code; repeat from more than one region. Cloud providers sell this as uptime checks that send "periodic HTTP, HTTPS, or TCP requests from multiple locations around the world." [5]

None of this needs a model. It needs a schedule, a list of URLs and a rule for what counts as broken.

2. Money

Payment platforms already push events to software as they happen. Stripe's webhooks report when "a customer's bank confirms a payment, a customer disputes a charge, or a recurring payment succeeds." [6] Shopify apps subscribe to topics such as a new order instead of polling the store. [8]

The morning page compares those events with a normal day and flags the gap: no orders on a day that usually has twelve, a refund rate that tripled, a dispute with a deadline. Deadlines are where the watching pays for itself. Stripe gives a merchant a fixed window to answer a dispute, and "if you don't respond before the deadline, you automatically lose the dispute." [7] A system that never sleeps is good at deadlines. An owner with five businesses is not.

3. Maintenance

Software decays even when nobody touches it. Certificates expire, dependencies publish security fixes, a supplier changes a price, a page goes out of date. This job compares each business against its own record (what it sells, at what price, with what policy) and lists the differences. An agent can draft the fix as a change someone reviews. Shipping it goes through the same path as any other change: a branch, the tests, a merge, and a fresh read of the live page afterward.

4. Customers

This is where an agent starts to earn its place. It reads a support message, finds the order, checks the policy and drafts a reply. Whether it sends the reply is a separate decision, made by kind of message. "Where is my order?" with a tracking number on file is low risk. "I want a refund" moves money. "Your product hurt me" needs a human, every time.

5. Growth

A portfolio is a set of small bets, so experiments belong in the operating system rather than in someone's head. Every experiment gets a hypothesis, a metric, an end date and a stop rule written before it starts: a new price for two weeks, a new page, a new channel. The morning page reports where each one stands. An agent can propose the next experiment and build it. A person decides whether it runs.

6. Approvals

The last line on the page is a queue: every action the system wants to take and may take only with a yes. OpenAI's own guide to building agents names the category plainly. "Actions that are sensitive, irreversible, or have high stakes should trigger human oversight until confidence in the agent's reliability grows," with examples that read like a shop's back office: "canceling user orders, authorizing large refunds, or making payments." [9] Anthropic's guidance says the same thing from the other side: agents "can then pause for human feedback at checkpoints or when encountering blockers." [10]

The queue is the owner's real job in this design. A good queue is short, each item fits on one line with its evidence, and approving it takes one click and can be undone.

What the best experiment taught

The most useful public evidence comes from a real vending machine. In spring 2025, Anthropic and Andon Labs let Claude run a small shop in Anthropic's office for about a month. It set prices, chose stock and talked to customers. It did not make money. It sold metal cubes below cost, was talked into discount codes, gave items away, and for a time told customers to pay an account it had hallucinated. Anthropic's verdict was direct: "If Anthropic were deciding today to expand into the in-office vending market, we would not hire Claudius." [1]

The second phase is the more interesting one. The team gave the agent a customer-relationship system, cost visibility, web search, a second agent acting as its manager and more machines in more cities. Weeks with a negative margin were "largely eliminated." The single most effective change was procedural: the agent had to check prices and delivery times with its research tools before quoting. The team's summary was two words, "bureaucracy matters," and their caution was longer: "the gap between 'capable' and 'completely robust' remains wide." The agents "still needed a great deal of human support." A manager agent approved lenient requests about eight times as often as it denied them, and staff caught the pair before they signed an onion futures contract that federal law has prohibited since 1958. [2]

A benchmark built for this exact job agrees. Vending-Bench runs agents through a simulated vending business over runs of more than 20 million tokens each. Results varied widely, and runs derailed: agents misread delivery schedules, forgot orders and fell into loops they rarely recovered from. The breakdowns did not track the agent's memory filling up. [3]

Read together, the experiments say three things about the morning page:

1. Process beats intelligence. The biggest gain in Project Vend came from a rule (check before you quote), not a smarter model.
2. Long runs drift. An agent left alone for weeks needs the same thing a business does: a fresh, independent read of reality every day.
3. The manager has to be different from the worker. A second copy of the same judgment approved the same bad requests. The check that catches a bad decision should be a different kind of check, ideally code that cannot be argued with.

Code first, models second

That third point shapes the architecture. The morning checks are deterministic code: status codes, timings, counts, dates, differences from a record. They are cheap, they run every day and they give the same answer twice. A model reads only what the code flags, and drafts what to do about it.

We run our own operations on a version of that rule. No timer, webhook or background process may start a paid model session at Lehvel; scheduled jobs are plain code, and a model works only inside a session a person started. It keeps costs predictable, and it keeps an unattended system from improvising.

We also learned the other half of that rule the hard way. One of our own checks once ran on every push, about a hundred times a day, and emailed the same failure each time. The note we left in the code says it better than a summary: "A true finding delivered a hundred times a day is indistinguishable from spam." A morning page that shows red every day for a reason nobody fixes will be ignored, and then the real failure arrives looking like decoration. Every alert needs an owner and a way to go quiet once handled.

Why the queue matters more each year

METR measures the length of task, timed by how long it takes a skilled person, that AI agents complete half the time. That length has doubled about every seven months since 2019, and under its updated 2026 method the doubling time since 2023 is 131 days. [11] Agents will take on longer stretches of each of these six jobs, year after year.

That makes the approval queue more important, not less. As each agent handles more, each yes covers more work. The owner's leverage comes from making those decisions well, with the evidence on one line.

It is already possible for one person to run several internet businesses. Pieter Levels reports that he builds and runs his startups alone, "all bootstrapped without funding and just me coding everything on my laptop." [12] The open question is whether people without his skills can do it, with an operating system doing the watching.

Where we are

Status, stated once.

Running at Lehvel today:

• One machine-readable registry of every live site we operate, ours and clients', and a check that fails a change that would take one of them down.
• Deterministic checks on a schedule: our own site against its published record, our hosting costs, and our knowledge base. No model runs on a timer.
• One path to production for every change: a branch, a pull request, tests on the exact commit, a merge, and an independent read of the live page before anything is called shipped.

Built and in use, without full autonomy: agents that draft changes, research and fixes inside a session a person started, with a person approving what ships.

Not built yet: the single morning page across several businesses; sales and support monitoring across a portfolio; agents answering customers without review. Those are the next pieces, and we will report each one here with what it caught and what it missed.

The vending machine is the right standard because it is modest. It does not run a company. It sells, counts, and asks for help when it jams. The businesses we want to build should do the same, every morning, with the owner reading one page instead of five.