Dynamic Moments: Weaving LLMs into Deep Personalization at DoorDash

The central thesis of this talk is a division of labour: let LLMs do content ideation and user understanding, let classical deep learning do last-mile ranking, and never confuse the two. Sudeep Das (Head of ML and AI, New Business Verticals at DoorDash) and Pradeep Muthukrishnan (Head of Growth for the same group) describe how DoorDash moved from static, cohort-level merchandising to what they call dynamic moments — short-lived, high-context windows of user intent that a recommender has to notice and act on within the session.

The forcing function is catalogue abundance. DoorDash's product ambition, as Das frames it, is to be your "local commerce buddy": not just restaurants but grocery, convenience, alcohol, flowers, pets, electronics — anything sold near you. That ambition has a cost. Once the platform carries millions of users, thousands of merchants, and a catalogue that large, the hard problem is no longer delivery, it is choosing what to show. This post reconstructs their answer from the presentation transcript, including the audience Q&A. Points marked Context are supplementary explanation for readers new to recommender systems, and points marked Author's note are my own commentary on gaps in the talk; neither is a claim made by the speakers.

What You Will Learn

• Why classical collaborative-filtering-style personalization fails at moment-awareness and cold start, and what LLMs add.
• How DoorDash represents users as plain-English "consumer profiles" split into memory blocks, and how those profiles are initialised and updated.
• How LLMs generate per-consumer content blueprints offline and how search queries populate them online.
• Why LLMs are deliberately kept out of the serving path, and what runs online instead.
• How the team evaluates thousands of unique, per-user carousels and optimises the whole compound system with GEPA inside DSPy.
• Where the speakers say LLMs should not be used, and the caveats raised in Q&A around feedback loops, exploration, and cost.

Why Classic Personalization Stops Working

Das gives a compressed history to set up the gap. Personalization began with matrix factorization made famous by the Netflix Prize, plus LDA-style topic approaches. Then came the deep learning wave: wide-and-deep models, multi-task multi-label (MTML) models, and two-tower embeddings for retrieval. He calls all of this "classic personalization" and is careful to say DoorDash still needs it.

Context: Matrix factorization decomposes the user-item interaction matrix into low-dimensional user and item vectors so that unseen preferences can be predicted from their dot product. A two-tower model trains one encoder for users and one for items into a shared embedding space, so retrieval becomes an approximate nearest-neighbour lookup — cheap enough to run over a huge catalogue in milliseconds. Multi-task models predict several objectives at once (click, conversion, add-to-cart) from shared representations.

What these systems do well is learn from within the system: engagement signals and some product metadata, ending up as something close to collaborative filtering — people like you bought this, or this item is similar to that one. Das identifies two things they do badly.

The first is moment-awareness. If you are hungry at 11pm and want snacks, the system has to understand the intent expressed in that context. Classic personalization learns long-term interests, which are genuinely informative but react too slowly. His concrete example: on Black Friday you spend thirty seconds on a product detail page for a deal, and a long-term-interest model is simply not "active enough" to throw that back at you when you reopen the app.

The second is world knowledge. If DoorDash onboarded Best Buy yesterday, there is no engagement data on those items at all, yet the system should still be able to infer from your other purchases what you would want. LLMs carry that knowledge from pre-training, so they can bridge the gap that a purely behavioural model cannot.

Context: this is the classic cold start problem. Collaborative filtering is structurally unable to rank an item nobody has interacted with; historically teams patched it with content-based features. An LLM is a much richer source of content-based priors because it already knows what a Bose QC Ultra is.

A third strength Das names for LLMs is explainability. An LLM can read past behaviour plus in-session behaviour, infer intent, and state that intent back in natural language — something you can show the consumer. The narrative he wants to move is from "people like you like X" to "you need X now".

Why Static Merchandising Does Not Scale

Two analogies carry the argument. A billboard on a highway is one asset for everyone; it can be personalized to the average passer-by and it does not change based on who is looking at it. A physical store is slightly better — the manager arranges promos and relocates products to sell better — but the manager is still merchandising for an average consumer, because there is no way to build five million replicas of the store for five million shoppers. The burden falls on the customer to walk their own path to what they want.

A digital surface has no such constraint. DoorDash can give each consumer their personalized path through the app without the consumer having to think about it. The second limitation of the old approach is throughput: much merchandising was editorial, done by humans. Editorial judgement is still needed, but humans cannot generate enough distinct content to meet every consumer, and generation is exactly what LLMs are good at.

Dynamic Moments Defined

A dynamic moment is a short-lived, high-context event the consumer is expressing. The speakers' examples span three scales: personal and mundane (a movie night), personal and significant (your birthday), and social or nationwide (Black Friday). Three properties matter for engineering:

• Nothing is static. Even inside a single Black Friday window one consumer's intent can shift — TVs today, headphones tomorrow.
• Interests drift and seasonality comes and goes, so the profile cannot be a frozen artefact.
• Deals and promotions must be surfaceable to the right customer at the right moment, which makes real-time inventory and deal state a first-class input.

Their slogan for it: whatever life throws at you, we adapt in real time.

The Ideal Experience: Alice on Black Friday

The talk grounds all of this in a worked example. Alice has been a DoorDash customer for years, so there is restaurant history. Since retail launched she has also ordered chargers, cables, and electronic essentials — so she knows the platform sells electronics. Recently she has browsed premium headphones: Apple AirPods Max, Bose QC Ultra, Beats over-ear.

Two inferences fall straight out of that browsing set: she is not interested in earbuds, and she is interested in noise cancelling. The pattern is "premium over-ear noise-cancelling headphones", which is a far sharper signal than "electronics".

When Black Friday arrives, the ideal homepage is dense with electronics deals and visibly honed in on over-ear noise-cancelling headphones — but crucially it is not an entire page of headphones. Das is explicit that variety matters: the page also reflects interest she showed in TVs and video games, includes a healthy amount of exploration because "it cannot always all be targeting", and steers her toward merchants she has affinity for, in this case Best Buy and Home Depot.

To make that page, four ingredients are required:

Layer One: Product Understanding

DoorDash's product knowledge pipeline moved from human-centric to AI-driven, and this is where the talk's clearest quantitative claim lives. An attribute extraction task — determining for a headphone whether it is noise cancelling, its brand, colour, over-ear versus earbud; or for a bag of chips its brand, flavour, and allergens — used to take 28 days. The same task now takes 2 days. That is DoorDash's reported internal result for one task, not a general industry benchmark.

Getting there took four steps, and the order is instructive:

1. Vanilla LLMs get you part of the way. Das describes this as "the 80 of the 80/20" — good enough to prove the approach, not good enough to ship.
2. Fine-tuning, done in-house, to hit the accuracy bar. The reason the bar is high is not aesthetic: if an allergen is extracted wrongly, "someone might actually die". Safety-critical attributes force precision requirements that a generic model will not meet.
3. RAG grounding so the model knows DoorDash's own ontology, taxonomy, and the products actually carried, and can therefore make an informed decision rather than a plausible-sounding one.
4. Agentic enrichment for the hardest inputs. Many mom-and-pop merchants send a spreadsheet of abbreviations that a human cannot decipher either. The agent searches Google with that fragment, scrapes the merchant's website, gathers the results, and lets an LLM reason over them to extract the right attributes.

Context: RAG (retrieval-augmented generation) means fetching relevant documents at inference time and putting them in the prompt, so the model answers from your data instead of from parametric memory. It is the standard mitigation for hallucinated attribute values.

Two points the speakers stress. This is a human-in-the-loop system, not autonomous extraction — the phrase in the talk is "the story is human in the loop". And the payoff extends past the consumer: accurate variant-level attributes let DoorDash tell the Dasher exactly which item to pick up in-store. The headline business outcome is small merchant onboarding: a process that was purely human-driven precisely because those items are so hard to interpret is now mostly AI-driven with humans reviewing.

Layer Two: Consumer Profiles

Muthukrishnan takes over for the other core pillar. He is upfront that consumer profiles are not new, and traces three generations.

Feature vectors (early 2000s). Represent each consumer as an enormous vector stuffed with engagement counts across pages, taxonomies, categories, and item clicks, and hope the model has enough expressiveness to learn from it. It worked for a while, but the vectors kept growing and models struggled to learn from representations that expansive.

Embeddings (roughly 2010–2015). More expressive and far more compact, with multiple embeddings per consumer representing different facets.

Natural-language narratives (now). Represent the profile in "just plain old English". The argument is expressiveness without unbounded width: you can write anything you believe about the user — store preferences, category preferences, item- and brand-level preferences — in prose. The shared weakness of the first two generations is that both learned only from your own app's engagement, with no external real-world information. That is precisely where LLMs are strong.

The second benefit is explanation. Traditional ML could not explain a recommendation back to the user in a legible way; with narrative profiles you can tell the consumer why they are seeing this content, and Muthukrishnan reports that this has "an immense impact" on engagement with the recommendations. That is the speakers' observed experience, not a published number.

Profiles are grouped into memory blocks: dietary habits, household information, category preferences, item and brand preferences, taxonomy preferences, and so on. The example Muthukrishnan reads out from the taxonomy-preference block for Alice is roughly: Alice tends to purchase last-minute electronics, but has also shown interest in premium over-ear noise-cancelling headphones like Apple, Bose, Beats, and Bowers & Wilkins.

Alongside the prose, structured facets are extracted and stored — the two he names are electronics taste (premium) and preferred form factor. This matters operationally: retrieval and targeting against a stored facet such as premium electronics taste is easier than matching against narrative snippets. A notification campaign can then target every consumer with premium electronics taste directly.

Critically, the profile is a shared primitive, used across notifications, homepage carousels and collections, ranking, and search — a core company-wide asset rather than a per-feature artefact.

Initialising and Updating Profiles

An audience member asked exactly this. Muthukrishnan splits it in two.

Initialisation dumps roughly the last year of consumer activity into the LLM: items bought, search queries issued, and — a nice signal most teams overlook — substitutions the consumer accepted when a Dasher reported an item out of stock. Even here they do not send everything to every block: restaurant orders feed the restaurant-habits block, new-vertical orders feed grocery shopping. Partitioning the input is a cost control.

Updates are per-block. Each memory block gets its own cadence, because dietary habits and item-level preferences do not need refreshing at the same rate, and certainly not on every app open. Each block also gets whichever model is appropriate for it. Updates are delta updates — you do not resend a year of history — which serves two purposes at once: cost, and recency weighting so the most recent interactions dominate.

The same questioner also asked whether user-supplied text entering the profile creates prompt injection, jailbreaking, or state corruption risk requiring sanitisation. The speakers answered only the update half of the question; the security half was not addressed in the talk.

Author's note: this is worth flagging, because a profile built partly from free-text search queries and agent chat, then injected into downstream prompts, is a textbook second-order prompt injection surface. Treat that as an open risk you must design for yourself rather than a solved problem.

Layer Three: Hyper-Personalized Merchandising

With profiles in hand, the generation step runs per consumer, every week, per use case. The LLM is asked: given this profile and long-term memory, what should we show this consumer, and what carousels make sense?

Use cases split into two families:

• Evergreen — grocery stock-up, brunch basics, nightly snacks.
• In-the-moment — Black Friday, back to school, flu season.

The output is a content blueprint for each carousel: the framing that best sells this use case to this person. Muthukrishnan's own example is that generic "grocery stock-up" becomes "premium seafood essentials" for him because he eats a lot of seafood — and would become something else entirely for Das.

The blueprint also specifies how to populate the carousel, as a set of search queries. This is the design decision worth stealing: they found plain search "expansive enough" to be the universal population primitive across every use case they had. For any collection, you describe the items you want as queries, and you can attach constraints — price sensitivity, brands, price bands, merchants, store propensities. Price sensitivity is itself contextual: a consumer may be price sensitive for retail or electronics deals but not for groceries. All of these constraints come "for free" from the LLM as part of blueprint generation.

Layer Four: Dynamic Content, Offline Versus Online

Muthukrishnan is blunt: "LLMs are still not great at using them online. You don't want them in your serving path itself" — for latency and for cost. So content generation is offline: a carousel config per consumer, holding 40 to 50 different merchandising ideas.

What must happen online is population of those carousels, for four reasons:

• Inventory changes, and you cannot show what is not available.
• Deal state changes, and deals are the point on Black Friday.
• In-session intent changes. The blueprint reflects everything up to the moment the user opened the app; once inside, they may have stopped looking at headphones and started searching TVs.
• Address changes. Switch delivery address and the available catalogue changes with it.

Generating everything end-to-end offline "isn't really a good idea." The right shape is: decide offline what kind of thing to show, adapt online to whatever has changed since.

Real-time signals include in-session searches and, increasingly, agent conversations. Their example: you tell an in-app agent you are hosting a taco night and a friend is allergic to cilantro — the system must then suppress cilantro even though it sits in your grocery stock-up blueprint. For Alice, the real-time signal was 75-inch TVs, so the blended result shows TVs alongside headphones.

Architecture And Data Flow

The end-to-end path, reconstructed from the talk. Every node and every solid edge is described in the presentation; dashed edges denote asynchronous or batch paths rather than request-time calls, and the one from the profile store back into offline generation is my own inference, since the speakers describe generation as consuming the profile without describing that wiring.

flowchart TD
    App["Mobile app"] --> Feed["Feed service
orchestration layer"]
    App -->|"consumer event stream"| Brain
    Feed -->|"fetch carousels for consumer"| Brain["DoorDash Brain
profile store + serving
+ real-time intent blending"]
    Offline["Offline weekly LLM generation
40-50 carousel blueprints per consumer"] -.->|"carousel config"| Brain
    Brain -->|"10-20 queries per carousel
+ real-time expansion = 20-30 retrievals"| Retrieval["Retrieval
item embedding index +
lexical + semantic search"]
    Retrieval --> Rank["Ranking
two-tower / MTML models"]
    Rank --> Feed
    Feed --> App
    Brain -.->|"batch update (~daily)"| Profiles[("Consumer profiles
memory blocks")]
    Profiles -.-> Offline

The feed service is a thin orchestration layer: it passes through events and calls the relevant microservices. DoorDash Brain is the service that "understands everything about the consumer" — it hosts and serves profiles, and it blends real-time intent. Consumer events stream into Brain, which tracks how intent is evolving using multiple embeddings, because calling an LLM to rewrite narratives in real time is not feasible. Embeddings approximate in-session intent; the results are batch-written back into the profile over roughly a day.

On a homepage request, Brain fetches the pre-generated carousels for that consumer. Each carousel requires 10 to 20 queries; adding real-time intent expansion pushes it to 20 to 30 embedding retrievals per request, hitting a separate item-embedding index, plus lexical search and the usual semantic search workflow.

Then — and Muthukrishnan calls this the key point — the results still get ranked. The LLM-generated queries buy you a certain level of personalization, but "your two-tower embedding models or your MTML ranker models, don't throw them away." They encode item-level preferences the query text does not, and for categories with frequent repeat purchases such as grocery, that is where part of the personalization actually happens — "it's not just what the LLM did for you."

Evaluating a System That Generates Something Different for Everyone

The old world was auditable. Cohort-level merchandising meant perhaps 30 use cases and 100 carousels; a human could review the whole set and say what was good and what was not. The new world produces 50 brand-new carousels per consumer, with different copy and different items every time. As Muthukrishnan puts it, "you can't just go based off vibes" — and the goal is not evaluation for its own sake, it is a signal you can optimise against.

They evaluate along three axes, which together form the reward function:

1. Quantitative metrics and rubrics. Does the carousel match the personalization it claimed? Is this something the user is likely to click? If the variant is already running as an experiment, use the real online data.
2. LLM-as-a-judge. Muthukrishnan acknowledges the obvious discomfort — "it feels like it's LLMs all the way down. LLMs generated it, and then you ask the LLM saying, was this good?" It contributes part of the signal, not all of it.
3. Human-annotated textual feedback. Collected from professional annotators and from internal dogfooding. Crucially, this feedback does not need to be numeric. Asking "what do you think about this carousel?" or showing several carousels together and asking "if you saw this on the homepage, is this a good or bad experience?" produces free-form text that feeds straight back into the optimiser — and Muthukrishnan says textual feedback works much better for optimising prompts than scores and scalars.

GEPA and the Compound AI System

The optimiser is GEPA (Genetic-Pareto), used through DSPy.

Context: DSPy is a framework for programming rather than prompting LLM pipelines, where prompts are treated as optimisable parameters. GEPA is one of its optimisers, using reflective evolution over textual feedback rather than gradient descent.

A compound AI system is one with many moving parts — prompts, the profile component, retrieval logic, ranking logic. GEPA lets each of those be treated as a parameter to optimise, provided you can define a reward function. The parameters DoorDash currently tunes:

• Prompts and templates. Example: consumers said a carousel was too monotonous, so the optimiser learns to require variety within the primary category rather than returning only headphones.
• Search term generation. If the generated queries all return the same items, push for more diversity across queries.
• Profile generation. If you missed something — the user bought Bose headphones six months ago and the profile never captured it — the optimiser can expand which facets get generated.
• The ranking objective. How much exploration versus exploitation, and what the value model should say.

Muthukrishnan is careful not to oversell it: "GEPA is great, but it's not really doing any convex optimization over any of these things. It's just doing some evolutionary biology-based mutations here and there, and does some hill climbing." Expect a search heuristic, not a guaranteed optimum.

Trade-offs And Limitations

Keep traditional ML for three explicit reasons. Muthukrishnan names them: latency, explainability, and the fact that deep models are not merely stochastic but genuinely optimisable against an objective. That last point is the sharpest — GEPA does hill climbing over prompts, whereas a ranker is trained against a loss function.

LLMs must not do last-mile ranking. The clearest rule in the talk: "Don't let your LLMs do the last mile ranking, and don't... do ranking, do the content ideation piece, or your ML models do the content ideation piece." The division is symmetric — each side is bad at the other's job. LLMs shine at turning messy behaviour into clean, understandable narratives; deep learning models shine at optimising concrete metrics such as click-through rate or conversion rate under constraints. Note that this rule is about the ranking layer: scoring a large candidate set against CTR or CVR inside a tight latency budget. It does not forbid an LLM from reasoning over a handful of already-retrieved candidates, as the agent example further down shows — that is a different problem with a different cost profile. Muthukrishnan also lands a useful aside on how fast the vocabulary has shifted: "It's sad to say that deep neural networks have come to be called as traditional machine learning now, and they're only around for 10 years or so." Do not read "traditional" as "obsolete".

Cost and latency bound everything. LLMs stay offline. Per-user prompts are out of reach — when asked whether feedback-driven prompt changes (for instance, "include at least 30% non-specified products") imply per-user prompts, Muthukrishnan's answer was direct: "That becomes too expensive, so we still do a single prompt for a use case, but not for per user." Das added the workaround: keep the prompt generic and personalise through what you pull into the context at answer-generation time. They have tried this, and the agentic use case benefits most.

Profile updates are also cost-shaped: block-level cadences, partitioned inputs, and delta updates all exist primarily to avoid re-processing a year of history.

Feedback loops do not go away. Asked whether the profile distinguishes the user's organic actions from actions taken in response to DoorDash's own recommendations — buy gloves, get recommended a wool cap, buy the cap, now "wool caps" looks like intent — Das named it as the age-old pigeonhole effect and said plainly that it "is not going to go away in the LLM world either." What they feed the LLM is factual interaction history, and behind that history sits a recommender. The only break is exploration.

Muthukrishnan added that LLMs can at least make exploration smarter: instruct the model to expand into adjacent categories when generating carousel queries — if someone likes Indian and Mexican restaurants, Thai has enough overlap to be a reasonable probe, and that adjacency comes from world knowledge. Das went further and called this genuinely open ground: classically they used Q-learning and similar methods to avoid exploring on things that are expensive, unengaging, and waste screen real estate; with LLMs there is an angle for much better guided exploration that "I don't think it has been thought through or explored a lot yet." Treat this as an acknowledged frontier, not a shipped capability.

Deduplication is embarrassingly unsolved. Asked where a just-purchased item gets removed from recommendations, Muthukrishnan confirmed it happens in the online blending step, and then conceded: "Surprisingly, this has still not been solved. I think now it's solvable. At least now it's purely an engineering problem."

Agents are early. Asked directly about agents, Muthukrishnan said the deliberate sequencing was to make it work non-agentically first, then move to agentic merchandising of the whole app. Das confirmed an internal team is building agents and agentic primitives, and that the same techniques transfer: GEPA-style prompt optimisation helps there too, and the consumer profile can be pulled into an agent's context via RAG. His example — if he says he is making chicken pasta tonight, the agent needs to know he likes chicken thighs and only organic, so that after search returns five or six candidates the LLM can do the last-mile reasoning about which one fits the recipe. That is consistent with the no-LLM-ranking rule rather than an exception to it: choosing between six items with recipe context is reasoning, not ranking a catalogue. Catalogue building is already "extremely agentic", and agents to help Dashers shop in-store are coming.

Author's note — security and privacy were largely unexamined. Beyond the unanswered prompt injection question, the talk does not discuss retention, consent, or access control on a store of natural-language behavioural narratives about millions of people. A prose profile is a far more legible and more sensitive artefact than an opaque embedding — it can be read by anyone with database access and it may contain inferred health signals (flu season purchases), household composition, and dietary or religious inferences. If you build this, that store needs the same treatment as any other sensitive personal data, and that obligation is yours to work out; none of this paragraph is stated in the presentation.

Practical Takeaways

Split the system by what each model class is good at. Use LLMs for user understanding, content ideation, and explanation. Use deep learning for retrieval and ranking under latency and metric constraints. If you find an LLM in your ranking path, that is the smell.

Make search queries your carousel population primitive. Having the LLM emit queries plus constraints, rather than item IDs, keeps generation decoupled from inventory and lets the online path stay authoritative about availability.

Store both prose and structured facets. The narrative is expressive; the extracted facets are what make retrieval and campaign targeting tractable.

Partition profiles into memory blocks with independent cadences and delta updates. This is the main lever on profile cost, and it gives you recency weighting for free.

Collect textual human feedback, not just scores. It is the input that made GEPA-driven prompt optimisation work well for them, and it is cheap to gather via dogfooding.

Build exploration in deliberately. Both speakers treat it as the only defence against the pigeonhole effect, and LLM world knowledge makes adjacency-based exploration more targeted than random.

Invest in shared primitives — profiles, product graph, evaluation frameworks — but do not start with a framework. Muthukrishnan's organisational advice is pointed here. Shared primitives should not be tightly coupled to the first use case, both for cost and for reuse. But he has seen companies start these as large infrastructure projects and believes that does not work: tie the work to real experiments that demonstrate return soon enough, start small, and generalise only once you understand the shape. Finally, treat the LLM-plus-deep- learning integration as product work, not infra work — the consumer does not care how elegant the plumbing is, only whether what is on screen makes sense.

Key Terms

• Dynamic moment — A short-lived, high-context event expressing consumer intent (movie night, birthday, Black Friday, flu season) that personalization should detect and serve within the session.
• Consumer profile — DoorDash's per-user representation, written as plain-English narrative plus extracted structured facets, and used as a shared primitive across notifications, ranking, search, and merchandising.
• Memory block — A partition of the profile (dietary habits, household info, category preferences, item/brand preferences, taxonomy preferences) with its own update cadence, model, and input data.
• Content blueprint — The LLM-generated specification for a carousel: its framing for this consumer, the search queries that populate it, and constraints such as price sensitivity, brand, merchant, or price band.
• Two-tower model — A retrieval architecture with separate user and item encoders sharing an embedding space, enabling fast nearest-neighbour retrieval over large catalogues.
• MTML — Multi-task multi-label deep models that predict several objectives (click, conversion, and so on) from shared representations; used for ranking.
• RAG — Retrieval-augmented generation; supplying relevant retrieved data in the prompt so the model reasons over your ontology and catalogue rather than parametric memory.
• Compound AI system — A pipeline of multiple interacting components (prompts, profile generation, retrieval, ranking) whose parts can be treated jointly as tunable parameters.
• GEPA (Genetic-Pareto) — A DSPy optimiser that evolves the parameters of a compound AI system against a reward function using mutation and hill climbing; explicitly not convex optimisation.
• LLM-as-a-judge — Using an LLM to score generated output against a rubric, used here as one of three evaluation axes rather than the sole signal.
• Pigeonhole effect — The recommender feedback loop where recommendations shape behaviour, which then reinforces the same recommendations; mitigated only by exploration.
• Dasher — DoorDash's delivery courier, who also shops in-store and therefore benefits from accurate variant-level product attributes.

The most portable lesson here is not the LLM usage itself but the boundary the team drew. They did not replace their recommender with an LLM; they inserted LLMs where behavioural data is structurally silent — cold-start items, world knowledge, in-the-moment intent, and human-readable explanation — and left the ranking layer alone. The evaluation problem that creates is real and unglamorous, and their answer to it is worth as much attention as the generation pipeline: once every user sees something unique, you no longer have a set of artefacts a human can review, so a reward function and an optimiser stop being optional.

Reference: Sudeep Das and Pradeep Muthukrishnan, Dynamic Moments: Weaving LLMs into Deep Personalization at DoorDash, QCon San Francisco 2025; the InfoQ page is dated April 21, 2026.