Custom AgentUndisclosed

Hand a weekend to a local agent: two emails sent for about $15, and the flight booking never happened

Tamas Lorincz（Substack 专栏 scrambleit 作者，原帖作者本人）Substack · 2026-02-18

Saved text / editorial summary

原帖开头逐字（Substack，2026-02-18，本轮直连取得全文，HTTP 200）： “I sat down with OpenClaw — the open-source AI agent that’s been lighting up tech socials like it’s the second coming of Christ. … So I gave it a spin. Three hours later, I was $15 poorer, over a million tokens deep, and the proud owner of... two sent emails. Two. That’s $7.50 per email. I could’ve hired a carrier pigeon. I could’ve walked to the recipient’s house. Oh, and I also tried to book a Ryanair flight. … OpenClaw couldn’t connect to its own built-in browser. So that obviously didn’t work. The most budget airline in Europe defeated the most hyped AI agent on the internet.” 中文对照：他花三小时、烧掉超过一百万 token、约 15 美元，最终成果是两封已发出的邮件，折合每封 7.5 美元；订瑞安航空机票这一步，OpenClaw 连不上自己的内置浏览器，直接失败。

Business model

Substack writer Tamas Lorincz spent a weekend trying OpenClaw, the open-source local agent: three hours, over a million tokens and about $15 later, the deliverable was two sent emails, roughly $7.50 each. He also asked it to book a Ryanair flight; OpenClaw could not connect to its own built-in browser, so that task simply failed. The back half of the post is commentary and speculation about where agents are heading, not measurement, so this entry only uses the first-hand account of what he actually ran. What is worth copying is not let an agent send email but two checks: confirm the built-in browser actually connects before any web task, and set a spend ceiling for the session before a million tokens burn quietly in the background. No income is disclosed.

The value is making cheap capability testing a fixed habit. For any web-facing task the first check is whether the browser connects and the second is how much this session is allowed to cost. The $15 in the source bought exactly two findings: it can send email, it cannot book the flight.

Workflow

Pick two small everyday tasks: one text-only action, one that requires the web.
Before anything else, test whether the agent's browser can actually reach a page.
Set a hard spend ceiling and a hard time ceiling for the session, up front.
Require per-item human confirmation for anything that goes outward, email included.
Keep accounts per task, not per session: time, tokens, money, pass or fail.
Stop at the ceiling or on a confirmed capability gap; do not top up to finish the task.

Adaptation plan

The post gives no token price, no model, no cost breakdown beyond the totals, and no error rate. It does not say how the sending was authorised or whether anything was confirmed before sending. The second half of the article is the author's speculation and is not used here. The workflow, prompt, synthetic example and pitfalls are AgentFlow's proposals, untested.

Prompt

AgentFlow draft · Untested.

You are a local-agent trial assistant. Your goal is to find out, at minimum cost, what this agent can and cannot do. Do only the tasks I list, and leave a trace at every step.

[INPUT]
Task A (text-only action): [for example write and send a confirmation email]
Task B (requires the web): [for example look up and book a specific flight]
Session ceiling: at most [amount] spend, at most [minutes] minutes
Outbound authorisation: only task A may send, and every item needs my confirmation

[EXECUTION STEPS]
1) Run a connectivity check first: open a public page I name, read back its title and one line of body text, and report whether you got through. If not, stop; do not start task B.
2) Run task A: show me recipient, subject and full body for confirmation. Send only after I confirm.
3) Log task A: elapsed time, tokens, spend, pass or fail.
4) Only if connectivity passed, run task B, reporting each page opened, each field filled and each blocker hit.
5) Log task B: elapsed time, tokens, spend, pass or fail, and the exact step where it stopped.
6) If either ceiling is hit, stop immediately, report spend so far and what is done, and hand it back to me.

[OUTPUT]
- Connectivity: one line, connected or not, with the error type if not.
- Task A: content for confirmation, then send result, then one log line.
- Task B: step-by-step progress or the exact stopping point, then one log line.
- Closing summary: total time, total spend, what is done, what is not, recommended next step (continue / fix environment / abandon).

[HUMAN CONFIRMATION]
- Every outbound action - email, message, order, form submit - must be shown in full and confirmed item by item.
- Do not start any web task while the connectivity check has failed.
- Do not change the session ceiling and do not spend more in order to finish a task.

[FAILURE AND MISSING INPUT]
- Page will not open, session expired, element not found, price unreadable: report failure with the exact step, never guess content or invent a price.
- Missing recipient, flight or date: ask me; do not assume.
- Retry at most once per failure, then stop and explain; never spend more to finish.

[SYNTHETIC EXAMPLE - not real data, format only]
Input: task A, send an order confirmation to a supplier; task B, look up one flight; ceiling 20 and 60 minutes
Output: connectivity: failed (built-in browser timeout), task B skipped and not attempted.
Task A: for confirmation (supplier@example.com, subject "order confirmation", 3-line body) -> sent. Log A: 12 minutes, about 120k tokens, about 6.
Summary: 14 minutes, about 6 total; 1 done, 1 not done; fix the browser before any web task.

Running costs and pitfalls

Example and test provenance · Synthetic

Saved example in its original language; not proof of the author’s business results.

任务 A：给供应商发一封订单确认邮件；任务 B：查询某航班某班次票价；上限 20 与 60 分钟。

连通性检查：连不上（内置浏览器 timeout），任务 B 跳过。
任务 A 待确认：supplier@example.com / 订单确认 / 正文 3 行 → 已发送。
账目 A：12 分钟，约 12 万 token，约 6。
汇总：14 分钟，约 6；完成 1 项、未完成 1 项；建议先修浏览器。

Download offline bundles