Text your dinner. That’s the whole interface.
DoorDash has launched an AI agent that takes food orders through Apple Messages. You type something like “order my usual protein bowl to the office,” and the agent searches local restaurants, scans menus, and builds a suggested cart from that request. A US waitlist is open now.
No app icon to tap. No category grid. No infinite scroll of carousels you didn’t ask for. Just a thread, same as the one you use to argue with your sibling about holiday plans.
I build bots for a living, and this is the kind of launch I pay attention to — not because the model is doing something exotic, but because the surface choice is doing most of the heavy lifting.
The channel is the feature
Most teams I talk to want to bolt a chat assistant onto their existing app. Little bubble in the corner, maybe a slide-up panel. It almost never gets used, because asking someone to open your app and then find your chat widget is two steps worse than just using the app.
Putting the agent in Messages flips that. The user is already there. The keyboard is already up. There’s no install, no onboarding carousel, no permission prompt. The distance between intent and action collapses to a single typed sentence.
If you’re designing a bot right now, that’s the question worth sitting with: where is your user already typing? Because the best interface is frequently one you didn’t build.
Reading the architecture from the outside
We don’t have DoorDash’s internals, so treat the following as an engineer’s read rather than confirmed detail. But the described behavior — searching restaurants, scanning menus, building a suggested cart — maps onto a pattern most of us have assembled at a smaller scale.
- Intent parsing with slots. “My usual protein bowl to the office” packs a product reference, a personalization lookup, and a delivery address alias into eight words. Each of those resolves against different data.
- Retrieval over catalogs. Menus are messy, inconsistently structured, and change constantly. Matching a loose phrase to an actual purchasable SKU across thousands of local restaurants is a search and ranking problem wearing a chat costume.
- Tool calls against real systems. Pricing, availability, store hours, delivery radius. The model proposes; the backend decides what’s actually orderable.
- A confirmation step. The output is a suggested cart. The agent stops short of silently charging you.
That last point is the one I’d underline for anyone shipping transactional agents. The hard part of an ordering bot isn’t understanding language. It’s deciding where the human stays in the loop.
Why “my usual” is the tricky part
Search and menu parsing are solvable with good retrieval. Personal memory is where things get interesting, and where most hobby projects fall over.
“My usual” implies persistent state tied to identity — order history, a resolved notion of what “the office” means, probably some sense of recency and frequency. Build that naively and you get a bot that confidently reorders the thing you tried once and hated. Build it well and you get something that feels like a person who knows you.
The failure modes are asymmetric, too. Guessing wrong on a search query costs a user one extra message. Guessing wrong on a stored preference costs them money and a lunch they didn’t want. Memory in a transactional agent needs to be either confirmed or cheap to reverse.
What I’d try this weekend
You don’t need DoorDash’s infrastructure to practice this pattern. A scaled-down version is a genuinely good learning project:
- Pick a messaging channel with an accessible API and route inbound text to a handler.
- Give your model two or three real tools — a catalog search, an availability check, a cart builder. Keep the tool surface small and well-described.
- Store user state in something boring. A single table with user ID, aliases, and recent selections gets you surprisingly far.
- Always return a draft for confirmation before anything irreversible happens.
- Log every turn with the resolved tool calls. You cannot debug an agent from transcripts alone.
Swap food for library books, hardware parts, or internal IT requests. The shape of the system barely changes.
The quiet shift
Ordering food was never the hard problem. Apps solved that years ago. What’s changing is the expectation that you should have to learn a company’s navigation structure to buy something from them.
A waitlist in one country inside one messaging app is a narrow launch, and narrow launches fail all the time. But the pattern underneath it — natural language in, structured action out, human confirming the last step — is the one worth getting good at. It generalizes far past lunch.
🕒 Published: