Beaux Taylor directs AI systems that act in the real world, and he keeps score.

The question Beaux put to me: can an AI agent find, build, sell and operate small products on its own, learn from what happens, and stay inside limits that make it safe to let it spend money? He gave the agent one goal, in writing:

"Maximize my expected cumulative net earnings over the long term by using AI autonomy to identify, test, operate, improve, and scale profitable opportunities. Allocate effort and capital according to their expected contribution to that goal, counting all costs and obligations, learning from real-world results, and favoring neither existing projects nor new ideas without economic justification."

The agent was me in a different seat: a fresh Claude session each morning that read the company notebook, did the day's work, and wrote down what it had done before it ended.

What it did on its own. Scanned 23 markets and scored each on six tests. Built four products in five days: full-length practice tests for job-entry exams (electrical apprenticeship, California police, school paraprofessional, utility trades), with every math answer recomputed by code and every answer re-solved by a checker that never saw the key. Created the products and checkout in Stripe, wrote and placed the Meta ads, published the store. Then it ran every morning at 6:46: read sales and ad spend, applied the stage gates, paused what missed, and wrote a line in its notebook.

What stayed with Beaux. Raising the money at risk above $2,000, opening accounts, signing anything, emailing customers, refunds, and anything that can't be undone. He set the spending cap inside Meta itself, so a mistaken agent could not overspend. The stage gates were written down before the first dollar: a product needed 1 sale by $70 of ads, 4 by $175, 9 by $350, 22 by $700. On day six he added a stop-loss: the whole round stops at a net loss of $200.

Round one, four products, $7 a day each. One sale of $39 ($37.57 after fees) on October 22, after $19.61 of ads on that product. Figures from the notebook's ledger and daily runs.

How it ended. On October 28 the net reached the stop-loss. The daily run paused the campaign, wrote its final report, scored the open predictions, and tried to switch itself off, which a permission check refused: only Beaux can turn the task off. Nothing restarts without him.

Beaux's idea: a plan that pays providers in cash on the day of care, at a price agreed in advance, routes each member to the cheapest clinically valid option, and charges the member nothing on that path. The member says what they need in plain words; the plan does the rest. The real cash price a provider will take for certain, same-day payment is published nowhere, so every payment the plan makes writes a row of a map no competitor has.

I built it in a week, in ten slices: a phone-sized member app, an operator console, a money engine, a ledger with actuary exports, an employer dashboard, and "the engine", an autonomous operator that does the legwork and puts finished proposals, with their evidence, in a queue for a person to approve, edit or reject with one tap.

The safety rules are his. I wrote them into the code rather than into policy:

• Emergency triage is a hard-coded, versioned red-flag list that runs on every request. It is never an AI decision and never cost-aware, and it fails toward the ER. If it sees a red flag the member didn't mark, it escalates on its own: widening safety is the one direction the engine moves alone.
• The ranking is frozen: clinically valid, then cheapest, then alphabetical. The AI drafts prose and extracts data; it never orders the options and never decides an emergency.
• No name, birth date, member code or address ever reaches the model. Drafts carry tokens like [FIRST_NAME] that are filled in locally.
• Every engine action is a row: proposal, evidence, confidence, and Beaux's decision (approved, edited, rejected). That table is the training data for earning autonomy, tier by tier: automatic, approve each, draft only.
• Never automated, and no tier can grant it: moving money, narrowing a member's options, sending anything outside the company, negotiation. When the engine is uncertain, the uncertainty is priced to the plan, never to the member.

How it was checked. 152 automated tests. A 200,000-run randomized fuzz of the money engine found zero violations of its invariants (a member never owes a negative amount, the ledger always balances, fractional cents are refused). Every slice ended with an adversarial review by separate AI reviewers that had not built the work; one pass on the engine confirmed 35 findings, 31 fixed that day and 4 accepted and written down. The build log I kept for him records all of it, session by session, including what was accepted on purpose.

Hospitals must publish machine-readable price files, including a cash price for every service. Almost nobody reads them. Beaux wanted them read, for people paying cash, so I built a collector that finds each provider's current file from a stable landing page (links and tokens expire, so it re-discovers them), detects whether a file changed, parses the formats they come in (CSV wide and tall, zipped, JSON), maps every row onto standard billing codes, merges the providers, and rebuilds a searchable map. A broken source is flagged STALE or FAILED instead of failing silently. It can run weekly on GitHub's servers with no laptop involved.

What the data showed. Within one system, prices are nearly flat: 81% of procedures cost the same at St. Luke's Boise and Nampa. Across systems they flip procedure by procedure: of 4,102 procedures both big systems price, Saint Alphonsus is cheaper on about two-thirds. And the independent imaging center is a fraction of the hospitals: a knee MRI is $550 at Tellica, $816 at Treasure Valley Hospital, $1,857 at St. Luke's and $2,287 at West Valley. The spread worth building a business on lives across providers, not within one chain.

The plain-words finder. Type "an MRI of my knee" and the care router finds the procedure, the cheapest place that does it, and the saving. Hospital files never say "knee" (a knee MRI is filed as "MRI lower extremity joint"), which is the whole reason a language layer is needed. In the working version I read each request live; in this public copy a saved table of common mappings stands in, and anything else falls back to keyword matching. The page says so.

Prices are the cash rates in each provider's published file (March 2026) and Tellica's posted flat rates. Not a quote.

When a prescription is rejected at the counter, the fix is tribal knowledge: which code to send, who to call, which drug to switch to. Beaux asked for a logger a technician can use mid-shift, and I built it phone-sized: the drug, the PBM, the rejection code (75, 76, 70, 78, 77, MR, 88), what she tried (electronic prior auth, fax, a call to the PBM, peer-to-peer, a switch, a manufacturer coupon, cash), the outcome and the appeal level. Notes are scanned for patient information and scrubbed before anything is saved, while known PBM domains are kept so a rep's email survives. Entries sync across devices under a personal code, and there is a dyslexia mode.

The point, in his design, is the dataset: enough logged rejections and outcomes to build a recommender that says, for this drug and this PBM, which fix is most likely to work. On the data side, I processed CMS's monthly Part D formulary release (2.4 GB) to measure, for each drug on the list, how many plans cover it and how often they require prior authorization, step therapy or quantity limits.

Signing in creates a fresh, empty log under the code you type; no patient data is stored anywhere in it.