DoorDash Cuts Grocery Reorder Latency From 16 to 2 Seconds With AI Agents

What Changed

DoorDash, the American food and grocery delivery app, reduced the latency of its grocery reorder flow inside Ask DoorDash, its conversational shopping assistant, from about 16 seconds to 2 seconds. The change, reported by InfoQ on October 30, 2026 based on a DoorDash technical post, doubled shopping list views and increased the order conversion rate by approximately 34% in that specific flow.

The gain didn't come from a faster model or more GPUs. It came from an architecture decision: taking out of the user response path the work that can be done ahead of time, offline, and leaving in real time only what actually depends on the catalog's current state.

How It Works in Practice

Before, every time the customer opened the reorder flow, the system rebuilt from scratch, via LLM, which items they probably wanted to buy again. That meant model inference happening in the request's critical path, which explains the 16 seconds.

The new architecture separates two stages:

• Batch pre-computation: DoorDash processes 90 days of purchase history plus consumer profile signals. Batch LLM inference identifies the likely recurring purchases, and a deterministic validation layer checks those results before storing them as reusable shopping list data.
• Real-time resolution: when the user opens the app, the system fetches that already-ready data and resolves each item against the current catalog, first trying the original store item, then a catalog product identifier, and finally a search term.

This fallback chain is what allows the system to handle a mutable catalog (a discontinued product, a store that swapped the item) without needing to repeat all the historical reasoning on every call. DoorDash engineer Twisha Jain summarized the logic behind the decision in a LinkedIn post:

Better agentic systems aren't always about more reasoning; they're about deciding what belongs in the agent loop and what can happen ahead of time.

Twisha Jain, engineer at DoorDash

When the LLM Still Runs in Real Time

The separation between offline and online doesn't eliminate the model from the critical path completely, it just reserves synchronous inference for cases that truly need new reasoning. The system still triggers the Grocery agent when the task requires comparing cheaper alternatives considering current price, promotions, package size, stock, and consumer preferences.

Simple operations, such as changing an item's quantity or removing a product from the list, are instead applied directly to the shopping list, without a new call to the LLM. This distinction, between what requires judgment and what is structural editing, is what keeps inference cost under control in a high-volume flow.

A DoorDash engineering post about the shopping interface describes the principle governing these edits:

A consumer's direct edit is authoritative: the next agent turn starts from the edited list, not from what was said earlier.

DoorDash Engineering, post about the shopping interface

The shopping list is treated as a structured artifact that both the consumer and the agent can update, instead of relying only on the conversation history to reconstruct state.

The Shared Agent Platform Behind It

This reorder flow wasn't built in isolation: it runs on Ask DoorDash's shared agent platform, which provides orchestration, memory, model access, tracing, evaluation infrastructure, and rollout controls as a common service. Domain teams (grocery, reservations, etc.) only retain ownership of the agent instructions, skills, tools, and evaluation criteria specific to their use case.

DoorDash reports that, with this base ready, adding a Reservations agent took one week, about ten times faster than building the initial domain agents from scratch. It's the usual reusable-infrastructure argument, now applied to agents: the platform amortizes engineering cost across multiple teams.

Why This Matters for Those Building E-commerce in Brazil

The pattern here is more interesting than the specific grocery use case. Any team that has a recommendation, checkout, or personalized search flow running synchronous LLM calls on every request is paying the same latency tax DoorDash had before the change. The question worth bringing to your own system is: how much of that reasoning depends on the exact instant of the request, and how much could be pre-computed in batch and only validated/resolved against current data at the time?

For marketplaces and retailers that already use generative AI in product recommendation or cart assembly, DoorDash's case suggests a concrete path:

1. Identify the signals that don't change with every request (purchase history, profile, consumption pattern) and process them offline, in batch.
2. Separate the result of the reasoning (what was inferred) from resolution against the current state (what's available now, at what price).
3. Reserve the synchronous model call only for decisions that truly require fresh data (price, stock, promotion).
4. Treat direct user edits as a source of truth that overwrites the previous state, instead of rebuilding everything from the conversation.

This design reduces not only perceived latency but also inference cost, since fewer LLM calls happen in the critical path per user. For those operating at scale in Brazil, with traffic spikes on dates like Black Friday, this kind of separation between offline work and real-time resolution can be the difference between a checkout that scales and one that degrades under load.

What Remains Open

DoorDash's material doesn't detail which model is used in the batch inference, nor the cost of running this 90-day history pipeline per user, nor how often the pre-computed data is updated. There's also no public benchmark comparing this architecture pattern to what other marketplace platforms, such as Instacart's shopping assistant, do internally. These are details that would matter to anyone replicating the design, and that have no disclosed numbers so far.