Esta entrada aborda los límites del cliente y de la plataforma que subyacen a la experiencia de usuario y a las interacciones con Ask DoorDash: cómo pasamos de los carruseles de hackatones a ese modelo, cómo un mismo artefacto da servicio a tres lectores y cómo el contexto y el estado se mantienen coherentes a medida que los usuarios navegan por DoorDash. A continuación, «Creación del asistente de DoorDash: una visión general desde el punto de vista de la ingeniería» y nuestros análisis en profundidad «Creación de Ask DoorDash (Parte 2): Inteligencia», «Creación de Ask DoorDash (Parte 3): Evaluación», y Creación de Ask DoorDash (Parte 4): una plataforma para crear y desarrollar agentes.
Ask DoorDash convierte peticiones como «prepárame una cena de 60 dólares para 10 personas», «ayúdame a hacer tacos de pollo» y «aperitivos para toda la semana» en listas de la compra editables. Genera una lista con productos que se pueden comprar, precios, fotos, controles de cantidad y botones sencillos para cambiar cualquier artículo y finalizar la compra. En el caso de las peticiones relacionadas con restaurantes, se muestran establecimientos y platos que se integran en el flujo de compra nativo. Ambas funcionalidades se ejecutan en el mismo cliente y en la misma infraestructura de la plataforma. Este artículo se centra en el caso de uso de la compra de alimentación, ya que es el que plantea mayores dificultades a la hora de crear una interfaz intuitiva para las compras gestionadas por un agente. Las listas de la compra suelen contener entre diez y veinte artículos, pasan por varias rondas de revisión y deben adaptarse fácilmente a las limitaciones de los consumidores, como el presupuesto y las restricciones dietéticas.
Las sesiones de usuarios de julio de 2026 mostraron que, en las sesiones relacionadas con la compra de alimentación en las que se mostraba una lista de la compra, los consumidores realizaban una media de casi dos interacciones con la interfaz de usuario cada uno. Aproximadamente un tercio de esas sesiones continuaron con la aplicación de la lista al carrito. El asistente recoge la intención general de los consumidores y la sintetiza. El resultado son componentes nativos, que permiten a los consumidores realizar ajustes detallados. Las modificaciones sencillas actualizan inmediatamente un elemento de referencia, mientras que los cambios que requieren razonamiento dan inicio a un nuevo turno del agente.
Para crear una experiencia de compra colaborativa eficaz entre el consumidor y el agente, los agentes de compra deben integrarse en una interfaz interactiva basada en datos de comercio en tiempo real y en el contexto actual de la aplicación del consumidor. Cuando un consumidor está comprando en una aplicación, espera ver de un vistazo artículos reales que pueda adquirir. El texto puede describir ese entorno, pero los componentes interactivos basados en imágenes permiten a los consumidores recorrerlo realmente. El contexto también es importante. Los consumidores que abren DoorDash llegan con expectativas diferentes a las que tienen al utilizar una aplicación de chat de uso general. Compran navegando, pasando de una tienda a otra y de una página a otra, en lugar de describir lo que quieren. Salirles al encuentro allí donde se encuentran es una pieza esencial del rompecabezas.
Las grandes cosas tienen un pequeño comienzo
El asistente de compra de DoorDash comenzó como un proyecto de hackatón. Sabíamos desde el principio que la integración de los componentes existentes de DoorDash sería una pieza clave de cualquier cosa que construyéramos. Las primeras versiones se basaban en gran medida en carruseles: primero, una lista de tiendas cercanas; después, un carrusel con los resultados de búsqueda para cada artículo que buscaba el agente. Se mostraban en línea, cada uno con su término de búsqueda adjunto. El resultado era, básicamente, una transcripción de chat con resultados comerciales pegados en ella.
Desde el punto de vista funcional, se parecía mucho a lo que ofrecemos hoy en día. En cuanto a la experiencia de usuario, era más rudimentaria, y merece la pena repasar los detalles.
Una vez encontradas varias tiendas, el asistente preguntaba cuál quería explorar y esperaba a que se escribiera la respuesta. Cada carrusel representaba un único artículo que el consumidor necesitaba, y al elegir una opción de él, ese artículo se añadía al carrito. Cada uno aparecía con sus opciones desplegadas a todo lo ancho y la elección aún abierta. Así pues, preparar la compra para una semana significaba ir bajando por la lista, selección a selección, sin posibilidad de seleccionar varios artículos a la vez.
Detrás de todo ello se escondía un fallo que afectaba en ambos sentidos: la interfaz se había diseñado principalmente para presentar el trabajo del asistente. Cada carrusel iba precedido de la consulta que lo había generado y los resultados aparecían en el orden en que se habían recuperado. Los términos de búsqueda y los conjuntos de resultados sin procesar son el material de trabajo de un agente. Presentar los resultados directamente es el equivalente, en una interfaz, a imprimir un seguimiento de la pila. El asistente se sometía con la misma facilidad a la interfaz, trabajando con un elemento cada vez, porque lo único que la pantalla podía mostrar era una pila de carruseles por elemento. Cada uno se había diseñado en función de las limitaciones del otro, en lugar de hacerlo en función del usuario.
La lección no era que reutilizar componentes existentes estuviera mal; la familiaridad que aportan es precisamente la razón por la que el asistente se parece a DoorDash. Simplemente habíamos creado el contenedor equivocado para ellos. El contenedor es lo que determina el orden en el que aparecen, junto a qué se sitúan y qué puede hacer el usuario con ellos. Por encima de todo, el usuario necesita una interfaz de compra, más que una interfaz conversacional. Habíamos creado una interfaz conversacional que, casualmente, contenía componentes de compra. La reutilización de componentes nos proporcionó el vocabulario. Lo más difícil fue organizarlo todo en una interfaz de compra.
Lo que sí sobrevivió al hackatón fue la base: la experiencia se ejecuta hoy en día sobre la misma infraestructura de streaming que se estableció entonces. Por su parte, la capa de decodificación que convertía los resultados de las herramientas en una interfaz de usuario no perduró. El asistente ya no muestra en absoluto los resultados de las herramientas. En su lugar, dedicamos tiempo a desarrollar una arquitectura de artefactos que separa los requisitos de los usuarios finales de los requisitos de almacenamiento y de los agentes. En otras palabras: dejamos de decodificar el material de trabajo del agente para su visualización y empezamos a diseñar en función de las necesidades de los diferentes componentes y usuarios del sistema.
Figura 1: La misma solicitud de la compra, con un año de diferencia. La versión creada en el hackatón mostraba un carrusel por artículo, cada uno encabezado por la consulta que lo había generado; la selección se dejaba en manos del consumidor. Hoy en día, el asistente muestra cada lista como una tarjeta en la conversación, con los artículos más solicitados ya seleccionados.
Un objeto, tres lentes
Una lista de la compra tiene tres lectores: el servicio que la almacena, el agente que la revisa y la persona que hace la compra. Cada uno necesita ver algo diferente. Mantenerlos separados es lo que permite que los cambios del consumidor aparezcan de inmediato y sigan siendo válidos sin que ello suponga una nueva iteración del modelo.
El formato almacenado es el sistema de registro: un blob JSON que se guarda como un artefacto en Managed Agent Services, tal y como se describe en la publicación sobre la plataforma. Debe estar completo y es la única copia oficial.
El agente no lee ese bloque de datos directamente. Una lista de la compra interactiva contiene muchos más detalles de los que un modelo necesita para la mayoría de las respuestas. Repetir el nombre de cada producto, el precio, la cantidad, las sustituciones y cada dato de metadatos de visualización en cada turno entraría en conflicto con lo que el consumidor realmente ha solicitado. Por eso, cuando un agente emite un «widget», lo que permanece en el contexto de la conversación es un resumen conciso: la tienda y el contenido de la lista. Cuando un turno requiere el estado exacto, el agente lee el artefacto y obtiene una vista reducida en la que se han eliminado los metadatos de visualización. Esa vista es inequívoca y lo suficientemente pequeña como para procesarla de forma eficiente. Una lista media ocupa entre 40 y 60 KB de JSON. Lo que permanece en el contexto de la conversación es una sola línea de unos 240 caracteres, aproximadamente 250 veces más pequeña.
Lo que ve el consumidor es otra cosa, y adopta más de una forma. En la conversación, la lista se muestra como un widget compacto: la tienda, el nombre de la lista, la hora estimada de llegada, algunas fotos de los artículos y un botón «Añadir al carrito» que indica el total estimado. Eso basta para evaluar la lista de un vistazo sin salir del chat. El botón «Ver lista» abre la vista a página completa, que muestra la lista completa y todo lo necesario para revisarla en detalle. Ambas vistas están diseñadas para que se comprendan al instante y se pueda actuar directamente sobre ellas.
Hay un detalle que pone de manifiesto hasta qué punto divergen estas perspectivas. Cuando el agente elige un producto para un artículo de la lista, conserva los demás productos que coincidían con la misma búsqueda, y el consumidor puede alternar entre ellos con un simple toque. Se mantienen diez opciones por artículo, y el 99,7 % de los artículos tienen suficientes coincidencias para completar esa lista, por lo que casi cada línea en la vista del consumidor tiene una selección y nueve alternativas detrás. La vista del consumidor muestra todas y cada una de esas alternativas. La vista del agente no muestra ninguna de ellas, ya que elegir entre ellas es tarea del consumidor (a menos que se le pida explícitamente al asistente que lo haga).
Mantener los pies en la tierra
Si, con un carrito que contiene yogur de frambuesa, pulsas «Recomendaciones para el carrito», aparecen dos sugerencias: muesli, «porque combina bien con tu yogur», y arándanos, «para añadir fruta a tu yogur» (véase la figura 3). El caso de contraste ya existe en nuestro propio producto, en la misma pantalla: la página del carrito incluye un carrusel de artículos complementarios que ofrece productos que el consumidor podría querer añadir, sin indicar ningún motivo. Nuestro agente del carrito podría haber devuelto exactamente eso: una lista de artículos plausibles. Es muy posible que los artículos fueran los mismos en ambos casos. El razonamiento es lo que indica al consumidor que la sugerencia está fundamentada y no es meramente plausible, y dado que cada elemento de la interfaz es también un lugar para actuar, esa distinción tiene una función real.
Eso es lo que aporta el enfoque práctico: la diferencia entre una experiencia de compra atractiva y una simple novedad. Si el resultado del asistente no es tangible, los consumidores tienen pocos motivos para dejar de lado la completa experiencia que ya ofrece la aplicación de DoorDash. El texto sigue cumpliendo su función, pero en un papel secundario. Hemos colocado deliberadamente la lógica del asistente dentro de los widgets y a su alrededor, en lugar de mostrar las celdas de los artículos exactamente como aparecen en el resto de la aplicación.
La integración también debe mantenerse a nivel de los datos, y ahí el trabajo se divide. Un agente elige un tipo de contenido compatible y proporciona los datos comerciales correspondientes; el cliente de iOS se encarga de la presentación y la interacción, adaptando ese contenido a los componentes nativos del sistema de diseño de DoorDash. Una solicitud de compra de comestibles genera una lista de la compra editable con cantidades, sustituciones y un subtotal. Una solicitud de restaurante puede generar fichas de tienda, fichas de productos o sugerencias para el carrito.
Esa división es lo que da validez a los propios datos. Los valores comerciales de un widget no proceden del modelo. Los precios, el inventario, el horario de la tienda y el contenido del carrito se obtienen de los mismos sistemas de registro que utiliza el resto de la aplicación, por lo que un precio que aparece en Ask coincide con el precio de la página de la tienda en ese momento. El contenido tipado también proporciona al backend y al cliente un contrato estable. La implementación de un nuevo widget requiere algo más que un simple cambio. El agente tiene que saber cuándo utilizarlo y qué incluir en él, y el cliente necesita un esquema con nombre, además del código para descodificarlo y representarlo. Más allá de eso, un nuevo widget llega al consumidor a través del mismo mecanismo de conversación y transmisión que cualquier otro.
Los widgets como canales de E/S
Cada nuevo widget que hemos integrado ha hecho que el asistente resulte más funcional. La razón tiene tanto que ver con la entrada como con la salida. Hay un límite que rige todos ellos: una edición determinista permanece en el cliente y se aplica directamente al artefacto, mientras que un cambio que requiera un juicio inicia un turno del agente. Los ejemplos que figuran a continuación se organizan en función de dónde se sitúa esa línea divisoria.
La versión del hackatón preguntaba al usuario qué tienda quería y luego esperaba a que la escribiera. No tenía forma de elegir por sí misma; hoy en día, esa elección es automática. Todavía hay muchas otras preguntas que requieren la intervención del usuario, y el texto directo puede ser una forma poco adecuada de recabar las respuestas. La introducción de texto es una limitación de un solo hilo: el usuario puede saber todas las respuestas, pero solo puede proporcionarlas a la velocidad a la que escribe o habla.
Aquí es donde los widgets cobran sentido. Un consumidor puede tener que realizar diez operaciones en una lista de la compra, todas ellas sencillas. Por separado, son trivialidades; pero, cuando se describen con palabras, se convierten en una tarea compleja. Es la diferencia entre mirar por encima del hombro de alguien y decirle qué botones debe pulsar, y pulsar los botones uno mismo.
Las preguntas aclaratorias estructuradas son el ejemplo más claro, y el patrón se ha tomado prestado de los agentes de programación: la herramienta AskUserQuestion de Claude Code realiza la misma función para los desarrolladores. Ofrecemos un widget que interrumpe al consumidor con un pequeño conjunto de preguntas (de opción múltiple y selección múltiple), lo que le permite dirigir la conversación en momentos verdaderamente abiertos. Se ha convertido en un pilar fundamental del modelo de interacción del agente de supermercados y ahora se está incorporando al agente de restaurantes para simplificar este mismo tipo de interacción. Lo integramos con nuestra plataforma de memoria del consumidor, lo que reduce considerablemente las opciones, pero siguen existiendo lagunas de conocimiento que requieren la aportación del consumidor. Hacer preguntas es inevitable. Pero podemos preguntar de una forma que resulte fácil y eficiente para el consumidor a la hora de responder.
La vista de lista a página completa es donde la colaboración entre entrada y salida se hace tangible. Un consumidor puede modificar la cantidad de un artículo, eliminar un artículo, cambiarlo por una de las alternativas que el asistente ha encontrado junto a él y añadir la lista finalizada a su carrito. Cada una de esas acciones manipula el objeto directamente. Ninguna requiere que el asistente actúe en nombre del consumidor, y ninguna supone una ida y vuelta al modelo de lenguaje grande (LLM). El caso del cambio aprovecha mejor los conjuntos de candidatos de la versión del hackatón. Las alternativas entre las que elige el consumidor son los demás candidatos que el asistente recuperó al seleccionar el artículo. La lista de todas las opciones disponibles para el consumidor ocupaba anteriormente un carrusel. Ahora se encuentran a un solo toque de distancia de la decisión, en lugar de estar dispersas ante el consumidor como una pregunta abierta.
Cambiar de tienda es la excepción, y la excepción es lo interesante. No se trata de una modificación de la lista existente. Se convierte en una solicitud al asistente que reconstruye la lista en la tienda alternativa. Esta interacción también es poco frecuente: fue la primera acción en el 0,1 % de las sesiones activas, lo que se ajusta más o menos a lo que cabría esperar si el límite se establece más o menos en el lugar adecuado. Si se sitúa esa línea en el lugar equivocado, el consumidor o bien espera a que el asistente haga algo que podría haber hecho con un solo toque, o bien tiene que ir tocando para realizar una acción en la que habría sido útil el criterio del asistente.
El artefacto garantiza la seguridad de la división, y las dos partes escriben en él de forma diferente. Un cambio de cantidad, una eliminación o un intercambio siguen la ruta corta: el cliente actualiza la lista in situ y la modificación aparece de inmediato. En cambio, un cambio de almacenamiento inicia un turno del agente, ya que es necesario volver a hacer coincidir toda la lista con un catálogo diferente. Una revisión del agente no sobrescribe lo que había; genera una nueva lista derivada de la anterior.
El resultado es que una modificación directa tiene carácter vinculante. Antes de que un turno modifique la lista, el agente consulta la lista actual en lugar de basarse en la transcripción; por lo tanto, si el consumidor elimina la leche de avena, el siguiente turno comienza con una lista en la que ya no figura la leche de avena.
El comportamiento observado durante ese mismo periodo muestra dónde se sitúa esa línea divisoria. Inmediatamente después de la primera solicitud, casi tres cuartas partes de las primeras acciones siguientes se realizaron a través de un componente. A partir del segundo mensaje, la tendencia se invierte, y las acciones de seguimiento escritas constituyen la mayoría en todos los niveles de profundidad que hemos medido. Los controles se encargan de los ajustes inmediatos y estructurados; el lenguaje toma el relevo cuando el cambio es mayor o más difícil de expresar con un simple toque.
Todas las revisiones de los asistentes permanecen activas
Cuando el asistente revisa una lista de la compra, la versión que sustituye permanece en pantalla y sigue estando disponible.
Esa no fue nuestra primera implementación. La primera versión ocultaba las listas sustituidas: una vez que llegaba una revisión, la lista anterior ya no se podía ver ni editar. Una sola lista actual, sin desorden. Parecía un comportamiento más ordenado. Sin embargo, lo que conseguía era que solicitar una revisión resultara costoso. Si pedir un cambio puede borrar una lista con la que estás satisfecho, lo más seguro es dejar de pedirlo, y eso socava el sentido mismo de un flujo colaborativo.
Así, cada revisión realizada por un asistente genera ahora un nuevo elemento derivado del anterior, y cada uno permanece en el lugar de la conversación donde se creó. Si te desplazas hacia atrás, las versiones anteriores siguen ahí, siguen activas: un usuario puede abrir una lista anterior, editarla o añadirla a su carrito en lugar de la más reciente. Solicitar un cambio no cuesta nada, porque lo que tenía hace un momento está a solo un desplazamiento de distancia.
No todas las listas que elabora el asistente se convierten en una versión que ve el consumidor. Cuando el asistente elabora una lista de opciones y llega a la conclusión de que la tienda no dispone de lo solicitado, esa lista nunca se muestra. Se informa al consumidor mediante un texto de que la tienda no tenía los artículos y de que se le está preparando una nueva lista. Es uno de los pocos casos en los que el texto cumple su función de forma directa, y es la razón que subyace a todo lo demás en esta entrada: la interacción se utiliza para simplificar, y el texto se utiliza para justificar.
Cuando una lista se convierte en un carrito
Un asistente que edite directamente el carrito puede eliminar un artículo que el cliente quería o añadir uno que nunca haya confirmado, sin que se le pregunte. Un solo error de este tipo basta para perder la confianza del cliente, ya que el fallo pasa desapercibido y afecta precisamente a lo que está a punto de pagar.
Por eso, en su lugar, presentamos una lista de la compra como propuesta. Puede contener docenas de artículos y pasar por varias rondas de revisión, ya sea para eliminar un producto de despensa que el consumidor ya tiene, cambiar una cantidad, sustituir un producto o modificar parte de una receta, y nada de ello afecta al carrito. Para confirmar la selección es necesario hacer clic explícitamente en «Añadir al carrito», que es la estructura más sencilla que hemos encontrado y que ofrece al consumidor un control real sin obligarle a supervisar cada paso.
Aún hay que conciliar ambos elementos, y lo interesante es decidir quién lo hace. El asistente lee el contenido del carrito mientras elabora la lista, pero no la ajusta automáticamente para que coincida: si una receta requiere dos plátanos, la lista solicita dos, independientemente de si ya hay cuatro en el carrito. Elaborar la lista con exactamente lo que se ha solicitado y conciliarla con el contenido del carrito en un paso aparte permite que cada decisión se tome en su contexto.
Ese paso se pone de manifiesto en el momento de confirmar la compra. Cuando la lista y el carrito coinciden, se muestran al consumidor los productos duplicados y este decide si desea sustituir esas cantidades o añadir otras. Es un pequeño momento, pero son precisamente los pequeños momentos como este los que determinan si se gana o se pierde la confianza.
Mantener el contexto en DoorDash
No basta con que el asistente se encuentre en un único lugar; debe poder accederse a él desde cualquier parte de la aplicación. Abrir el asistente ya es una señal clara de intención, pero ambigua. En ese momento, un consumidor puede estar haciendo un pedido en su restaurante favorito, comprando la compra para la semana, buscando unos auriculares nuevos o solicitando ayuda con un pedido anterior. Un consumidor que ha accedido a la página web de una tienda de alimentación concreta está enviando una señal mucho más clara: es probable que tenga la intención de crear una cesta de la compra en esa tienda. Facilitar ese contexto al asistente es lo que le permite centrarse en la intención probable en lugar de tener que preguntar.
El sistema de ámbito que hemos diseñado para esto abarca tanto el cliente como la pasarela. El cliente adjunta a cada solicitud datos clave sobre el contexto de la entrada: el tema bajo el que se ha registrado el usuario (supermercado, restaurante), la tienda que está consultando y algunos identificadores relacionados. La pasarela utiliza el tema para decidir a qué agente se deriva la solicitud, y el resto de datos para proporcionar a las herramientas los identificadores que necesitan.
Scope es, deliberadamente, un conjunto plano de pares clave-valor en lugar de un esquema tipado, y es el cliente quien decide qué se incluye en él. Las claves no reconocidas se transmiten tal cual, en lugar de rechazarse, por lo que una nueva superficie puede empezar a enviar contexto sin tener que esperar a que se produzca un cambio en la pasarela. La excepción es el propio tema: añadir uno nuevo implica indicar a la pasarela a qué agente debe dirigirlo. Así pues, aunque crear una nueva superficie es sencillo, crear un nuevo dominio no lo es.
El tema es también la parte que se aplica únicamente al primer mensaje de un contexto. Eso proporciona al asistente una base sólida sobre la que trabajar sin ser excesivamente prescriptivo, y es lo que permite a los usuarios salir de un ámbito cuando así lo eligen explícitamente. Un usuario que utilice el asistente dentro de un restaurante puede salir por completo del ámbito del restaurante pidiéndole: «Búscame una receta para este plato y prepárame una lista de la compra para que pueda prepararlo en casa». Esa solicitud no es gratuita, pero el coste supone un pequeño desvío en el proceso en lugar de un callejón sin salida: el agente del restaurante tiene que reconocer que la solicitud queda fuera de su ámbito y devolverla antes de que otro agente se haga cargo de ella.
En ciertos casos, los ámbitos también nos permiten prescindir por completo del modelo. Tomemos como ejemplo el punto de entrada «Volver a pedir mi último carrito». Podríamos limitarnos a enviar esa frase al asistente como un mensaje y, aunque eso funcionaría, añadir un ámbito nos permite ser más precisos. El caso de «volver a pedir» es, en la práctica, determinista, por lo que podemos saltarnos el modelo de lenguaje grande (LLM) y devolver una lista de la compra casi de inmediato. Lo que se devuelve es un widget de lista de la compra normal y corriente: el consumidor puede cambiar las cantidades, intercambiar productos o pedirle al asistente que la revise en el chat, exactamente igual que lo haría con cualquier otra. Ten en cuenta que esta omisión solo es válida si la tienda sigue teniendo todos los artículos del carrito anterior; si un artículo no está disponible, la solicitud se envía al agente de alimentación, que vuelve a generar la lista del mismo modo que lo haría a partir de una solicitud escrita.
El ámbito es también lo que hace posible mantener una única conversación continua a lo largo de una sesión de la aplicación, pero solo funciona porque el ámbito, la asignación de agentes y el estado de la sesión se mantienen separados. Tratamos el ámbito como un contexto por turno. La asignación, descrita anteriormente en la serie de entradas del blog, mantiene los turnos de seguimiento con el agente que resolvió el turno anterior. Tanto la asignación como la transcripción (la conversación propiamente dicha) se asocian al chat en lugar de al ámbito, por lo que un consumidor que se desplaza de una tienda a otra reasigna la asignación a un agente de un nuevo ámbito sin descartar lo que se había dicho. Varios agentes se especializan en segundo plano, y el conjunto sigue comportándose como un único asistente.
Conclusión
La integración de los agentes en los productos de consumo aún se encuentra en una fase temprana. Sin embargo, las bases se están perfilando con claridad. Los widgets son el lugar donde los consumidores realizan el trabajo, y la conversación entre el consumidor y el agente es lo que los guía. Actualmente hay tres lectores de nuestro artefacto de lista de la compra, y cada uno necesita una visión diferente del mismo. Utilizamos la parte orientada al usuario para que el consumidor se sitúe en el contexto de los productos reales y para que las modificaciones habituales se puedan realizar con un solo toque. A medida que los agentes asuman una mayor parte del trabajo, esperamos que lo que el consumidor necesita ver y lo que el agente necesita analizar sigan cambiando, y que la línea divisoria entre la interfaz de una aplicación y la de un chat sea cada vez más difícil de trazar.
