What I Learned From DoorDash's AI Assistant Architecture

DoorDash published a three-part engineering series on Ask DoorDash, their conversational shopping assistant. I went in expecting model talk and came out with a list of things that had nothing to do with models. Here's what stuck.

The model wasn't the problem, the environment was

When they swapped Claude Sonnet 4.6 for Gemini 3.5 Flash, their eval harness said the new model was worse. Scores dropped sharply. The obvious read is that Flash wasn't good enough.

It wasn't a capability gap. Flash was passing a search query as {"dishes": [...]} where the tool signature declared a plain string, and parts of the system prompt had been tuned around conventions Sonnet happened to infer on its own. Their own line for it is the one I keep repeating: they were not changing the model, they were correcting the environment around it. After the fixes, Flash reached parity and shipped with a 35% latency cut.

That's a coupling problem. Their prompts had grown a quiet dependency on one vendor's habits, and nobody knew until a different model walked into it. I've never swapped a base model under a working system, which means I have no idea how much of my prompt is propping up one model's quirks. I'd like to find out before someone else does.

Grounding is a tool-call discipline

I expected them to name hallucination as their biggest production risk. They didn't. They named grounding: stores recommended as open when they're closed, prices that don't match the catalog, items the agent claims to have added that aren't in the cart.

The fix, every time, is boring. Route the agent's claim through a tool call against the system of record. Their stated goal is that every consumer-visible claim comes from a tool call on the turn it's made.

Redrawn from DoorDash's Figure 2 in the engineering overview.

Business logic lives in the tools, not the prompts. Cart manipulation, store lookup, deal application: all of it sits behind a Model Context Protocol layer backed by the same services the rest of the app uses. Personalization runs the identical path, so the agent calls memory_search exactly the way it calls find_nearby_stores. If you've read my piece on supervisor agent architecture, the routing will look familiar.

That's not an AI technique. That's refusing to let a cache lie to a customer.

The best decision they made was not calling the model

One grocery turn runs 6 to 8 LLM calls, pulls low hundreds of thousands of input tokens once the candidate set is in, and takes 20 to 30 seconds end to end. Twenty to thirty seconds, in a shopping flow.

Then look at what happens on turn two.

When the consumer taps the widget to swap a brand or drop a yogurt, that edit runs straight against the artifact through the Gateway while the model sits idle. Widgets are versioned objects with stable IDs, and the agent reads the latest version on the next turn. No round trip, no tokens, no 20-second wait, no chance of the model garbling an edit the user already expressed perfectly by tapping a button.

Most of us reach for the model on every interaction because the model is the exciting part. The lesson isn't how to make the agent handle the edit faster. It's noticing the edit was never an agent problem.

Exclusion is harder than inclusion

Memory-backed sessions converted ~24% higher for grocery, with 17% bigger baskets, and were ~33% less likely to misunderstand intent. Those are early-rollout figures over seven days, and DoorDash flags them as a snapshot rather than a trend, which is more caution than most engineering blogs bother with.

The number isn't the lesson though. This is: a consumer with 100+ memory blocks needs aggressive pruning, and not because tokens cost money. Too many competing facts injected at once caused the agent to start dropping instructions. Irrelevant context doesn't just waste budget, it degrades reasoning.

That inverts how I'd have built it. I'd have optimised recall. They optimised what to leave out, which is a harder thing to write a test for.

The durability rules are the subtle part. In restaurants, "I don't want ramen" is treated as transient unless you say "always", because otherwise a passing mood permanently kills noodles. In grocery, "I prefer Oatly" is exactly the durable signal you want. Same sentence shape, opposite handling, and the only thing separating them is domain knowledge a person sat down and encoded. No model release does that for you.

I'm still chewing on the rest of their Intelligence post, especially how it connects to agent memory more generally: they inject a compact index of which tokens actually exist in your namespaces once per session, so the model stops guessing your vocabulary and burning tokens on searches that return nothing.

What I'm taking away

Almost nothing that made Ask DoorDash work is an AI problem wearing AI clothes. Versioned artifacts. Typed tool contracts over a system of record. TTLs keyed to what a fact is about. A test harness with frozen fixtures. Decoupled deploys per domain team. Strip out the model and you're looking at a competent distributed system.

The model made the interface conversational. Everything that made it trustworthy is work we already knew how to do. I haven't decided yet whether that's reassuring or deflating.

I send occasional notes on system design and the senior-to-staff transition, no fixed schedule; you can sign up here. I break down architecture and engineering decisions on Gazar Breakpoint on YouTube.

If you want this thinking applied live, my next free session is System Design for AI Agents: Senior vs Staff on Tuesday, July 21, 2026, 6:30 PM GMT+1: 45 minutes on the five things that break every LLM agent after the demo, and the design decisions that stop each one. My courses and other free lessons are on my Maven profile.