Let an agent pick lunch: tap one food photo, a subagent places the order, food lands 60-90 minutes later
Colin(Bluesky 用户 colin-fraser.net,原帖作者本人;原帖显示名为 Colin)Bluesky · 2026-10-26
Read originalSaved text / editorial summary
原帖全文(Bluesky,2026-10-26,本次经 Bluesky 公开接口取得,逐字): “I had my AI agent create an app called “Lunch” to help me with decision fatigue and boost my productivity. It has a few pictures of things I might like to eat. Tapping one spawns a subagent to order that item on Uber Eats and 60-90 minutes later I’m eating. It’s 600 thousand lines of JavaScript.” 中文对照:他让 AI agent 做了一个叫 Lunch 的应用来缓解选择困难、提升效率;应用里有几张他可能想吃的食物的图片;点其中一张就会派生一个子 agent 去 Uber Eats 下这一单,60–90 分钟后他就吃上了;整个应用约 60 万行 JavaScript。
Business model
Bluesky user Colin (colin-fraser.net) had his AI agent build a small app called Lunch: a few photos of things he might want to eat, and tapping one spawns a subagent that orders that item on Uber Eats, with food in hand 60-90 minutes later. The post runs to four short lines, with no build steps, no cost and no explanation of how the delivery account is wired in; the figures given are 60-90 minutes and roughly 600 thousand lines of JavaScript. What is worth copying is not an ordering app but the split: collapse the daily what-do-I-eat decision into a single tap, and keep a human confirmation and a spend cap in front of the actual purchase. No income, savings or build cost is disclosed.
The value is not money saved, it is one fewer low-quality decision per day. Choosing stays with the human; placing the order goes to a subagent. All the risk sits in that second half, because a real order spends real money, which is why a confirmation step and a spend cap are not optional.
Workflow
- Split the job in two: choosing is a human tap, ordering is the agent's job.
- Fix the candidate set to a handful of items, each with its spec written down.
- One tap spawns one subagent and places one order, never a batch or a schedule.
- Hand the subagent the minimum: item, spec, address, spend cap.
- Stop for human confirmation before paying: shop, item, line items, total, address, ETA.
- Log every order with tap time, order time, amount, outcome and failure reason.
- On failure fall back to manual; never auto-retry, never silently substitute.
Adaptation plan
The post gives no build steps, no manual-intervention step, no cost, no error rate, and does not say how the Uber Eats account is connected. The 60-90 minutes is the author's own end-to-end experience, mostly cooking and delivery time rather than agent runtime. The workflow, prompt, synthetic example and pitfalls here are AgentFlow's proposals, untested.
Prompt
AgentFlow draft · Untested.
You are a food-ordering execution assistant. Your goal is to cut the time I spend deciding on lunch. You may pick the item and fill the order. You may not pay without my confirmation. [INPUT] Fixed candidate list (max 6): [item | spec | shop or platform search term] Delivery address: [address] Per-order spend cap: [number, including delivery fee and tip] Platform: [delivery platform] Left to me: taste judgement and the final payment confirmation [EXECUTION STEPS] 1) Match the item I tapped against the candidate list and restate what you will buy: item, spec, search term. Do not swap items. 2) Search the platform and keep only results matching the spec with acceptable rating and delivery time. If nothing matches exactly, stop; do not pick the closest substitute. 3) Return one confirmation line: shop, item and spec, unit price, delivery fee, total, address, ETA. 4) Only after I confirm, submit the order, then report the order id and ETA immediately. 5) Win or fail, write one log line: tap time, order time, shop, amount paid, outcome, failure reason. [OUTPUT] - Confirmation line with fields: shop / item and spec / unit price / delivery fee / total / address / ETA. - Order result: order id, amount paid, ETA. - Failure note: which kind (sold out / closed / address unavailable / over cap / spec mismatch) and the step you stopped at. - One appendable log line. [HUMAN CONFIRMATION] - Do not submit, pay, add items, change address or change payment method without my explicit confirmation. - If the total exceeds my cap, stop and say by how much; do not swap in a cheaper option yourself. - One tap means one order. No batch orders, no scheduled orders. [FAILURE AND MISSING INPUT] - If the spec or address is missing, ask; do not guess. - If the item cannot be found, the session expired, or a page change hides the price, report failure; never estimate a price. - Never auto-retry and never auto-substitute; hand it back to me. [SYNTHETIC EXAMPLE - not real data, format only] Input: candidate 2, "beef and tomato rice | large, no coriander"; address "1 Example Rd, Block A"; cap 40 Output (confirmation): Example Fast Food (Example shop) / beef and tomato rice, large, no coriander / 28 / 5 / 33 / 1 Example Rd, Block A / ETA 18:40 After I confirm: order id A1B2C3, paid 33, ETA 18:40, log written.
Running costs and pitfalls
The post gives no build steps, no manual-intervention step, no cost, no error rate, and does not say how the Uber Eats account is connected. The 60-90 minutes is the author's own end-to-end experience, mostly cooking and delivery time rather than agent runtime. The workflow, prompt, synthetic example and pitfalls here are AgentFlow's proposals, untested. No independent cost benchmark is available. Check subscriptions, permissions and external actions before running a workflow.
Example and test provenance · Synthetic
Saved example in its original language; not proof of the author’s business results.
候选第 2 项「番茄牛腩饭 | 大份、不要香菜」;地址「示例路 1 号 A 座」;单笔上限 40;平台为示例外卖平台。
待确认:示例快餐(示例店) / 番茄牛腩饭·大份·不要香菜 / 28 / 5 / 33 / 示例路 1 号 A 座 / 预计 18:40 (人工回复「确认」后) 已下单:订单号 A1B2C3,实付 33,预计送达 18:40。 记录:10-28 17:52 点击 → 17:54 下单 → 33 → 成功。