El pedido llega al WhatsApp del negocio con 0% de comisión

Un negocio de comida vende por las plataformas de domicilios y de cada venta se va una comisión enorme. No es una tarifa de software: es un porcentaje del plato, cobrado sobre el precio final, pedido tras pedido. Y encima el cliente no queda del negocio, queda de la plataforma: su número, su historial y su próxima compra viven del otro lado. Cuando el margen ya viene estrecho, esa resta es la que decide si el local abre el mes siguiente.

PÍDELO le da la vuelta a eso. El cliente escribe al WhatsApp del negocio, el número que ya tiene guardado, y ahí lo atiende un agente que conoce el menú, los horarios, dónde queda el local y lo que el negocio tenga escrito para resolver dudas. El pedido entra directo a la caja del local y el dinero lo cobra el local. La comisión por venta es 0%: se paga el software, no una tajada de cada plato vendido.

El sistema ha atendido a 55.120 clientes, y solo una parte de eso lleva IA. La caja de escritorio y el adaptador de impresoras térmicas ESC/POS son deterministas a propósito: cuando el pedido ya está confirmado, nadie quiere un modelo decidiendo qué se imprime en la cocina. La inteligencia vive en la conversación; de ahí para adentro manda el código de siempre.

El corazón es un bucle de tool-calling montado sobre el AI SDK de Vercel. Cada mensaje entra a un generateText con el catálogo de herramientas disponible y toolChoice en automático: el modelo decide si contesta, si consulta o si actúa. El bucle no da vueltas indefinidas. La condición de parada combina un tope de pasos con una herramienta terminal: cuando se ejecuta la que cierra el turno, el ciclo se acaba ahí, aunque al modelo le quedaran ganas de seguir hablando.

En el canal del cliente hay ocho herramientas y cada una tiene un trabajo estrecho. prepareOrder arma el pedido y lo deja listo para confirmar; createOrder lo registra de verdad. sendMenuImage manda la carta, sendLocation la ubicación del local, sendSchedule los horarios y sendWelcomeMessage abre la conversación con quien escribe por primera vez. fetchKnowledgePackage trae la respuesta a una duda concreta, y escalateToHumanAgent entrega la conversación a una persona.

Lo que sale de una herramienta va validado con Zod, así que el pedido que llega a la caja tiene forma conocida antes de tocar la base de datos. La base de conocimiento tampoco se consulta con texto libre: el agente escoge un tema de una lista cerrada, y eso le cierra la puerta a que se invente un dato que nadie escribió. Las notas de voz se transcriben con Whisper y entran al mismo bucle que el texto, porque el cliente que pide por audio pide igual de en serio.

Un agente que no sabe rendirse es un problema de negocio, no una curiosidad técnica. El que insiste en atender lo que no entiende termina tomando un pedido mal, prometiendo un domicilio que no existe o discutiendo con un cliente molesto en el número oficial del negocio. En un local real eso se paga en plata y en reputación, y se paga el mismo día.

Por eso escalateToHumanAgent tiene cuatro motivos tasados, no criterio libre: que el cliente pida hablar con una persona, que repita una queja, que muestre frustración evidente, o que lo que necesita quede fuera del alcance del agente. Están escritos así, cerrados, para que la decisión sea reconocible en el rastro y no dependa del humor del modelo ese día. Cuando se dispara, el turno se cierra: la herramienta es terminal y el agente deja de hablar.

Diseñar la salida cuesta más que diseñar la respuesta. Es fácil lograr que un modelo conteste siempre; lo difícil es que reconozca el borde y entregue limpio, con la conversación entera del lado humano y sin que el cliente tenga que repetir lo que ya dijo. Esa puerta es la que hace que el dueño de un negocio deje al agente atendiendo sin estar mirándolo.

Los proveedores de modelos fallan, y fallan a la hora del almuerzo. Cada modelo tiene su propio circuit breaker en Redis, con la máquina de estados escrita en scripts Lua atómicos: cerrado, abierto y semiabierto, con sondeo de recuperación y decaimiento exponencial del enfriamiento. Al resolverse en Lua, la transición ocurre en una sola operación, así que dos workers que fallen a la vez no dejan el interruptor en un estado imposible.

Cuando un modelo se cae, la cadena de fallback pasa al siguiente proveedor sin que la conversación se entere. Encima va un presupuesto compartido entre workers, con doble cubo: peticiones por minuto y tokens por minuto. El pipeline es asíncrono de punta a punta, del webhook de Meta a SQS, de ahí a BullMQ, al worker, al modelo y de vuelta por la API de Meta y por WebSocket, con locks distribuidos, deduplicación y una puerta de equidad entre chatbots.

Y aun así el modelo a veces devuelve basura. Antes de contestarle al cliente hay pasadas de calidad: si el texto sale vacío se sintetiza uno a partir de lo que el agente acababa de hacer; si viene con markup o escrito en otro alfabeto se corrige; si el flujo de herramientas se rompe, queda una recuperación sin herramientas que al menos deja al cliente atendido. Nada de eso es elegante. Todo eso es la diferencia entre una demo y un negocio abierto.

Los prompts no viven dentro del código: son un CMS versionado, con borrador, publicado y archivado, más variantes y variables dinámicas. Se cambia el tono de la bienvenida o se corrige una regla del menú y eso queda publicado sin desplegar nada. Cada cambio queda como una versión propia y la anterior no se pierde, así que un comportamiento raro se rastrea hasta el texto exacto que lo causó y volver atrás es publicar otra vez el que servía.

Todo el bucle está trazado en Langfuse por OpenTelemetry, con tracers separados por canal para que el tráfico del cliente y el del administrador no se mezclen. Encima llevo métricas propias de costo, de tokens y de errores por herramienta. Esa última es la que más me ha servido, porque cuando una herramienta empieza a fallar más de la cuenta casi siempre el problema está en el texto que la describe, no en el modelo que la llama.

La memoria de conversación vive en DynamoDB turno a turno, con las llamadas a herramientas incluidas, y se rehidrata entre reintentos: si un worker muere a mitad del pedido, el que lo reemplaza retoma con el mismo contexto. Y hay un segundo canal, el del administrador, con tres herramientas de solo lectura, pedidos activos, reporte del negocio y desglose financiero, y una prohibición explícita de tomar pedidos por ahí. Consultar y vender son dos permisos distintos.