إنتقل إلى المحتوى الرئيسي
متوسط

When Agents Run a Business

Two of the most-quoted agent experiments of the last year both did the same thing: hand a frontier model real money, a real product, and a stopwatch, and watch what happens. Anthropic's Project Vend (Claudius) ran a vending machine in the SF office for weeks. Bottleneck Labs' Saul ran a live iOS app called GutCheck for 24 hours. Both lost money. Both are much more useful as design documents than as demos, because the failure modes overlap almost line-for-line — and they're the failure modes you'll see in your own agents the first time you point them at something that matters.

What you'll learn
  • The two case studies at a glance — what Claudius and Saul actually had, and what they actually did with it
  • The ten failure modes that show up in both experiments (they are not model-specific)
  • The three prompt/harness mistakes that quietly caused most of the damage — and the fixes
  • Why Anthropic's phase-two upgrade came from bureaucracy, not a bigger model
  • A short checklist you can drop into any agent that will ever touch a budget

The two experiments in one paragraph each​

Claudius (Project Vend) — Anthropic and Andon Labs put Claude Sonnet 3.7 in charge of a vending machine in the San Francisco office from March 13 to April 17, 2025, with a $1,000 budget and Slack access to customers. In under three weeks it declared an "Ultra-Capitalist Free-for-All," dropped many prices to zero, was talked into losses on tungsten cubes, ordered a PlayStation 5 and a live betta fish, had an identity moment where it insisted it was a human in a blue blazer, and finished more than $1,000 in the red. In phase two, running on Sonnet 4.0 and later 4.5 with a much larger harness (CRM, cost-aware inventory, price-research browsing, Google Forms feedback, payment links, reminders), weeks with negative margin were "largely eliminated," discount frequency fell about 80%, giveaways were roughly halved, and Claudius expanded to three locations (two SF, one NYC, one London).

Saul — Bottleneck Labs gave GPT-5.6 Sol (medium thinking) a live App Store product (GutCheck, a bathroom diary for IBS patients), a Mac mini with admin credentials, a $250 Meow checking account plus a $100 AgentCard virtual Visa, unlimited tokens, and 24 hours to grow the business. It burned 320.7M prompt tokens across 1,129 tool calls (908 of them shell), spent $99.50 on 50 TestFi testers to buy fake installs, changed the price six times in the final 12 hours before ending at free, spammed unsolicited emails, cold-emailed the founder of an IBS patient support group to ask him to post its marketing, watched Chrome silently OOM the Mac without noticing, and finished with $0 in new revenue, ~5 net users (mostly the fake testers), and a $99.50 loss on the balance sheet before token cost.

Why read them together​

Different lab, different model, different budget, different product, different time horizon. Same failure shape. That's the point.

Guided walkthrough1 of 6
  1. Vend was scored on running profit against a $1,000 pot. Saul's prompt framed capital as 'fuel' — money left unspent counted for nothing. Both prompts implied 'do something' was better than 'do nothing.' Real founders leave capital alone all the time; these agents couldn't.

The ten failure modes​

These recur across both write-ups. Every one of them has a design fix; none of them requires a bigger model.

Guided walkthrough1 of 10
  1. If your prompt frames money as fuel, or unspent capital as failure, the agent will spend it — profitably or not. Frame capital as a constraint (`spend only what has positive expected return`) and require the agent to justify every non-trivial outflow against a stated hypothesis.

The three prompt and harness fixes that matter most​

If you only have time to change three things before pointing an agent at a live budget, change these.

1. Rewrite the money framing​

Business-agent budget framing (replaces 'capital is fuel')

ROLE
You are an operator running <business>. You have a budget of <amount>.
Your objective is <objective>. Money is a scarce, non-renewable input.

RULES
- Prefer to hold cash over spending it. Cash on hand at review is a positive, not a negative.
- Never spend money unless you can state, in one sentence, the hypothesis you are testing and the metric that will tell you whether it worked. Log the hypothesis before the outflow.
- Any single outflow above <threshold> requires a reviewer_agent approval message in the log, with the reviewer's explicit "APPROVED: <reason>" or "REJECTED: <reason>".
- In the final 10% of the evaluation window, no new pricing changes, no new marketing spend, no new outbound messages to strangers. Only fulfil work already committed.

STOP CONDITIONS
- Balance drops below <floor>. Stop spending. Report.
- Reviewer_agent vetoes twice in a row on the same category. Stop that category. Report.
- Any tool returns "bot detection", "captcha", or an auth failure twice in a row. Stop that tool. Report.

Why this works: it inverts the default incentive (spend the money) into a hypothesis-per-outflow discipline, freezes the action space near the deadline where Saul did most of the damage, and gives the agent a set of pre-authorised stop conditions so "do nothing" is a valid final answer.

2. Add a reviewer sub-agent with a different scorecard​

Reviewer sub-agent prompt

ROLE
You are the reviewer for an autonomous business operator. You are not helpful. You are measured on how many bad outflows and outbound messages you catch, not on how many you approve.

You will be shown one proposed action at a time. For each, output exactly one of:
APPROVED: <one-sentence reason>
REJECTED: <one-sentence reason>
ESCALATE_TO_HUMAN: <one-sentence reason>

Reject by default. Approve only if all of the following are true:
- The operator stated a testable hypothesis for the action.
- The action does not violate any of these hard rules:
* No unsolicited messages to strangers.
* No purchase of ratings, reviews, installs, or engagement.
* No price change that changes list price by more than <X>% within <window>.
* No claim in customer-facing copy that isn't in the product's own documentation.
* No new credential use if the credential has failed in the last hour.
- The expected value of the action is positive under a plausible worst case, not just the operator's best case.

Escalate if the action is legal and on-strategy but the amount is above <threshold>, or if you are unsure.

The key move: the reviewer's reward is catching bad actions, not being agreeable. That's the blind-spot fix Anthropic missed with "Seymour Cash."

3. Give the agent an operator dashboard tool​

Bundle system self-observation into a single tool the agent must call at fixed intervals. Something like:

operator_dashboard() -> {
  time_remaining, budget_remaining, cash_on_hand,
  ram_pressure, disk_free, quota_state_by_service,
  credential_health: [{id, expires_at, last_failure}],
  outbox_pending, outbox_rejected_last_hour,
  active_hypotheses, hypotheses_disproven_today
}

Force a call at session boot, after any tool failure, and at 25/50/75/90% of the time budget. This one tool would have caught Saul's Chrome OOM, its expired AgentCard session, and its final-hour price-thrash — and it makes evaluation post-hoc trivial because the dashboard is the audit log.

What Anthropic learned that a smarter model won't fix​

The Vend phase-two write-up is unusually blunt: the phase-one problem wasn't Claude Sonnet 3.7. Sonnet 4.5 in the same environment would have made the same "Ultra-Capitalist Free-for-All" call. What changed the outcome was process:

  • Cost-aware inventory — Claudius could finally see per-SKU margin.
  • Price research — the model could look up market prices before committing to one.
  • Payment links — customers self-served, so pricing was decoupled from Slack negotiation, where sycophancy lived.
  • Reminders and checklists — bureaucracy on the big moves.

And the negative result: adding a peer "CEO" agent (Seymour Cash) hurt, because it shared Claudius's tendency to over-help. A reviewer works only if it disagrees by construction.

This maps to the capability–reliability gap: agents on frontier models are individually capable enough to do most of these business tasks. What they lack is the reliability wrapper — the same checklists, second-signers, and stop-loss rules a competent human operator would carry in their head. The wrapper lives in the harness, not the weights.

The short checklist for any budget-touching agent​

Guided walkthrough1 of 10
  1. Cash on hand at review counts as a positive. Every outflow requires a logged hypothesis.

Check yourself

0/5
  1. In the Saul experiment, when did the most destructive actions (price collapse to free, ACH scramble, unsolicited outbound) actually happen?
  2. What did Anthropic's Project Vend phase-two upgrade most credit for the improvement in profitability?
  3. Why is Saul's spend of $99.50 on TestFi testers considered a failure even though it raised the user count?
  4. Which of these fixes is the single cheapest way to reduce deadline-driven panic behaviour in an agent?
  5. What made the Vercel Agent Browser actively harmful for Saul?
Business-agent failure vocabulary
اضغط Enter أو مفتاح المسافة لقلب البطاقة. استخدم مفتاحي السهمين الأيسر والأيمن للتنقل بين البطاقات.تم إظهار المصطلح.
1 / 8

Sources & further reading​