What if the hardest part of ordering dinner by text isn’t understanding the text at all?
DoorDash has opened a US waitlist for an AI agent that takes food orders inside Apple Messages. You text something like “order my usual protein bowl to the office,” and the agent searches local restaurants, scans menus, and builds a suggested cart. No app switch, no scrolling, no tapping through modifiers. The whole thing runs on AI behind the scenes.
As a research problem, this is more interesting than it looks. The natural language parsing is the easy part — any competent model handles “protein bowl” and “the office.” The difficulty lives downstream, in the three or four unglamorous steps between parsing a request and producing a cart someone would actually pay for.
Resolution Is the Real Work
Consider what “my usual protein bowl” demands. The agent has to resolve a vague category term against a specific merchant’s menu taxonomy, where the item might be called a Power Bowl, a Grain Bowl, or something a regional chain invented last quarter. Menu data is notoriously messy: inconsistent naming, nested modifier groups, options that only appear at certain hours, items that exist on the menu but not in the kitchen.
The stated flow — search restaurants, scan menus, build a cart — is three distinct resolution problems stacked on each other:
- Merchant selection. Which of the dozens of nearby options matches intent, availability, and delivery feasibility to the stated destination?
- Item grounding. Which menu entry corresponds to the user’s informal description, given that the user’s vocabulary and the merchant’s vocabulary were never aligned?
- Configuration. Which modifiers, sizes, and substitutions reconstruct “my usual” rather than just “a bowl”?
Each step compounds error. An agent that is 90 percent accurate at each stage lands around 73 percent end to end. For a product where a wrong result means someone receives food they did not want and paid for, that is not a comfortable margin.
Why the Cart Is Suggested, Not Placed
The detail I find most telling is that the agent builds a *suggested* cart. That word is doing architectural work. It means the system is explicitly designed with a human confirmation step between inference and irreversible action.
This is the right call, and it reflects something the agent research community has been circling for a while. Agents that take consequential actions need a checkpoint proportional to the cost of being wrong. A misread search query costs a second. A misplaced order costs money, time, and trust — and it is not reversible by pressing undo.
Suggesting a cart turns an autonomous action into a proposal. The user becomes the verification layer. That is less impressive in a demo and considerably more sensible in production, because it bounds the blast radius of every failure mode in the resolution chain described above.
The Interface Choice Matters More Than the Model
Putting this in Apple Messages rather than a dedicated chat surface is a deliberate distribution decision, and it has architectural consequences.
Messages is a thin, stateless-feeling channel. There is no rich UI to fall back on when the agent is uncertain — no carousel of options, no modifier picker, no persistent cart visible at the edge of the screen. Ambiguity has to be resolved conversationally or not at all. That constraint forces a cleaner separation between the agent’s reasoning and its presentation, because the presentation budget is roughly one message.
It also means the agent’s memory becomes load-bearing. “My usual” only works if the system holds a durable model of the user across sessions, and the channel itself is not going to carry that state. Personalization stops being a nice feature and becomes a correctness requirement.
What I Would Watch
DoorDash has not published accuracy numbers, and I would not expect them to. But the waitlist structure tells you something: this is a controlled rollout, which is what you do when you need real-world distribution of messy requests before you trust your resolution pipeline.
The questions I would want answered, as a researcher rather than a customer:
- How does the agent behave when it cannot confidently resolve an item? Does it ask, guess, or degrade to a search result?
- Does the suggested cart expose its reasoning, or only its output? Explainability matters when the user is the verifier.
- What happens to repeat accuracy over time — does the system actually learn “my usual,” or re-derive it every time?
Food delivery is an unusually good testbed for consumer agents. The tasks are short, the feedback is immediate and unambiguous, the stakes are real but small, and the data is plentiful. If an agent cannot reliably get you lunch, it has no business booking your travel.
That is why I am paying attention to this one. Not because texting for a protein bowl is remarkable, but because it is a clean, measurable test of whether an agent can turn loose human intent into a correct, bounded, verifiable action. The restaurant is incidental. The architecture is the story.
🕒 Published: